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.

My hope is that, in the future, AJO will have its own Visual Experience Composer and an equivalent of A4T, so this gap will close and AJO will become the main tool for personalization.

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

First Things First

Once you have the requirements ready, all Adobe Experience Platform (AEP) implementations must start with the identity strategy. Let me repeat that: do not take any further step in AEP until you have a long-term design for the identities that you will use in AEP.

I know how tempting it is to start designing a data model, logging into AEP, and creating schemas and datasets. However, you should begin on paper or a whiteboard. I also know how stressful it is to see a project delayed because of something so basic. Believe me, it will be time well spent. Modifications on paper or a whiteboard are incredibly cheap. Resetting the production sandbox can be very expensive, not because of Adobe’s cost but because of the amount of work that goes down the drain.

Remember one thing: once you have configured AEP identities and enabled schemas and datasets for profile, there is no going back. You are stuck with your decisions. If you later realize that you made a mistake in your design and have to start from scratch, you will need to reset the sandbox you were working on.

In the most complex AEP implementation I have ever had, we spent a significant amount of time discussing the identity problem while the project was still in the red. This customer had a very specific setup, which needed a complex solution. It took weeks of discussions, learning all their cases, ensuring that the customer understood AEP identities, and going back and forth with various solutions. I managed to come up with a design that mostly satisfied their requirements, and I am proud to say that they are still using it to this day.

Number of Identifiers

While designing the strategy, one parameter that you will have to consider is the number of identifiers. At a minimum, you will have two: the ECID and one person identifier.

However, there are many cases when there will be more than one person identifier:

• Different business units have their own Customer Relationship Management (CRM) tools.
• Data sources may not all have access to the CRM and manage identity in different ways.
• Data coming from third-party data providers will have their own ID.
• The CRM ID is not available on the web data layer and a different ID is used only for the web.

My recommendation is to limit the number of identifiers to a minimum.

Throughout the rest of this post, I will only refer to the person identifier. The ECID is already provided by Adobe. If you are using its cousin, the FPID, remember that it is converted into an ECID internally.

AEP engineers usually refer to the ECID as the “durable ID”, while referring to the person identifier as the “transient ID”.

What Makes a Good Identifier?

Not all identifiers are created equal. Some are good, some are bad, and sometimes you have to use ugly ones.

The Good

The best identifiers are those that you control. The typical example of this type of identity is a CRM ID. I expect all companies, big or small, have a CRM. In this system, for every customer, there is an entry in a relational database with a primary key. If you do not want to expose this primary key, you can always hash it or generate a UUID per customer, which would become another column in the CRM database.

Next are other identities that you do not control but have a high degree of confidence they will be unique: an example could be a credit card number. While they can be recycled, combined with the expiration date, the resulting value is unique. As a side note, never use clear-text credit cards in AEP; always hash them first before sending them to AEP.

The Bad

At the other end of the spectrum, we have the bad identifiers. Let me start with the first on the list: email address. I am well aware that this is bad news for many who have relied on this identifier. If you are reading this blog, you are fairly tech-savvy and consider your email address as part of your personal identity. Unfortunately, the reality is that email addresses are shared:

• It was a surprise to me when I started hearing about spouses sharing the same email address. I have a close relative who does that and I still do not understand it.
• Parents create online accounts for their children, using the parent’s email address for convenience.
• Grandchildren manage their grandparents’ online accounts, and just like the parents above, they do not want the hassle of having separate email addresses.
• The most extreme case I heard was a football (soccer if you are in the US) club, where they had many fan associations. It was common that the leader of the association would manage the members’ accounts and, again, to avoid multiple email addresses, they used one for all accounts.

If you were thinking of phone numbers as a better alternative, the situation is even worse. Mobile operators recycle decommissioned numbers. I even have personal experience with this case.

In summary, any identifier that you cannot control or cannot guarantee will be unique should be avoided; here be dragons.

The Ugly

More often than I would like, I have had customers who did not want to come up with a good identifier. And I say “did not want” because there were options to get to a good identifier, which they refused for various reasons. The typical excuse is that they expected AEP to take care of their identities. The reality is that AEP is not an identity provider nor an MDM tool.

In this case, there are some ugly solutions you can try:

• Combination of parameters. Theoretically, it could be possible to concatenate two or more parameters to get a unique value. I have suggested it multiple times but I have yet to find a situation where this has worked.
• Accept the limitations. Some customers, especially in retail, may accept some profile collapses, as long as the number is manageable.
• Exclude conflicting profiles. In some cases, you could remove all those profiles that you know have shared identities or only load one. As long as you do not use Adobe Journey Optimizer, that may be a good solution.

Pick your poison.

Configuring AEP

So, now that you have come up with a robust identity strategy and have documented it, you can turn to AEP and start configuring it.

The first step is to set up the namespaces. Think of an identity namespace as a separate database for a specific type of identifier.

1. Navigate to the Namespaces page. You will see that there are already a bunch of namespaces created, including the ECID.
2. For each namespace that you need, create a new one. Give it a name, an identity symbol (no spaces or special characters), and select “Individual cross-device ID”.

Now that you have the namespaces set up, you can configure your schemas. Each schema should have:

• One or more identifiers. If you have many, I suggest that you create a field group for them. Otherwise, find a sensible place in the XDM hierarchy.
• One identifier must be set as primary, which means that it will be mandatory in every record. AEP will throw an error if a record does not have the primary identity. The rest of the identities will be optional.

IdentityMap

There is one exception to the previous step: the schema for the event dataset coming from web or app. While you can still set a field as an identity, it is recommended that you use the identityMap field group. As its name implies, it is a map, so you can pass multiple identities in it.

While browsing anonymously, you will only have the ECID, so this field will look like:

{
  "identityMap":{
    "ECID":[
      {
        "id": "83238819066235616291057085344313877718",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

After logging in, it will look something similar to:

{
  "identityMap":{
    "ECID":[
      {
        "id": "83238819066235616291057085344313877718",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "personID":[
      {
        "id": "cd578d2c-12bd-47e8-9fdc-5f9bf31aaab0",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Let me explain what you see above:

• The fields under the identityMap object are namespace identity symbols.
• The namespace identity symbols are arrays. In other words, you can have multiple identifiers for each namespace. I have yet to see a use case where more than one identifier is really needed.
• The id field is the identity for that namespace.
• There must only be one identity with "primary": true. Typically, it will be the ECID while browsing anonymously, and then switch to your person identifier after logging in.

I hope I have answered most of your questions. I know I have not covered everything, but if I did, this post would take forever.

Let me know in the comments what you would want me to address in future posts.

Photo by Barthelemy de Mazenod on Unsplash

Recap of SEO

Before I talk about the main topic, I want to make sure we are all on the same page. If you have never heard of SEO or Search Engine Optimization, Wikipedia defines it as:

Search engine optimization (SEO) is the process of improving the quality and quantity of website traffic to a website or a web page from search engines.

When you type something into a search engine, its algorithm selects, from all the web pages it has indexed, those that are most likely to provide the information you are looking for. For example, if you type “apple”, what should the results show?

• The tech company
• The record label
• The fruit
• A combination of the above

Google claims that it uses more than 200 ranking factors to decide what results to show.

The goal of SEO is to make sure that the combination of those 200 factors scores the highest number possible for your website, so that pages in your website show up in the first few places of the search engine results page for searches that are relevant to your company. I am sure that you can now see why it is complex and expensive.

Generative AI

Using search engines requires that you click on a few links on the results page until you find what you were looking for. Most of the time, the first three to five results will get you exactly what you want. However, sometimes none of the results gets you the information that you are looking for. This often happens to me when my search phrase is long and very specific.

With the advent of generative AI and, more specifically, conversational AI tools like ChatGPT, Copilot, or Gemini, you can now ask complex questions, and the engine will reason and provide you with a full response, all of it without having to leave the same UI. It will also provide the most important references it has used to provide the response, but there is no need to visit those references. No wonder that people are switching from search engines to these new tools. The first consequence, which can already be seen by many companies, is that traffic from search engines has started to decline.

I highly recommend this Forbes article if you want to dig deeper.

As a side note, I agree with Yuval Noah Harari that this new set of tools can be very dangerous for our freedom. With search engines, you got ten results per page and you had to process the results. With generative AI tools, you get only one response with everything you asked for. Whoever controls that response controls the narrative.

The Birth of GEO

I am sure you are now seeing where I am going. If SEO was needed to keep your website at the top of search engine results pages, now that generative AI is with us, you need to make sure that your information is what these tools use to compose the response. This is what we call GEO.

I have tried to find a clear definition, and the one that I like the most states:

Generative Engine Optimization (GEO) is a developing discipline focused on increasing the likelihood that individuals, brands, services, or resources are cited organically in responses generated by large language models (LLMs) such as ChatGPT, Gemini, Claude, and Copilot.

To me, the most important word in the previous definition is developing. It is very early on and there is not enough research and information about it. However, it starts to be clear that a new discipline and area of expertise will emerge. Everybody will want to have their website as a reference in a generative AI response. Since these responses often include links to the references, visitors can go to the website for more details or to transact. Otherwise, if your website is not picked up by generative AI tools, your website will become invisible.

Part of Marketing Strategies

I usually start my posts with the why. In this post, I will end with it because I thought it was more important that I first provided the context.

The reason why I wrote this post is to make you all aware of this emerging trend and the impact it will have on digital marketing.

First, companies will likely have to allocate marketing budget to GEO, just like they have been investing in SEO. I am not saying that SEO will go away, at least not in the short term. Investment in SEO will still be needed; it is not free. What I am saying is that digital marketing budgets will now have to include a part for GEO. Companies may need to purchase tools like Adobe LLM Optimizer and pay GEO experts.

Second, companies will want to track the results of their GEO efforts, just like we have been tracking the results of traditional marketing activities (paid media, social, SEO, email, etc.) for the past 20 years. Adobe Analytics excels at it thanks to the Marketing Channels reports. In case you did not make the connection, the “Natural Search” value in the reports is the most approximate way to track SEO efforts. Very soon we will all have to reconfigure these reports to start tracking GEO results.

I know it is still too early to see where GEO will go, but I recommend that you keep an eye on it.

Photo by Google DeepMind

What is a Non‑Profile-Enabled Dataset?

In AEP, data lands in the Data Lake after being ingested or generated. From there, you may choose to project certain datasets into the Real‑Time Customer Profile (RTCP) by enabling both the schema and the dataset for profile.

Any dataset not projected to RTCP is a non‑profile-enabled dataset. It still lives in the Data Lake and can be fully leveraged by many other tools, such as:

• Customer Journey Analytics (CJA)
• Data Distiller
• External BI tools via the Postgres/BI connector

To clarify, most datasets—including those that are profile-enabled—reside in the Data Lake.

Why Keep Some Datasets Out of RTCP?

You know how much I like to start with the why. Here are several reasons to keep certain datasets only in the Data Lake:

• Cost control. The profile store and identity graph are expensive. Enabling large datasets for profile will increase your license cost.
• Performance. Loading data into RTCP is resource-intensive. The fewer datasets you enable for profile, the faster ingestion will be.
• Data not used for activation. If the data will not be used in segmentation or personalization, it does not belong in RTCP.
• Development and testing. You should never enable a schema or dataset for profile without thorough testing in the Data Lake.
• Raw datasets. Sometimes a dataset contains too much information, when only part of it is needed for profile. In such cases, the raw dataset should remain outside RTCP and can later be refined into a smaller, profile-enabled dataset.

Core Use Cases

Use in Customer Journey Analytics

CJA data connections are established directly with the Data Lake, not RTCP.

It is common to duplicate data from a single upstream data source: one version, with only the attributes required for activation, is sent to a profile-enabled dataset; another version, with the attributes needed for reporting in CJA, is sent to a non-profile-enabled dataset.

Use in Data Distiller

A full post would be required to explain everything Data Distiller can do. If you have a license, you are probably already putting it to good use. Query Service (the service behind Data Distiller) works exclusively with the Data Lake.

This means that whenever data is intended for Data Distiller but not needed in RTCP, the source datasets should remain non-profile-enabled.

Typical scenarios include:

• Derived datasets for profile. A large dataset is ingested into the Data Lake, but only certain attributes are needed in RTCP. A SQL query can extract those attributes and write them into a new dataset that is profile-enabled.
• Derived datasets for export. Sometimes a custom dataset is required for export. By using the same procedure, you can then map the output dataset to a cloud destination. In this case, the output dataset will generally not be enabled for profile.
• Audience creation. You can also create audiences with Data Distiller. This works similarly to the above examples, where a SQL query selects identities which are then used to build an audience.

For more insights, see the Adobe Summit 2025 session S656 - Top Tips to Maximize Value with Adobe Experience Platform Data Distiller.

Profile Snapshot

Every day, the contents of RTCP are copied into a dataset. You can identify this dataset by its name:

Profile-Snapshot-Export-<UUID>

Naturally, this dataset is not profile-enabled. Its common uses include:

• serving as input to Data Distiller, or
• exporting to a cloud destination.

Non-profile-enabled datasets are just as important as profile-enabled ones for keeping your AEP implementation balanced, cost-efficient, and high-performing.

Let me know in the comments if you have seen other interesting use cases for non-profile-enabled datasets.

Photo by Quang Nguyen Vinh

Pre-Requisites

To understand the solution, you first need to understand how AEP works internally. There are two main concepts that are prerequisites to the explanation in this post. I recommend you review them if you are not familiar with these concepts before continuing.

• AEP Identities, in particular the concept of namespaces.
• Profile Projection, especially how the identity graph is used.

How Identity Graph Linking Rules Work

The concept behind this feature is very simple: break links within the identity graph if more than one identity from a given namespace is present in that graph.

Let me explain with a simple scenario, where Alice and Bob share the same device. I will use the email address as an identity for illustration purposes; in general, it is not recommended to use it in real scenarios.

1. Alice uses the shared device and logs in to your website. An ECID is generated on the landing page and, after logging in, AEP links Alice and the ECID.
   

2. Now Bob wants to access the same website using the shared device. After he logs in, AEP links Bob to the same ECID from the previous step, resulting in a profile collapse — there is now a single graph containing both Alice and Bob.
   

3. With identity graph linking rules enabled and configured, the oldest email address is removed from the graph, as it violates the rule of having only one email address per graph.
   

The end result is that we now have two identity graphs:

• Alice has only her email address.
• Bob has his email address and the ECID.

The ECID Trade-Off

You may have noticed there is a catch with the ECID. Since the ECID is now always linked to only one profile, all anonymous events are tied to that profile. In the previous example, anything Alice did before logging in will be attributed to Bob.

Some may argue this is an issue, but I would counter that there is no guarantee that anonymous events belong to the next person who logs in. While it could be an educated guess, it could just as well be the case that Bob used the shared device anonymously, and then Alice logged in afterward. There is no reliable way to determine who was behind the device before a login.

One way to address this issue is to create a merge policy that does not stitch identities (ID stitching set to “None”) and use it as the Active-On-Edge Merge Policy. With this configuration, anonymous events will not be combined with events after login. As always, do not immediately apply such configuration changes without fully understanding their implications and testing them in a development environment.

Beyond The Basics

I strongly recommend spending time reviewing the full documentation on Identity Graph Linking Rules, including the accompanying videos. I have explained only the simplest case, with two identity namespaces. If you have more than two, and a collapse could occur in different parts of the hierarchy, you must clearly understand what happens in each scenario. The possibilities grow exponentially with each namespace and each potential identity combination, making it impossible to document every case here.

To help visualize the behavior of this functionality, Adobe provides a Graph Simulation tool. I find this tool incredibly useful — you can load different scenarios and see exactly how the graphs will behave. Use it extensively in a development sandbox, testing all options and configurations until you find the optimal setup. Only then you should replicate it in your production environment. Client feedback on this tool has been very positive.

A customer recently asked if there was a rollback mechanism to restore the state from before enabling linking rules. The short answer is no. This is another reason why the simulation tool is so important.

Exceptions

While this solution works very well for many of Adobe’s clients, it is not the solution for all cases. I have worked with customers who are hesitant to enable Identity Graph Linking Rules because of the consequences for their identity strategies. As mentioned above, my recommendation is to use the simulation tool to analyze your specific use cases before making a decision. If it creates more problems than it solves, do not use it.

I want to thank Shota Ido, the Adobe product manager responsible of leading the efforts in making this solution a reality.

Photo by Rizky Sabriansyah

Definitions

Most people are familiar with the concept of a vicious circle. I picture this as a downward spiral, with each iteration making the situation worse than before.

The opposite of a vicious circle is a virtuous circle, where the spiral moves upwards and, with every iteration, results improve.

Campaigns are Linear

Traditionally, marketing campaigns are linear. Regardless of whether it involves an email, website personalization, display advertising, or social advertising, the approach usually follows a sequence from start to finish.

It typically begins with a brief: an outline describing what the campaign should achieve. In technical terms, this is often called the requirements document.

From the brief, the creative team begins working on the campaign’s components:

• Images must be created.
• Text must be written.
• Occasionally, a video will be included.
• A call to action is defined.
• The landing page URL is determined.

Once the creative process is complete, the marketing operations team prepares the campaign:

• Images need to be stored in a digital asset management tool.
• The HTML for the email must be created.
• Segments are created in RTCDP.
• Activities and experiences are configured in Adobe Target.
• Campaigns are set up in the relevant tools provided by social network platforms.
• Landing pages are published.

When you finally have everything ready, you publish the campaign, hold your breath and cross your fingers. Some adjustments may have to be made if issues show up.

And, last but not least, reports are generated to assess the success (or otherwise) of the campaign.

Of course, this is a simplified process. If you are part of any of the teams mentioned above, you know the work involved is much greater than what is described here. My intention was to provide an overview.

For reference, most of the above can be managed through Adobe Workfront. This is a tool I have not yet written about, but I am seeing increasing potential for it.

Closing the Loop

Although the above steps have made sense for many years, something crucial is missing: a feedback loop.

With a linear approach, once a campaign concludes, it is typically shelved. This practice leaves behind a wealth of valuable information—insights about what worked well, what did not, and what could have been done differently.

The idea behind the virtuous circle applied to digital marketing is to capture all learnings from previous campaigns and apply them to future ones. The main objective is to avoid repeating past mistakes and to continually enhance marketing results.

A word of caution: avoid the trap of repeating the same campaign with only minor changes. Instead, identify and replicate the key elements that made previous campaigns successful.