AEP Identity Strategy

21 Sep 2025 » Platform

It has been more than three years since I wrote my first post on AEP identities. I think it is time to revisit this topic. Not only have I learned a lot about AEP since then, but there were many questions in that post which clearly indicated that it is a complex topic not well understood.

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. AEP Namespaces
  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”. New AEP namespace

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.

XDM schema with identities

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

Related Posts