Additional Context

Before going into the particulars of this post, I want to clarify a few important details:

• I will assume that you have already read the previous post. If you have not, I highly recommend that you do so first to get the full context.
• This post will be largely based on the official documentation page for Incremental load in Query Service. The information in the Experience League is sometimes difficult to follow, so my goal here is to make it more digestible. For example, I do not find any obvious connection between this help page and the documentation of the SNAPSHOT clause.
• Throughout this post, I will use the word “table”. However, remember that there are no such database tables in the Adobe Experience Platform (AEP). The underlying data is stored in a dataset, as usual.
• The SNAPSHOT clause and, therefore, this post only applies to scheduled queries.

Auxiliary Table Creation

The first step is to create an auxiliary table to keep track of the snapshot IDs. We will use the same table for all queries.

DROP TABLE IF EXISTS checkpoint_log;
CREATE TABLE checkpoint_log AS
    SELECT
        cast(NULL AS string) process_name,
        cast(NULL AS string) process_status,
        cast(NULL AS string) last_snapshot_id,
        cast(NULL AS TIMESTAMP) process_timestamp
    WHERE false;

Be very careful with this query. If you accidentally run it a second time in production, the first command DROP TABLE IF EXISTS checkpoint_log; will delete the table and, with it, all existing data.

Initialization

The query that I will show in the next section expects an initial value in the table. For every such query, you need to insert a row in the table:

INSERT INTO checkpoint_log
    SELECT
        'DIM_TABLE_ABC' process_name,
        'SUCCESSFUL' process_status,
        cast(NULL AS string) last_snapshot_id,
        CURRENT_TIMESTAMP process_timestamp;

You must replace DIM_TABLE_ABC with a unique name for your query. There is no need to use the name of the dataset you are querying, you can use any other unique text for your query, as long as you use it consistently. In fact, if you are going to run multiple queries against the same dataset, I do not recommend that you use the dataset name, but a different name for each query.

As with the table creation, you should not run this query a second time for the same process_name in production. It will add a new entry with the current timestamp and all previous entries will be ignored. The effective consequence is that the next run of the main query will start from the beginning of time.

Incremental Processing

Now it is time to run your scheduled query. This is how it will look like:

$$ BEGIN
    SET resolve_fallback_snapshot_on_failure=true;
    SET @from_snapshot_id = 
        SELECT coalesce(last_snapshot_id, 'HEAD') 
        FROM checkpoint_log a 
        JOIN (
            SELECT MAX(process_timestamp)process_timestamp 
            FROM checkpoint_log
            WHERE process_name = 'DIM_TABLE_ABC' AND process_status = 'SUCCESSFUL' 
        ) b
        ON a.process_timestamp = b.process_timestamp;
    SET @to_snapshot_id = SELECT snapshot_id FROM (SELECT history_meta('DIM_TABLE_ABC')) WHERE is_current = true;
    SET @last_updated_timestamp = SELECT CURRENT_TIMESTAMP;
    
    CREATE TABLE DIM_TABLE_ABC_Incremental AS
        SELECT * FROM DIM_TABLE_ABC SNAPSHOT BETWEEN @from_snapshot_id AND @to_snapshot_id;

    INSERT INTO checkpoint_log
        SELECT
            'DIM_TABLE_ABC' process_name,
            'SUCCESSFUL' process_status,
            cast(@to_snapshot_id AS string) last_snapshot_id,
            cast(@last_updated_timestamp AS TIMESTAMP) process_timestamp;

EXCEPTION
    WHEN OTHERS THEN
        SELECT 'ERROR';

END
$$;

Let’s analyze this code. There is a lot going on in just 30 lines.

Anonymous block

You need to insert your query in an anonymous block using the keywords BEGIN, EXCEPTION and END to be able to exit gracefully in case of errors.

Expired snapshots

The documentation mentions that there could be problems with expired snapshots. I do not exactly know what they mean by this concept, and it is not clearly explained either.

In any case, the proposed solution is to add the line SET resolve_fallback_snapshot_on_failure=true; to the query. I have added it just in case, but I am not sure it is always needed.

Retrieve the last snapshot ID

Next, you need to get the last snapshot ID from the auxiliary table checkpoint_log.

    SET @from_snapshot_id = 
        SELECT coalesce(last_snapshot_id, 'HEAD') 
        FROM checkpoint_log a 
        JOIN (
            SELECT MAX(process_timestamp) process_timestamp 
            FROM checkpoint_log
            WHERE process_name = 'DIM_TABLE_ABC' AND process_status = 'SUCCESSFUL' 
        ) b
        ON a.process_timestamp = b.process_timestamp;

You need to replace DIM_TABLE_ABC with the unique name for your query that you decided when you initialized the table.

Now you have the variable @from_snapshot_id set to the snapshot ID of the last execution of the query. In the first run, it will be set to NULL thanks to the initialization.

Retrieve the current snapshot ID

Using the function history_meta, you need to get the last snapshot ID of the dataset DIM_TABLE_ABC. In this case, you have to replace this dataset name with your real dataset name, not the process_name value.

It took me a bit of time to understand why we need this value. I initially thought that we could just use 'TAIL' but then I realized that there could be race conditions between the query execution and new batches: if a new batch arrives while the query is running, there could be a case where the new data would be skipped.

    SET @to_snapshot_id = SELECT snapshot_id FROM (SELECT history_meta('DIM_TABLE_ABC')) WHERE is_current = true;

Get the current timestamp

To sort the entries in checkpoint_log the query relies on the timestamp of the execution of the query, so we need to retrieve it too.

    SET @last_updated_timestamp = SELECT CURRENT_TIMESTAMP;

Your query

Now is when you finally run your complex query, probably dozens of lines long. The example above shows a very simple query as a placeholder:

    CREATE TABLE DIM_TABLE_ABC_Incremental AS
        SELECT * FROM DIM_TABLE_ABC SNAPSHOT BETWEEN @from_snapshot_id AND @to_snapshot_id;

This can be any query. The fact that the tables are called DIM_TABLE_ABC and DIM_TABLE_ABC_Incremental is irrelevant and it has no connection with the value you have inserted into the auxiliary table. The only important relation here is that the process_name value in checkpoint_log and your query is 1:1. For every query you schedule, you need to come up with a new process_name.

The truly important part of the query is SNAPSHOT BETWEEN @from_snapshot_id AND @to_snapshot_id, which you will need to embed in your query in the right place. This tells the Query Service engine to only process the dataset entries between these two markers.

If you have to combine two or more datasets that need to also use snapshot IDs, you will have to replicate the code to manage them, using different variable names and process_name values for each dataset. I am not implying that you have to use it for all your datasets in a query. If you are combining a large dataset with a small one, you may not need to use the SNAPSHOT clause with the small dataset.

In general, this central body of the query will be developed in isolation before adding the rest of the surrounding code:

1. Start by developing and testing your query without the SNAPSHOT clause.
2. Once your base query works, add the SNAPSHOT clause.
3. Add some manual entries to checkpoint_log and test the query with the SNAPSHOT clause.
4. Add the rest of the code around your main query and test it.
5. Schedule your query and check for a few days that it works.

Finally, you are ready to go to production:

1. Manually insert the initialization entry.
2. Copy the query from development or staging to production.
3. Schedule the query.

It goes without saying that you should monitor it for a few days.

Update the auxiliary table

With the query successfully executed, you should insert the last snapshot ID into the auxiliary table:

    INSERT INTO checkpoint_log
        SELECT
            'DIM_TABLE_ABC' process_name,
            'SUCCESSFUL' process_status,
            cast(@to_snapshot_id AS string) last_snapshot_id,
            cast(@last_updated_timestamp AS TIMESTAMP) process_timestamp;

The value of @to_snapshot_id in the current execution will become the value of @from_snapshot_id in the next execution.

As I also explained in my previous post, there is no UPDATE operation with datasets. This is why you have to add the value to the end of the dataset (INSERT) and add a timestamp.

Finalization

I am not intimately familiar with exception handling in SQL. My understanding is that this code just returns 'ERROR' if any query failed.

EXCEPTION
    WHEN OTHERS THEN
        SELECT 'ERROR';

END

Photo by Creative Minds Factory on Unsplash

Data Lake vs RDBMS

Although the Adobe Experience Platform (AEP) Data Lake has a SQL interface, it is far from being a Relational DataBase Management System (RDBMS). The technologies behind each are completely different. The fact that you can use a PostgreSQL client to connect to the Data Lake does not make it a PostgreSQL database.

There are two fundamental differences: file structure and data manipulation.

File structure

Each RDBMS engine has its own file structure to store the data: SQLite uses a single file for everything, MariaDB spreads the data over multiple files, and Oracle requires its own partition or block device.

In the case of AEP, you will have already noticed that XDM is based on JSON. Dataset batches in AEP are stored as JSON files. Think of each of them as a JSON array containing multiple rows of data. This applies to both profile and event datasets.

Data manipulation

RDBMS engines support various operations to manipulate data: INSERT, UPDATE or DELETE. When you issue a DELETE, the RDBMS may delete the data from disk, but it is more likely that it just sets a hidden flag to mark the row as deleted, so that it is ignored in subsequent queries. An UPDATE may modify the existing value on disk or create a new row with the new data, marking the previous row as deleted; in both cases, the old data becomes unavailable.

The AEP Data Lake only supports INSERT operations. Once a profile fragment or event is written into a dataset, it is never modified or deleted. The only way to delete data from the Data Lake is to delete a batch or the whole dataset, or when a data retention policy rule determines that some data has to be deleted. In other words, all data that you send to AEP keeps piling up in the Data Lake.

Do not get confused with the Real-Time Customer Profile (RTCP). The RTCP only contains the last version of the profile and the events that have not expired due to TTL. So, when you send a new profile fragment, RTCP will delete the previous fragment and only keep the last one, while the Data Lake will keep all versions.

Querying the Data Lake

I am sure you know where I am going with this, but I want to make sure we are all on the same page. When I run SELECT * FROM my_fancy_dataset, the Query Service will process all rows in the dataset from the beginning of time. Think about it: if you have web events from a website with heavy traffic from the last 2 years, Query Service will process billions of rows. And if you think that you are safe with querying the profile snapshot, you should remember that the dataset has the profile snapshots from the past too.

No wonder that the query that ran smoothly a year ago, when you had just finished your AEP’s implementation, is dragging its feet now. The slowdown is exponential and you are consuming compute hours like crazy.

Query Optimization

I hope that, by now, you are convinced that all queries that need to run regularly must be optimized. This should not be an afterthought; your query should be optimized from the beginning, even if it is not needed initially. Modifying a query in production is a risky and expensive operation. In the long term, it is cheaper to write the query thinking about the future from the get-go.

Here you have a few techniques to optimize the execution of queries.

The WHERE clause

As simple as it seems, you should use time-based WHERE clauses wherever possible. If you are querying the profile snapshot, you only need last day’s data. If you are processing events, I am sure that the events from 2 years ago are not relevant anymore.

Derived tables

Some datasets are huge by nature. My best example is the journey_step_events dataset, which has every step of every journey for all profiles in journeys. Another example could be the web event dataset of a heavy-traffic website, as mentioned above.

If you are going to run complex queries based on this huge dataset, but do not need all the data in it, my strong recommendation is to create a derived dataset using a Create Table As Select (CTAS) query. In this initial query, you only select the rows and the columns that you really need. Then, you run your complex query on this derived dataset.

The SNAPSHOT clause

This is probably the most important feature for query optimization, and the most important section of this post. Data Distiller offers the SNAPSHOT clause to tell the query engine to only process rows between two markers. It is explained in great detail in Experience League: Incremental load in Query Service. However, I am sure that by just looking at the title of that page many will have skipped it, and this is why I am highlighting it here.

I want to clarify that this feature only makes sense if you are scheduling a query to run regularly (every hour, every day, every week…). You do not need it if you are just running a query once or need to process all data in the dataset.

The idea is fairly simple, although the code may look complex. You start by creating and initializing an auxiliary table to keep track of the last marker that has been processed. Then, with every execution:

1. Get the previous marker from the auxiliary table.
2. Get the last marker in the dataset.
3. Run your query between these two markers.
4. Insert the last marker into the auxiliary table for the next run.

Since this post is already getting too long, and this feature is so important, I will continue in my next post on the SNAPSHOT clause.

Finally, by no means am I an expert in Data Distiller. If you feel like I am missing an optimization trick, let me know in the comments.

Photo by Diana ✨

Storage vs DAM

The first step is to define what a DAM is. Duckduckgo’s LLM, based on Adobe and Gartner, defines it as:

Digital asset management is the process of organizing, storing, and distributing digital files using specialized software, which helps create a centralized repository for easy access and management of digital assets like images, videos, and documents. It enhances efficiency, security, and accessibility while ensuring consistent use of assets across an organization.

This definition emphasizes the enterprise focus of the process and tools. It is not just a simple storage, like your hard drive or OneDrive. It does much more. One key feature (or, rather, lack of) is that your DAM should not be your working directory.

Use Cases

In order to select the right tool to store content, you need to first define the use case. Let’s see the most common.

Image and Video Creation

When a photographer is taking photos or a videographer is shooting a video, you are not expecting the content to be stored directly in a corporate storage solution. Maybe in the future, with mobile or satellite networks supporting gigabits per second, this type of content can be directly uploaded to the cloud. For now, it will go to a storage device like an SD card or a portable SSD.

You may be thinking that I am going too far with this type of storage. However, it still must be managed. If I am paying for these photos, I want to make sure that they are properly managed.

Content Editing

I will not entertain any type of local or network storage. In 2026 and in a corporate environment, I am not sure they have a purpose for content management.

Once you have the photos or the videos, it is time to edit them; in the case of text, this is where you start from. You need some type of storage where you can store, edit, and share the content. This storage should allow you and relevant people to apply changes, add comments, or approve it. It needs to be compatible with the editing software that you are using. You do not want to copy a file from A to B, edit it in B, and move it back to A. Even worse, sending emails around with the content attached. Here be dragons.

For example, with Adobe, if you are going to use Frame.io and Adobe Photoshop to edit your content, Adobe cloud storage directly integrates with them.

Types of storage that you can use in this case:

• Cloud providers: SharePoint, OneDrive, Google Drive, Adobe Document Cloud, and similar; they all allow content sharing.
• Project tool storage: as you mature in Content Supply Chain, you will want to use project management tools like Workfront, which come with their own storage.

Content Publishing

Once content is approved, it is finally ready for your marketing campaigns. Now the situation changes; the storage tools from above are usually not fit for purpose. Instead, you need a tool that allows your campaign managers to find and use the approved content, and makes it available to other campaign tools.

This is where a DAM comes into play, the whole reason for its existence. While other types of storage are meant to keep lots of content, a DAM should only contain content that is ready to be shown to customers and the rest of the world. From hundreds of photos that you have taken at the beginning of the process, only those edited and approved should be in the DAM. In other words, a DAM is not a good place to store temporary content that is still being edited, or a storage dump to keep everything.

In the case of Adobe Experience Manager Assets, these are some of the features you get:

• A folder structure and tags for easy management and search. You do not want to spend time finding the right image.
• Various renditions for images, to adjust to different screens and locations.
• Integrations with:
  • AEM Sites (obviously!)
  • Adobe Journey Optimizer for email, SMS and push notifications.
  • Marketo.
  • Workfront, to receive the approved assets.

Archival

Creating all this content does not come cheap. As an enterprise, it forms part of your intellectual property, and you may want to keep everything that has been created, even if it has never been used. For this purpose, you will want to use another type of storage, specialized for archival. You are not likely to use this content anymore, so there is no need to make it easily accessible.

You could continue using your cloud provider, but there is another solution to consider: long-term, secure, and durable storage. They tend to be cheaper than cloud storage, as they have been optimized for storage, not retrieval. Some examples are AWS Glacier, Azure Archive Blob and Google Cloud Nearline.

Final Remarks

I hope that it is now clear when and when not to use a DAM. In summary, a DAM has been designed to store published content, content that has to be accessible by multiple people, from campaign managers to end users. For all other cases, you should be looking at a solution that meets your needs.

Photo by Taryn Elliott

Bad Quality

Let’s start by defining what we mean by bad data quality. IBM defines it as follows:

Poor-quality data occurs when datasets fail to meet the requirements of a specific business operation. Even data that appears accurate and complete can function as “bad data” if it isn’t fit for purpose, meaning it doesn’t support the use case […]

I very much like the inclusion of “business operation” and “use case” in the definition. Data is data is data. Zeroes and ones are not wrong, unless there is data corruption. The quality of the data has to be evaluated against the desired outcomes of the usage of that data. In our case of the digital marketing sphere, data is good only if a marketer can trust it to make decisions and run successful campaigns.

The consequences of having poor data quality are multiple and varied. It would require a long post, which nobody would read, and it would still be incomplete. Instead, let me share a couple of examples in AEP:

• Segmentation. You want to be sure that the audience receiving the marketing message is the right one. Sending a message that does not resonate with a recipient is a waste of resources and can damage reputation.
• Personalization. In this world of hyper-personalization, generic or incorrect messages ruin campaigns.

Data Patching

Once the bad data is in the system and is needed immediately, we have no other option than to patch it. However, this is just a band-aid, as the next batch will contain errors again. I want to emphasize that this is a short-term solution. It just means that we are doing what we can to keep the system working, but not fixing the root problem.

I will not try to enumerate all options to clean up the data temporarily, just share some ideas with AEP in mind:

• Use data prep functions upon ingestion, even though we strongly recommend against using them.
• Use data distiller to:
  • Modify profiles with issues that can easily be fixed.
  • Mark profiles that should not be used, or put them in an exclusion audience.
  • Calculate a data quality index per profile, and create an exclusion audience based on a data quality index below X.
• In Adobe Journey Optimizer:
  • Use conditions to exclude profiles that do not meet the minimum standards for a journey.
  • Use an update profile activity to increase the quality of the profile.

Bad Governance

In the past, when I heard my customers complain about their low data quality, I just accepted it. It is not my job to judge how they run their business.

However, recently, someone mentioned that the problem is not with data quality, but with data governance. It was one of those lightbulb moments 💡. I told myself: How could I not have thought of it? It makes a lot of sense!

Poor data quality is the evidence of the problem, not the problem itself. The problem lies in allowing the wrong data to enter the system in the first place. Why did it happen?

Data Governance for Data Quality

Many years ago, I had a customer with a problem in the data they received from third parties. These third parties were using the email address as the identity, which, as you all know, is a bad, bad idea. However, my customer wanted AEP to fix the problem. Before AEP, they had a complex solution based on heuristic rules to choose which profile an event should be assigned to. It took me a lot of effort convincing them that a CDP is not an MDM. Finally, they realized that the solution was to force all customers to have a unique email address.

In order to ensure that any data entering the system is of sufficient quality, you have to make sure that humans enter correct data. In other words, it is a human responsibility, as, ultimately, all data comes from human sources.

Therefore, data governance is the only solution that addresses the root of the problem: the human. I am not saying that humans are stupid, but we know that we all make mistakes. These mistakes can be as simple as a typo or as important as not submitting the data. You will have noticed that I have used the word “solution” here, whereas I used the word “patching” earlier. I have done it on purpose.

While researching for this topic, I found the Wikipedia page on Data Governance very useful. I want to highlight the following comments:

Data governance is the set of principles, policies, and processes that guide the effective and responsible use of data within an organization. It creates a framework for decision making, accountability, and oversight across the data lifecycle, from creation and storage to sharing and disposal.

Data governance initiatives improve the quality of data by assigning a team responsible for data’s accuracy, completeness, consistency, timeliness, validity, and uniqueness.

Leaders of successful data governance programs declared at the Data Governance Conference […] that data governance is about 80 to 95 percent communication.

As you can see, all these points apply to humans: processes, teams, communication… There is nothing technical in data fundamentals. Sure, technology should help us avoid bad data quality, but technology on its own cannot be at the core.

I am totally aware that this solution is a tall ask. Companies are like oil tankers, which require miles to change course or stop. Nobody likes to be told that they have to work differently, and there is a natural resistance. Unfortunately, I cannot think of any other option. On the other hand, I have worked with many companies that have taken good care of their data governance and they are happily using their data to achieve their goals.

Photo by Yan Krukau

If you have not read those posts or do not remember them (I will not blame you), the problem to solve is the situation where you have Adobe Journey Optimizer (AJO) offers and Adobe Target (AT) on the same web page. We want to make sure that one does not interfere with the other. There are various approaches, which I summarize in the tables below. I have added some more cases that I did not consider in my previous posts.

Some clarifications:

• Private section refers to the section of the website only for logged-in visitors.
• Public section is the part of the website visible to everybody.
• AT Premium applies to all cases, except in option A, where it only applies to the public section.

A different view of the same information:

I hope this is now clearer. I know it is not easy to envision all options. Let me know if you have seen another configuration that has worked without major issues.

Photo by Peter Bryan on Unsplash

This complexity shows up in a very fundamental place: how we define a “conversion” in the first place.

What is a conversion?

In some industries, like retail or travel and hospitality, a conversion seems straightforward: a customer buys something, and that transaction is the success metric. However, once you step outside these simple scenarios, the answer is no longer obvious.

Consider a few examples:

• Financial institutions. It is clear that they aim to make money and that digital marketing matters as much as in any other vertical. But what exactly is a conversion for a bank? Is it opening an account, even though that is initially a cost for the bank? Is it the first deposit? Is it when the account reaches a certain balance?
• Telecommunications. When you get a new line, you usually pay only the first month up front. Subsequent monthly payments are not recorded at the moment of opening the line. Should all future payments be attributed to the original campaign that brought the customer to the carrier? What about a subsidized phone, which initially costs the carrier more than the sale price?
• Consumer packaged goods (CPG). Here the situation is even more complex. Most CPG companies do not sell directly to customers; they sell through supermarkets and other distributors. These intermediaries rarely share detailed sales data with their suppliers, making it very hard to tie a specific campaign to a specific sale.

These examples show that even something as basic as “what counts as success” is not universal, and that has big consequences for how we measure performance.

Micro vs macro-conversion

To manage this complexity, digital marketers started to distinguish between different types of conversions. As digital marketing became more sophisticated, teams began to track not only purchases but also intermediate steps that signal progress toward a purchase. A new qualifier appeared: not all conversions are equal.

• Micro-conversions are meaningful steps a customer takes on the way to a final conversion. Examples include creating a web account, clicking on an internal campaign link, or using the chat functionality.
• Macro-conversions are the final events that usually represent direct business value, such as a transaction or a contract signed.

This distinction is useful, but it also makes it even more important to be explicit about what your conversions are.

Define your conversions

All of this complexity has one practical implication: you cannot assume that everyone in your company shares the same definition of a conversion. We tend to take for granted that we all mean the same thing, but you might be surprised once you start asking a few uncomfortable questions.

Here is some guidance to define your conversions. Notice the plural: you will probably need more than one definition, depending on the use case.

• When running A/B tests, be clear on what you are trying to optimize. Some will argue it should be revenue; others will prefer clicks on the banner, especially when what happens later may not be directly connected to that banner.
• List and prioritize the micro-conversions that signal a customer’s intent to eventually convert. Not all micro-conversions have the same weight, and some may be much better predictors of future value.
• For subscription services, decide whether the conversion is the first month’s fee, the first year’s revenue, or an average revenue per customer over time. Different choices will change how you evaluate campaigns and which ones you consider successful.
• When conversions do not have an obvious monetary value, consider assigning one. This applies to both macro-conversions and, especially, micro-conversions. You may be able to use statistical analysis to estimate how a given conversion contributes to total revenue and turn that into an approximate currency value.

The point is not to discover a single “correct” definition of conversion, but to choose clear, consistent definitions that match your business model and share them across your organization. My suggestion is that any marketing campaign should not only describe the activities, but clearly define the converstion.

Photo by Clay Banks on Unsplash

A Bit of History

I am fascinated by planes. I follow a few YouTube channels about them. To me, it is almost unbelievable that we went from

to

in just over 60 years.

If you have been in the Digital Marketing space for a decade or more, you will have noticed a similar evolution from the early days to today. However, instead of taking 60 years, it has only taken 20.

When Adobe acquired Omniture in 2009, very few understood the move. In the years since then there have been more acquisitions in the Digital Experience front: Day Software, Demdex, Neolane, Efficient Frontier, Workfront… Then, these purchases started to make more sense.

However, bringing all these different tools together and connecting them to the Adobe Experience Platform has not been easy: different technologies, different approaches, different perspectives had to be aligned. The very reason why the Multi-Solution Architect role was created was to bring all tools together.

This evolution has also been seen on the business side, although slower. Initially, people were only interested in their own tool. I remember with nostalgia the days when I was consulting on Adobe SiteCatalyst Analytics and Adobe Audience Manager. My customers were only interested in their own tool. Nobody working with Adobe Analytics cared about Adobe Campaign, and vice-versa, except perhaps for the Genesys integration.

Over the years, though, this siloed approach started to evolve into families: data, experience, and orchestration. People needed to use various tools to generate better marketing. For example, it was not enough for content creators to master Adobe Experience Manager, they also had to work with Adobe Target through the Experience Fragments integration. Experiences were served from both tools and they had to manage all experiences.

Customer Experience Orchestration

The last jump in this evolution has been to understand that all these tools work together to achieve business goals, and those business goals do not care about tools. Consequently, marketers need to be aware of all the technologies that are involved.

Let’s consider an example: sending an email. Something as simple as that requires, at least:

• Target audience
• Design
• Text
• Images
• Constraints (e.g. timezone, fatigue)
• Metrics
• Reports

Any other digital marketing example will have a similar set of components, which have to be done by people, using multiple tools. No longer can you just limit yourself to a single tool.

In other words, this is a factory, not a workshop, and a factory needs to run like clockwork. It is the same truth that Henry Ford realized more than a century ago. Everybody has a position, requires inputs from others, and their outputs subsequently become the inputs of the next stages. One direct consequence is that you have to understand the full ecosystem, not just your niche. This applies to both technical and business roles.

CXO is basically the consolidation of what I have just explained. It is just that we are giving it a name and formalizing it. Getting into the details, CXO is composed of:

• Customer Engagement: involves gathering all the data needed to personalize the customer experience.
• Content Supply Chain: guarantees that content goes from ideation to realization.
• Brand Visibility: ensures that your brand stays relevant in this changing world.

Moving forward, not only do we all need to know what our role in this factory is, but also what everybody else is doing in it. This is not a theory, my most advanced customers have already started this journey. They have structured their MarTech team with CXO in mind, even if they do not use this term.

Photo by cottonbro studio

Let’s continue with the options to allow AT and AJO offers to coexist.

Only Use AJO for Personalization

If you are running offers on both AT and AJO, why are you managing two systems? Would it not make more sense to use the best tool for personalization?

AJO offers, especially if you choose to go with the latest version, AJO Decisioning, is the most advanced solution to manage offers. You can add start and end dates, priorities, capping rules, qualification rules, and you can use propensity scores in ranking formulas. While you may be able to do the same in AT, you would need to use profile scripts, with its limitations, or complex AT activities.

With this approach, you would use AJO for personalization activities, and AT for A/B tests and all premium features. Obviously, you would not be able to run an A/B test and an AJO personalization activity on the same placement. However, I would argue that, if you want to do that, you have not thought it through well enough.

If this were the absolutely best solution, everybody would be using it, but the reality is that this is not the case. The reason is very simple: AT has the Visual Experience Composer, which makes it much more marketer friendly than AJO. In AJO, you need to generate or manipulate the HTML manually. This is the main drawback of this approach. That being said, I have had customers who had an IT resource dedicated to the marketing team, to manage all technical work like this.

There is another drawback: reporting. With A4T, you have all the reporting done automatically, whereas if you use AJO, you will need to prepare the reporting more manually.

The final major issue is that AJO offers were designed for known visitors. Personalization for anonymous visitors will be challenging, if not impossible.

The Arbitrator

The final and most complex solution is to create an arbitration layer between the browser, AJO, and AT. I can think of two options to develop this arbitration layer:

• Microservice. You could set up a microservice, which would be invoked from the browser. This microservice would then request the AJO offers and AT activities, would evaluate which content should be returned to the browser, and send it back to the browser. The browser would blindly show whatever the microservice sends back.
• JavaScript function. Very similarly to the microservice, this function would request the AJO offers and AT activities, decide which one should be shown, and discard the other one. This code would live in the user’s browser.

Each has its pros and cons, and I do not think there is a clear winner. In both cases, you need to write custom code, which is why I mention this is the most complex solution. The microservice requires extra infrastructure, but it will be faster than doing everything in the browser.

There is one detail that is very important to keep in mind with this approach: the difference between decision and impression. Let me explain.

By default, AT increments the impression counter every time a decision is made to send an experience back to the browser. In other words, AT assumes that all retrieved experiences are shown. Remember that AT and A4T reports use this impression metric heavily. With an arbitrator, not all retrieved experiences will be shown. This poses a problem for AT: the reports will be completely wrong. Fortunately, AT has a solution for this edge case. Since I recently wrote a full blog post on it, I will not cover the solution here and just reference my other post: Conditional Adobe Target Rendering.

The case of AJO offers is different. AJO will always send a record to a system dataset for every decision made. If you want to capture the impressions or the clicks, which are not mandatory, you should send an event back to AEP using a standard eventType: decisioning.propositionDisplay for impressions or decisioning.propositionInteract for clicks.

I know I have skipped many steps regarding this arbitrator. Since it is custom code, the business rules will be different per company, and it is a complex piece of software, I cannot offer a generic solution or sample code. YMMV.

Photo by Astrid Schaffner on Unsplash

A Bit of Background

There is little to no overlap in the scope of most Adobe Experience Cloud tools:

• Although the names are similar, Adobe Experience Platform (AEP) and Adobe Experience Manager (AEM) are worlds apart.
• You can create a website with Adobe Commerce, but if you have AEM, you will likely use the latter.
• AT has its own reporting capability, but if you have Adobe Analytics or Customer Journey Analytics, we prefer to use one of these analytics tools for A4T reporting.

However, with the release of AJO offers, its web capabilities compete directly with AT.

I will be referring to AJO offers generically. For completeness, AJO has two engines, the legacy Offer Decisioning Engine, now renamed as Decision Management, and the new Experience Decisioning, also known as Decisioning. I know, Adobe could have done a better job in naming these two features. I will not differentiate between the two in this post, as the differences do not change the explanations. I also assume that only one of these two AJO offer engines is in use. I strongly recommend against using both simultaneously; here be dragons.

Finally, if you want a different perspective from mine, my coworker Sarvesh has a post on LinkedIn on the same topic.

The Problem

While AT was designed for the web, and it can also be used in mobile apps, AJO offers can be used in any channel that can make API calls. I know, I know, you could, in theory, use AT rawboxes for email open-time personalization, but who uses them these days?

If you have been following so far, you will have noticed that on the web, we can potentially have AT experiences and AJO offers simultaneously. Per se, this is not a problem. However, nothing prevents you from configuring an AT experience and an AJO offer to be shown on exactly the same placement. AJO and AT have no way to communicate in the backend to detect a collision. I do not expect this capability to be built, so we have a conflict to resolve. I would even argue that it is impossible. As a consequence, we have to resolve this collision externally.

Let’s explore what solutions we have at hand.

Mutual Exclusivity

The simplest solution is also the most obvious: use one or the other on a given page, never both at the same time. The most common approach is to use AT on publicly-facing pages, and AJO offers on the private section of the website.

On the one hand, the public section of a website is open to everyone. Most visitors will be anonymous, so you will not have a profile for them that you can use to show them an offer. AT is at its best in this scenario, from A/B testing to Recommendations.

On the other hand, the private section requires authentication. You can now access a profile and use AJO offers to find the best content for the visitor.

The benefits of this approach are obvious:

• Simple governance.
• Separation of concerns.
• Predictability.
• Attribution in AT will be more accurate.

Activity Type Separation

One drawback of the previous solution is that you cannot run A/B tests on the private section of your website. In order to enable this capability, you could take one of the following two approaches.

On the public section of the website, you continue using AT only. Nothing changes here. However, on the private section, you allow AT for A/B testing, and only A/B testing. AJO offers still show offers in the private section. It goes without saying that A/B tests should not be performed in locations where AJO offers are shown.

A slightly different approach is to use AT for A/B testing and AJO offers for personalization everywhere on the website. Again, you will have to define where you can run personalization campaigns and where to run A/B tests, and keep these areas mutually exclusive.

The main advantage of this solution is that you can now run A/B tests everywhere on the web. However, you have to define the boundaries between AT and AJO offers carefully.

Since this post is already quite long, I will continue in the next post.

Photo by Uriel Soberanes on Unsplash

Proposition Impressions

You may think that the easy solution is just to prevent the Web SDK code, which renders the content in Adobe Target’s response, from running. However, it is not that easy, as I will explain below. Before I continue, I want to clarify that this response is usually called a proposition. The documentation uses this word, and so will I throughout this post.

Adobe Target has no way of knowing what has happened in the browser. It therefore considers the returned experience rendered and increases the impression counter for that experience. This counter, in turn, is used to calculate lift and confidence, the two main metrics of Adobe Target. In other words, if we do nothing, in cases where a proposition is not shown and the impression counter is increased, the reports will be incorrect.

Fortunately, there is a solution. Adobe Target can be told not to increment the impression counter automatically. Instead, a different process needs to be followed:

1. Request the proposition from Adobe Target, without incrementing the counter.
2. Decide whether to render the proposition.
3. If the proposition is rendered, send a view event back to Adobe Target.

Web SDK

If you are using Adobe Launch Tags, you have to configure the Adobe Target send event action at the top of the page with these checkboxes.

• Disable “guided events”. By default, Web SDK will try to make your life simpler by only allowing you to configure the typical options. We want to go our own way.
• Disable “render visual personalization decisions”. You can only change this checkbox after disabling guided events.

With these two parameters, you will get the propositions, but nothing else will happen: Adobe Target will not increase the counters, and Web SDK will not show the proposition. Now you have to decide whether you should render the propositions and, if so, render them and notify Adobe Target.

It is beyond the scope of this post to go into the details of how to decide and render the propositions. This will entirely depend on the business requirements for the decision and the structure of your website’s HTML. What I can do is guide you on how to implement it.

The Platform Web SDK tag extension provides a “Send Event Complete” event, which can be used to trigger a new rule when a response from a Send Event action is received. I can think of two options for how to use it:

• If the decision to render can easily be constructed in a rule condition and the rendering is simple:
  • Add the condition to the rule
  • Add an action of type “Apply propositions” and configure it to render the proposition.
• If the decision and rendering require custom code, add a “Custom code” action, where you will add the necessary code to evaluate the decision to show the proposition and handle its rendering. In your code, you will want to use event.propositions to get the response from Adobe Target.

Refer to this help page for more information.

Finally, it is time to report back to Adobe Target whether the proposition has been rendered, which includes activities with Analytics for Target (A4T). This can easily be done using a normal send event action in Web SDK. Since this event is only for sending data, you can try to use the “collect” method:

In the previous screenshot, the XDM data is missing. It must contain the proposition information (the Adobe Target experience details) following this structure:

"_experience": {
  "decisioning": {
      "propositions": [{
        "id": <PROPOSITION_ID>,
        "scope": <PROPOSITION_SCOPE>,
        "scopeDetails": <PROPOSITION_SCOPE_DETAILS>
      }]
  }
}

The values for propositions[].id, propositions[].scope, and propositions[].scopeDetails are just a copy of the values that came from the Adobe Target response. You will have noticed that propositions is an array, in case you have multiple propositions to report on in a single call. Again, refer to this help page for your reference.

Alloy.js

If you are not using Adobe Tags and Web SDK, you will have to do everything above manually, in code. The documentation in Experience League explains it fairly well; you just need to find it, as it is a bit scattered. While I cannot provide boilerplate code, I can provide some guidance. Before I continue, I have to warn you that this code is completely untested.

To get the propositions and prevent Web SDK from rendering them, you will set renderDecisions to false and customize decisionScopes to your needs:

alloy("sendEvent", {
  personalization: {
    decisionScopes: ["__view__"],
    sendDisplayEvent: false,
    defaultPersonalizationEnabled: true
  },
  renderDecisions: false,
  xdm: { /* Your XDM */ }
});

Again, the decisioning and rendering are out of scope for this post.

The last step is to send the display event back to Adobe Target:

alloy("sendEvent", { 
  xdm: {
    eventType: "decisioning.propositionDisplay",
    _experience: {
      decisioning: [{
        "id": <PROPOSITION_ID>,
        "scope": <PROPOSITION_SCOPE>,
        "scopeDetails": <PROPOSITION_SCOPE_DETAILS>
      }],
      propositionEventType: { 
        display: 1 
      }
    }
  }
});

I have used these references:

• renderDecisions
• Process the response from Target
• Manually render propositions
• Manage display events in the Web SDK

at.js

What??? You are still using at.js? You should really consider migrating to Web SDK. Well, I should not be judgmental.

I will not explain how you should do it, as my knowledge of at.js is very rusty by now. What I will share is the following:

• The process is the same as above: retrieve, and conditionally render and notify.
• Use the Adobe Target Delivery API for both retrieval and notification.
• For experience retrieval, you use prefetch.
• For display notification, you use notifications.

Photo by Austin Chan on Unsplash

Before I continue, if you have landed on this page looking for AI tools related to the Adobe Document Cloud or the Adobe Creative Cloud, I am afraid I have very little to say about them. Photoshop is as alien for me as Adobe Experience Platform is for you.

With that being said, let’s get to the heart of the matter. I have classified these AI capabilities in three broad groups: assistants, content optimizers and end user support. In the remainder of this post I will explain each one.

Assistants

Adobe uses the icon to denote an AI assistant. You will see it in multiple places, for example:

• Adobe Experience Platform
• Adobe Journey Optimizer
• Customer Journey Analytics
• Adobe Target

All these assistants have one thing in common: they are meant to help the user of the corresponding tool. Think of them as a virtual intern that takes your orders (your prompt) and works on them in the background. The initial use case was to help you learn more about the tool. However, they are still evolving and, over time, they will do more and more.

Disclaimer: what I am going to explain is not currently available; I am sure it will be in the future. In my wildest dreams, I envision a meta assistant or assistant orchestrator where, based on a brief, it would create every step of a campaign. For example, for an email campaign you would get:

• The email content, including A/B testing and personalization
• The AJO campaign, ready to be activated
• The RTCDP segment for the AJO campaign
• The CJA dashboard for this campaign

Content Optimizers

If you are like me and come from the data world, you may not be that familiar with the content world. We like to think of AEP as the center of our universe. However, once you learn and understand the predominant role of Adobe Experience Manager (AEM), you realize how big the world beyond data is. While I am not an AEM expert, I can tell how it plays a key role in big corporations. All my clients use it as their content management system and it is a central component of their digital marketing stack.

It should be no surprise, then, that Adobe has released AI tools specifically designed for content:

• AEM Sites Optimizer. It analyzes and improves the performance of websites built on AEM. Not only does it audit your website, but it can also apply the changes to AEM to improve it.
• Adobe LLM Optimizer. With the advent of Large Language Models (LLM) and the chat engines in front of them, webmasters want their websites to rank high in the popular LLMs, so that they become the reference of certain prompts. This is called Generative Engine Optimization (GEO). Well, LLM Optimizer was designed with this goal in mind: help websites become the reference of AI chat assistants.

End User Support

You are all familiar with those chat tools that many websites have. They are mainly call deflectors: they try to help end users who have basic questions, so that they can self-serve and do not need to call the client support center. However, the existing chat tools are very basic. Every time I have tried to use one, I have ended up having to interact with a human, as the tool could not do what I needed.

With Adobe Brand Concierge, Adobe is entering this space, offering an AI tool to manage end user conversations. This is one of the rare occasions where the Adobe Experience Cloud offers a tool that is specifically designed for the end users, the customers of our customers (anybody remembers Adobe Survey?). This tool is in its infancy, but if it delivers on the promise, we will finally get a chat that works.

Photo by BoliviaInteligente on Unsplash

Execution is Expensive

While the situation with the house described above is completely imaginary, I have seen this in technology. It goes without saying that they tend to end in fiasco.

I was once assigned to a project, where the customer had already implemented the data architecture of the Adobe Experience Platform (AEP). Schemas and datasets had been created in the production sandbox, they were already loading data, and some destinations had been configured. With this part of the implementation done, they asked the business for use cases. To their horror, very few could be delivered with that implementation. The problem was that the IT department had implemented what they thought was the right design for the data, without ever asking the business team for their input.

After multiple discussions with this customer, we made the hard decision to reset the production sandbox. I actually clicked the button, I felt really bad. That probably was $500k (or more) going down the drain.

Unfortunately, this is not an isolated case; I still see this behavior in some of the engagements I have been part of. IT directors argue that a discovery and design phase is a waste of time and money, that it is just a “lift and shift” and they need to show value quickly. I have bad news for them.

Thinking is Cheap

While I am not in sales, I work closely with them. A typical hurdle they face when negotiating contracts with customers is that architects, business consultants, and digital strategists are expensive. I beg to differ. I am not going to dispute that our hourly rate is higher than that of a developer, but:

• In a healthy project, the number of architect or strategist hours should always be significantly smaller than the total development time. We are in technology, not philosophy.
• Fixing a mistake on a whiteboard or redoing an architecture diagram that does not support the use cases costs a fraction of having to redo an implementation that is not fit for purpose.
• As I have explained multiple times, you must start with the why, and to find this why, you need to spend time thinking before you start developing.

I can understand the anxiety to show value. In my post Buy a Raspberry Pi, I explain how our customers expect a return on their investment when they buy enterprise-grade software like the Adobe Experience Cloud. However, this should not be an excuse to put the cart before the horse.

In summary, and based on my experience, I can confidently say that “thinking is cheap”.

Photo by Andrea Piacquadio

What is Support Shopping?

I do not think that there is a standard definition for this concept. In fact, I heard it for the first time from a coworker not that long ago. Since then, though, I have used it when needed and everybody understood me. If I had to provide such a definition, it would be something like:

The activity of requesting help from multiple people simultaneously, without telling them that you have also asked others.

I am sure you have seen this behavior in the past. Someone has a problem with a technology, and they ask their technical representative and their account manager, and open a ticket with support. I understand why our clients do that: they do not always know who to ask or they are in a hurry and need an urgent response. However, there are important downsides.

The Issue with Support Shopping

The main problem with this behavior is that the outcome can make things worse.

Let’s consider a scenario where a client wants to know what the best color in a particular scenario is. The client raises the question to the provider, asking four different people. Three reply “blue”, which is the one that the provider has documented as the best color, but one outlier misunderstands the question and says “pink”. It turns out that the client wanted pink as the color, as it is the color they already have. So, they go with pink. Later, when it is clear that this was the wrong color, they will claim that it is the provider’s fault, as they recommended pink.

I want to be very clear about one point: the person who replied “pink” is not to be blamed. Any of us could have done it.

The more I work with internal teams at Adobe, the more I understand the origin of this problem:

• Client Care manages dozens, if not hundreds of tickets daily. Very few are problems with the Adobe products, most are related to issues with the client implementation. They do not have the knowledge or the time to research the exact details, and will mostly fall back to the published best practices.
• Customer Success Managers (CSM) are mostly non-technical employees. They understand the technology at a high level, but their role is about value realization, not Java code.
• Account Directors (AD) lead the sales team, not the implementation team.
• Technical Account Managers (TAM) are technical and have the knowledge to support the customers, have access to backend tools, but they are not always asked first or may not have been exposed to the context needed to answer correctly.
• Consultants usually know the technical details of the implementation and most likely they have the best answer, but not all our clients have a consulting engagement.

My Solution

OK, we have a problem. What do we do about it?

The starting point is to avoid support shopping altogether. Instead, a process should be agreed with the technology provider. I cannot provide a generic process, as there are too many permutations and I have only seen what we do at Adobe.

What I can explain is what I have done with some customers, where I have been involved as an Enterprise Architect.

1. All issues should be routed first to me or the TAM. We are in the best position to evaluate the problem.
2. If this is something we (EA or TAM) can resolve, we just go ahead and do it.
3. If we need someone else, but we know who this other person should be, we engage them.
4. If the problem is related to not having a license, we will talk with the AD.
5. Finally, if we see this is a product issue, we will help the client open a ticket with Client Care, making sure this ticket has all the relevant information, and we will follow up with Client Care.

Let me know in the comments if you have seen this behavior or you have implemented a different solution.

Photo by Jezael Melgoza on Unsplash

Friction Point

The reason why I wanted to write this post in the first place is to clarify the unnecessary friction that integrating AEP with the rest of the ecosystem has caused. Some of my previous customers had an expectation that this tool can connect to any data source or destination seamlessly, without any additional development.

AEP, like any other advanced software, was built to be as generic as possible. We have thousands of customers, each with a completely different setup. It is impossible to build a piece of software that supports every single case.

As I was preparing this post, I remember my days with Adobe Analytics and Adobe Audience Manager, when this was not a major issue. I guess that, since these tools were very specific and simple compared to AEP, such an expectation did not exist. I also assume that Adobe Experience Manager (AEM) requires a large implementation, which allows for developer time to create any custom integration.

Out of the Box

Let’s start with the out-of-the-box integrations that already exist. AEP boasts a large number of data sources and destinations.

The catalog has dozens of integrations; I stopped counting a long time ago. Some of the categories that you will see are:

• Other Adobe applications
• Advertising platforms
• Cloud storage
• CRM platforms
• Databases

Expect more to be added and feel free to suggest new ones to your Adobe representative.

Most of my customers have all they need in the existing catalog. If you find one that suits you, just go ahead and use it. However, be mindful that you cannot change the behavior other than what is available in the configuration wizard.

Custom Integrations

This is where the friction I mentioned at the top arises. I have had customers who were annoyed with me when I told them that the integration they wanted to set up was not possible. I would argue that nobody should be surprised when licensing SaaS tools as complex as AEP, when a custom layer needs to be built. In other words, my point is that, if you are implementing AEP, you should expect some level of custom integration, which will require development effort.

These are some examples I have seen where a custom integration was needed:

• Source data format needs to be adapted to XDM format to take full advantage of AEP’s features.
• Connecting to a data source needs to follow a particular security standard not currently supported.
• AEP sends the data too fast to a destination.

The solutions I have seen in the past can be grouped into two groups: ETLs and microservices. Let me know in the comments if you used other approaches.

ETLs

Extract-Transform-Load (ETL) tools have existed for a very long time. With them, you can adjust the format of a data source to the format expected by a destination. I do not have the numbers, but I believe that most AEP implementations use ETLs to extract marketing data from internal systems and convert it to XDM or CSV format to be ingested by AEP. The main limitation of an ETL tool is that it usually only supports batch processes.

I would assume that all my customers would have, at least, one ETL tool. To my dismay, I have had customers who refused to use one.

Microservice

I am using here the term “microservice” very loosely. I am referring to a custom development that receives data from a source and does all the necessary adjustments so that the destination can receive the data. I know it sounds like an ETL, but there are a couple of major differences:

• Microservices can support real-time use cases.
• Microservices can do anything that you can do with a programming language, which is more than what ETLs can usually do.

Let me share a few examples of microservices my customers have needed:

• The HTTP API connection was sending the data too fast and in bursts, causing the downstream system to crash. This destination was designed to be as fast as possible, so it is not possible to make it slower. The solution was to build a microservice with a large buffer, to adjust the speed.
• An Adobe Journey Optimizer (AJO) journey required accessing data in a way that AJO custom actions could not support. A microservice was created, which would receive a call from a custom action, retrieve the additional data, and send it in an event back to AEP, which was captured by the journey.
• AJO Custom Actions send calls individually, whereas a particular receiver end required microbatching and a slower rate. A microservice took care of this mismatch.

In summary, with AEP (and, I assume, with our competitors), you should always expect to develop a connecting layer around AEP.

Photo by John Barkiple on Unsplash

Life

I think that most of us can agree that the political situation all around the world has seen better days. Most big and influential countries have had their fair share of drama. I have lived in three countries and all three have major issues. While it would be great if I could ignore all those problems, it is impossible, at least for me. I guess I worry too much about what would happen if things go really wrong.

My work at Adobe is going well. Looking back into this year that is ending makes me realize how much I have learned. I feel more and more confident in my role as a manager (part-time), and I like working with my customers, with whom I have a very good working relationship. I still go to the office three days a week, which gives me the opportunity to meet my coworkers.

The most significant change that I have noticed is the continuous disruption caused by AI. I can see how knowing the technology behind AI can have an impact. In fact, I recommend that you learn AI as deeply as you can. I have understood neural networks for many years, but the AI tools we have today go way beyond neural networks. Being an expert in prompt engineering will help you with your day-to-day, but if you want to be more employable you need to understand how LLMs work.

I have some vague knowledge and, to catch up a bit with this technology, I have just purchased a new computer with a powerful enough processor and lots of RAM, so I can play with Ollama and other related tools. I do not think I can ride the AI wave, but at least I will be able to take more advantage of it.

For us working at Adobe, not only do we need to know how to use conversational AI tools, but also know how our own AI tools work: Firefly, AI Assistant for Acrobat Studio, or Adobe Brand Concierge. I have seen parts of the architecture behind the latter and it is anything but simple.

Blog

I always want to talk about my blog, as it is an important part of my life. I usually publish every two weeks. It is a lot of effort. For context, a standard post takes around four hours. If I want to make it more complex, with code examples or steps in the UI, it will take even longer. I wish I had more time to write more often.

Metrics

Let me share a few metrics with you:

I was expecting this drop in numbers, so I am not concerned:

• Most of 2025 was flat, except for something weird around October. This means a steady flow of visits, which is what I would expect.
• The metrics in 2024 showed an increase in traffic that did not make sense.
• We should all expect decreases in organic traffic, as AI becomes more prevalent. My customers have already noticed it.

Countries

The top 5 countries are the same as last year:

1. Singapore: 31.3%
2. United States: 26.7%
3. India: 14.7%
4. United Kingdom: 3.4%
5. Canada: 3.2%

Surprisingly, Singapore is still at the top. I assume that many people are using a VPN that exits through this country, otherwise I cannot believe that such a small country brings more traffic than the U.S. Where could these visitors come from? China?

Traffic Sources

To me, this is the most interesting report to evaluate in 2025. As I said above, AI is replacing search engines at a slow but steady pace. I can already see it in the traffic sources report:

1. Search Engines: 45.9%
2. Types/Bookmarked: 40.5%
3. Social Networks: 9.4%
4. Other Websites: 4.0%
5. Conversational AI: 0.3%

These are the OOTB Adobe Analytics classifications and it is important that you understand them:

• Adobe only added “Conversational AI” in the last few months.
• Before adding “Conversational AI”, those tools showed up under “Other Websites”.
• Search engines often show an AI-generated response to your query; if you click on it, the referrer will still be classified as “Search Engine”.

The good news is that conversational AI tools believe that my blog is a reliable source of information.

Looking into 2026

I hope that the new year comes with more positive news. As I said above, I am not very happy with how 2025 has behaved.

For this blog, I will start posting more about AI in relation to Adobe technologies. I need to learn more and, as I do, I will share my knowledge with you. That being said, I want to mention that, in my humble opinion, there has been too much hype around AI, and I am not the only one thinking along these lines.

Happy 2026!

Photo by BoliviaInteligente on Unsplash

Page Views

In traditional websites (i.e., those that do not use any SPA technology), every page view is a full page download. After clicking on internal links, the browser unloads the previous page, releasing all the resources, and loads the new page. From a technical perspective, it is very clear what a page view is, and you can easily configure Web SDK to send data with every new page view.

However, with SPAs, only the first page is a full download. All subsequent clicks trigger the download of only the content specific to the new page. The rest of the page stays the same: menu, header, side bars, footer… In other words, while the end users feel like they are moving from page to page, technically, the browser does not unload any pages nor release any resources, and thinks it is always on the first page. Page view events are sent to Adobe Analytics or Adobe Experience Platform Edge based on arbitrary rules included in the SPA controller, typically when more than 50% of the content of the page changes.

This behavior has a direct impact on the page metadata, in particular, the previous URL or referrer, which is accessible through document.referrer. Web SDK uses this parameter for the previous page URL.

In the case of traditional websites, this parameter is automatically updated with every page refresh, and, as expected, it holds the URL to the previous page. However, in SPAs, since the browser only fully loads the first page, the referrer does not get updated again with every click.

The Attribution Problem in SPAs

Let’s consider a scenario with the following Adobe Analytics Marketing Channels rules:

Next, consider the following chain of events from an end user perspective, where the website is an SPA:

As you can see, on the landing page, the marketing channel was correctly identified, but it then gets updated to a wrong value from the second page onwards. Any conversion further down the line would then be attributed to “Natural Search”, when it should have been attributed to “Paid Search”.

If you think that Adobe Analytics has enough information to know that it is an internal link, think again. Consider this alternative series of events:

With this new scenario, although events 5 and 6 should not carry any marketing channel value, the value they get is actually correct, and attribution would be fine. However, the crucial question is: how can Adobe Analytics know the difference between this example and the one before? It cannot. They both look exactly the same, as Google does not send any data to Adobe Analytics.

This problem does not exist on a traditional website. The clicks on internal links will carry the correct URL in the referrer. They will be correctly identified as internal URLs and will not generate new Marketing Channel values. I want to also clarify that this explanation refers to last-touch attribution; first-touch attribution should always be correct.

The Solution

Ideally, you would want to tweak the Marketing Channels rules to deal with this scenario. Unfortunately, this is not always possible. Marketing Channels rules only evaluate the current hit, with no context of previous hits. Crucial information needed to correctly identify the marketing channel is present in these previous hits. For example, in event 3 of the second table above, the Marketing Channels engine only sees that the referrer is Google.

The best solution is to modify your Web SDK implementation, either manually or through Adobe Tags. Your rules should keep track of the previous page that was shown and use it to populate web > webReferrer > URL (see the Web Details field group) with the correct, internal URL. If you use Adobe Tags, you will probably need a Data Element.

For more information, read this Experience League post: Web SDK Part 4: Avoiding Banana Peels (Banana Peel #6).

Photo by Alex Bertha on Unsplash

As usual, since I have been writing about the Adobe Experience Platform (AEP), I will use the following diagram as reference:

And just to set the stage, today I will describe the “Profile Store” and the “Identity Store” boxes in the previous diagram.

Unified Profile Service

This is the simplest of the two, but before I get into the details, I will start by explaining what it is not. It is very tempting to think that this is a relational database where each row corresponds to a profile, with the columns being the schema parameters. Let me assure you that this is not the case. There is no SQL database behind the scenes, nor are we issuing SELECTs, UPDATEs or INSERTs. If this were the case, profile collapses would be totally unsolvable, whereas in reality, there are various solutions.

Instead, you have to think of UPS as a store of fragments, which behaves as follows based on the type of dataset:

• Profile datasets: it keeps the last update received from the data source, for each primary identity.
• Events datasets: it keeps all events whose TTL has not been reached.

All these fragments are keyed by their primary identity. Think of it as a key-value pair database, where the key is the primary identity and the value is an array of fragments. This is why it is so important to decide on the primary identity in a schema: it will be the key used to find fragments in UPS. The same applies to the primary field in the identityMap.

You can also see how time plays a role: as new profile fragments are received from data sources, previous fragments are deleted, and every day, events whose TTL has been reached are deleted. Remember that the Data Lake keeps all data until the batch is deleted.

I want you to pause and see how in this database, a fully formed profile is nowhere to be found. All you have are scattered pieces of information.

Unified Identity Service

Now that we have all the previous fragments, how do we know which need to be combined to project a profile?

If there is only one identity involved, the solution is simple. However, in scenarios where there are multiple identities associated with a single profile, we need a place to store linked identities. This is the role of the UIS. Think of it as a specialized storage that keeps track of namespaces, identities, and links between identities. I like how HubSpot depicts this identity graph:

In AEP, you can view many details of UIS in the “Identities” menu:

While UPS cares only about primary identities, UIS wants to know about additional identities, those not marked as primary. As records are ingested from data sources, UIS takes the following steps:

1. Checks that the primary identity is present; if it is not, rejects the record.
2. If there is an additional identity:
   1. If the identity is already in another graph in the database, both graphs will be collapsed into a single graph.
   2. If the identity is new, it will be added to the store and linked to the primary identity in the record.

You will have noticed in the screenshot above that the minimum size of the identity graph is 2. Although you could have, theoretically, a graph with just one node, it does not make sense to store it. Only when two or more nodes are required is a graph created. As a consequence, 2.b above may also create a new graph.

UIS keeps track of where the links between identities came from and when these links were stored in the graph. This key feature has two consequences:

• If you delete a dataset or a batch in a dataset, all links between identities that were formed from this dataset or batch will be deleted. I have built solutions around this capability to un-collapse profiles.
• The Identity Graph Linking Rules feature could be implemented, as it can detect the age of a link between identities.

Where is the Profile?

So, we have fragments and identity graphs, not profiles. However, we always talk about a profile. How do we get it?

I will not explain it here, as I wrote a blog post where I described the process step by step: profile projection. I recommend that, if you have not read it, you do so now. Both posts will make a lot of sense when read together.

Photo by Monstera Production

Summary of the Past

Before I explain what is changing, I will start with what I have seen in the last few years.

One of the approximately 200 ranking factors that Google uses in its ranking algorithm is page load time. Let me repeat that again: only one out of ~200 parameters that Google considers in its algorithm is the time the page takes to load.

This has led hordes of zealots to take full control of websites and demanded major changes to achieve some absurd number. These people would not try to find compromises. The consequences have been noticeable in digital marketing: the capability to personalize websites without flicker has diminished. I have been in my fair share of battles with them and I was never able to win. 😞

I never believed that such extortionate measures were positive. I agree that a website that takes 10+ seconds to load on a desktop connected to a fiber connection offers a very bad experience. However, those 10 seconds on a patchy 3G connection are to be expected. All my customers are well-known companies, who are usually searched for by name. In this case, the brand is so strong that a slightly slower website would not be noticeable in the search results. In other words, site speed, while necessary, is not a deal breaker.

The New Kid in Town

In the last few years, generative AI has taken the market by storm. So much so that one of the immediate consequences has been that organic search traffic to websites has dropped significantly. People are changing the way they search for information, especially the younger generations. Instead of using a few, carefully selected keywords in a search engine, you now describe your problem in detail and the generative AI platform replies with all the information you need.

The first consequence is that fewer prospects, although more qualified, will land on your websites. With search engines, we had to manually check multiple links until we found what we wanted. Now, the generative AI tool of choice will do that for us automatically by reviewing multiple pages. Only when the prospect is ready to take the next step, they will click on a reference to your website.

Another consequence is that this new technology will force a change in how digital marketing teams distribute their budgets. There is a new discipline that will soon become a significant part of those marketing efforts: Generative Engine Optimization (GEO). Not only will you want your website to score high in search engines, but you will also need to be the reference used by Large Language Models (LLMs) when providing a response to a prompt relevant to your business. Adobe has just launched a product called LLM Optimizer precisely with this goal in mind. As a clarification, LLMs are the backbone of generative AI tools.

My Point of View

In my opinion, and given all that I am seeing and my experience, this is what I expect for the near future:

• Content will still be king. That was an expression used with SEO, but with GEO, it will even be more important. Quality content is what an LLM will use to select a website.
• While Gemini and other LLMs rely on Google data, and thus, page speed will still matter somewhat, not all successful engines will use Google’s index.
• LLMs have a different set of parameters to evaluate whether a website is relevant or not. I doubt page load time will be one.
• There will be a tension between SEO and SEM on the one side, and GEO on the other. I expect GEO to win.
• Page speed will always be important, within reasonable expectations. However, the pursuit of perfect Google Lighthouse scores will become irrelevant.
• The aggressive approach that many companies have taken to achieve these perfect scores will have to be backtracked to allow personalization and optimization tools to do their job.

In summary, being able to use all digital marketing tools at their full capacity to increase conversion will be more important than ever. Companies will have a smaller window of opportunity to convince a new visitor to stay and convert.

What is your point of view? Will we still have to battle with impossible page speed requirements or will we get back all the tools we need to convince prospects?

Photo by Tom D’Arby

Profile Projection

Unless you know very well how a profile gets projected, before you continue reading this post, I highly recommend that you read my post on profile projection. The summary of the process is:

1. A profile is requested for a given identity.
2. The identity graph is queried to get all identities linked to the one provided.
3. The profile store is queried to get all the fragments with these identities.
4. The fragments are combined following a set of rules.
5. The projected profile is returned.

In the rest of the post, I will refer to “step [X]”, where X is one of the steps in the process above.

Although I only briefly explained it in my other post, merge policies govern this process. So much so that one of the parameters of the first step is the merge policy to use. Let’s see how this functionality works.

ID Stitching

One of the parameters that you have to configure when creating a new merge policy is how identities are stitched.

None

With this value, the profile projection process completely skips step [2] (querying the identity graph). Yes, I know, it sounds weird, especially when one of the main features of the Adobe Experience Platform (AEP) is to stitch identities. However, in some scenarios, it can be very useful.

Let me try to explain it differently, as I am sure some may not have understood it. When you set “ID Stitching” to “None”, and you project a profile, the algorithm will only use the identity that you have supplied in step [1] to look for profile fragments in step [3].

A typical use case when this value becomes very useful is for some scenarios of profile collapse. Sometimes you do not need the full profile, only the profile fragments that have been submitted with one of the identities. In a way, with this approach, you “uncollapse” the profile. Remember that the profile is not stored anywhere; the profile store only keeps fragments.

Private Graph

This is the default value. In step [2], the algorithm makes a call to the identity store. The identity store subsequently returns all other identities that have been linked to the identity given in step [1].

Default and Edge

Let’s move on to the next two parameters.

Default Merge Policy

There always needs to be a default merge policy, which is the one that will be used if, in step [1], no merge policy is supplied. AEP provides one, but you can change it to one of your own.

Active-On-Edge Merge Policy

When the AEP Edge Network requests a profile to the core, the process is no different, and it also has to supply a merge policy. It could use the default merge policy, but you have the flexibility to use a different one, if your use case requires it. Since the Edge Network Server API does not have the capability to supply a merge policy, you have to predefine it.

Merge Method

The next configuration parameter that you need to set is the merge method.

This method governs how step [4] works. The output of step [3] is a bunch of fragments. However, fragments can overlap; that is, some attributes may be present in multiple fragments. If this happens, which fragments prevail?

Timestamp Ordered

All fragments include a timestamp of when they were last updated in AEP. If you select this option (the most common), AEP will choose the fragment with the timestamp closest to now, irrespective of where it came from. This is the most common option; in fact, I have not seen any customer use the next value.

Dataset Precedence

Instead of relying on the last fragment update to take precedence, you define a priority of datasets. So, if there is a collision between fragments, AEP will choose the one coming from the dataset highest in the hierarchy.

This capability can be useful when you have datasets coming from various sources, some more reputable than others. For example, you may be ingesting data from your CRM and from 3^rd-party data providers. If there is any overlap between these data sources, you will likely want your own data, which you control, to take precedence over other sources, which are out of your control.

When you select this option, the UI shows you the datasets, which you have to choose and order. You have to do it for both profile and event datasets. One feature that you also get with this option is that you can leave out some datasets from this merge policy. In other words, you can create a merge policy that will only show a partial profile. I am not sure when I would leave out datasets, but it is always good to have options.

Usage

OK, now you have your shiny, custom merge policies. How do you use them?

Profile UI

The first place where you can use them is when you want to browse some profiles in the UI. You may have already noticed that the first parameter is the merge policy, although you probably have ignored it so far. You can remove the default value and select a new one. I find this option very interesting to see how different merge policies generate different profiles.

Segmentation

While the profile UI has its uses, when you can really take advantage of merge policies is in segmentation. This means that, when evaluating segments, the profiles sent for activation will be generated by using the selected merge policy.

In order to configure this parameter, in the new audience interface, you should see a gear icon. I had never used it until now. When you click on it, you get a few configuration parameters, one of which is the merge policy.

Profile API

Being AEP API-first, the Profile API also supports passing a merge policy. In fact, if you read the documentation under “retrieve an entity”, you get the following explanation:

Additionally, usage of the following query parameter is highly recommended:

• mergePolicyId: The ID of the merge policy you want to filter the data with. If no merge policy is specified, your organization’s default merge policy will be used.

Photo by Markus Winkler

Conversion Funnel

I am sure you are all familiar with the typical sales or conversion funnel. There are many ways to show it, and it differs between business-to-business (B2B) and business-to-consumer (B2C). In the B2B world, Marketo will be at the center of most marketing activities.

In this post, though, I will explain a B2C case, as I am more familiar with it. This is a typical B2C conversion funnel:

And it is a funnel because, as you go from top to bottom, there are fewer people in each section.

Let’s go step by step and identify what Adobe tools I believe belong to each one.

Top of the Funnel: Awareness

At the top of the funnel we find the awareness state. I like the definition of this stage that I found on this post:

This is where potential customers first become aware of your brand or product. They might not be actively looking to buy anything yet, but you want to make them aware of your existence and pique their interest.

Since you know nothing about them and they do not know your company, you have to fish them outside of your properties. Your options with Adobe tools are:

Middle of the Funnel: Interest & Desire

Now you have piqued the interest of a potential buyer. They have found you somewhere in the wild Internet and they have clicked a link that takes them to your website. Now it is your opportunity to show that you are their best option.

The difference between these two steps is subtle, and many combine them into one step. However, you could say that interest is just curiosity and research, while desire shows an appetite to buy your products or services.

At this stage, you can use these Adobe products:

Bottom of the funnel: Action

You will also see this stage named conversion. This is when the customer finally opens their wallet and buys your products or services. I know that there are some cases where the action is not necessarily paying for something, but the tools needed to manage it remain mostly the same.

This is my selection:

Retention

So, someone has taken the action that you wanted. Congratulations!

However, is that the end? Absolutely not! Now you have to keep making this customer happy and, in the future, when they want to buy similar products or services again, they buy from you. And here you have an ace up your sleeve: you already know who they are and what they like. You can, and should, be using this information to your advantage.

All your Adobe tools are there to support you:

And this is my list. What is yours?

Photo by Anton H