Data Sources in AAM

When you are new to AAM and you hear the words “data sources”, you immediately think you understand the concept. However, as you progress in your knowledge of the tool, you start to realise that you actually do not know what data sources are in AAM and need to rethink all you have learned. At least, this is what happened to me. Over time, I have finally understood this concept and today I wanted to share it with you in this post.

Onboarded traits

The actual etymological meaning still stands in one case: onboarded traits. AAM separates input files by data source. In other words, when you create an onboarded trait, you must select the correct data source from the drop-down:

onboarded trait data source

Choosing the wrong data source will mean that AAM will ignore your traits. This is the simplest case.

ID Storage

A less known functionality of the AAM data sources is to store IDs. Just by creating a new data source in AAM, you also get a new ID storage where you can send IDs, either by using a declared ID or an ID sync. The way I see it is like a table, where the rows are the devices and the columns the data sources. This table is stored at AAM level, which means that is shared across all AAM customers. As a consequence, it makes it conceptually huge: billions of rows and hundreds of thousands of columns. Obviously, AAM does not really use a SQL or Excel table, which would be really slow.

UUIDData Source 1Data Source 2Data Source 3

It is worth nothing a couple of things:

  • The primary key for AAM is the UUID (demdex cookie).
  • There will be gaps, many gaps. Usually, a UUID will only have an ID sync with a handful of data sources.

What is even more surprising is these IDs are used in destinations. I know, this sounds really confusing: data source IDs in destinations? However, if you think a bit more about it, it makes sense. Why create a new ID storage for destinations, when you already have one. As an AAM user, you should not care about this, but if you are implementing AAM and need to get a batch file from it, you will need to think about the data source ID you want the data to be keyed off. This is also used with DSPs.

Core Services

You will have noticed that, after using AAM for some time, you have multiple data sources, some of which you did not create. The Adobe provisioning team will create some of them, whereas others are created automatically. The reason is that AAM delivers some Core Services features and they require a data source. One example is the sharing of Analytics segments with the Experience Cloud.

In reality, the Core Service is using either the data onboarding feature or the ID storage, but hidden behind a different front-end.

Data classification

This is the main reason for writing this post. In a turn that looks even more difficult to follow, when you select a data source for a trait or segment, you are actually classifying it. This causes a lot of confusion in the following 2 cases, as people do not know what to choose in this mandatory field:

  • Rule-based traits. These are based on real-time calls to AAM edge servers. No matter which data source you choose, all rule-based traits are evaluated in every AAM call. We usually create a “Analytics” data source, but this is just for convenience; AAM will not restrict the traits in there to those coming from Server-Side Forwarding.
  • Segments. Creating a segment from traits from the same data source might not require to think too much, but what happens when you combine traits from multiple data sources? Which data source do you choose?

The truth is that it does not matter, from a processing perspective, what data source you choose in the previous 2 cases. AAM will still behave as you expect. You may wonder, then, “why do I need to choose a data source”? There are, at least, two reasons:

  • User permissions. As I will show in a later post, you can create user groups and restrict the access based on data source. This is particularly important when you have multiple tenants or multiple agencies working with your AAM instance.
  • Look-alike modelling. When creating a model, you must choose a list of data sources. Only the traits in the selected data sources will be included in the model.


I hope that, after reading this post, you understand a bit better AAM data sources.

6 thoughts on “Data Sources in AAM”

  1. Hi Pedro
    Undoubtedly, the DS concept is confusing. I read some where that DS act as containers of traits and segments. Can you throw some light on how are traits and segments stored within a DS? Thanks!

  2. Hi Pedro, if I create a rule-based trait with criteria “c_evar1” == “” (url) for a customer who has several report suites with completely different data models:
    – WEB RS – eVar1= {{url}}
    – APP RS – eVar1 = {{devicebrand}}
    – BLOG RS – eVar1 = {{language}}

    How can I control that rule-based trait with criteria “c_evar1” to only work for the WEB RS (and not for others RS).

    • By default, the report suite is not available in any variable in AAM. If you need it, you can always copy it into a variable. To avoid burning an eVar or prop, you can use context data variables. Alternatively, if you know the URL of the domains used per report suite, you can use the h_referer variable. It contains the URL of the browser, which you can check with something like: h_referer STARTSWITH ""; or with a regular expression.

      All together, it could look something like:
      c_evar1 == "" AND h_referer STARTSWITH ""


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.