The demdex cookie
05 Sep 2021 » AAM
This post may be a bit late, as 3rd party cookies have their days numbered. However, with Google’s decision to delay the end of these types of cookies, we will still have them for a bit longer. So, in case you wanted to know more about the demdex cookie, here you have all its uses.
UUID
The original reason for this cookie is to store the unique identifier of the browser in Adobe Audience Manager (AAM). Feel free to check the value of the cookie. You will notice that all values you see are always different.
Think of it as the primary key of a huge table, where the columns are all your organization’s traits and the rows are the browsers that have interacted with your website. The cells are just bits: 1 if the browser qualifies for the trait, 0 otherwise. For each server call to AAM, it will use this UUID to find the row with the browser’s traits and evaluate which segments it qualifies for. Such a table does not exist, AAM works differently, but it is a good way of understanding this ID.
| UUID | Trait1 | Trait2 | Trait3 |
|---|---|---|---|
| 12345 | 1 | 0 | 1 |
| 54321 | 0 | 0 | 1 |
| 13542 | 1 | 1 | 1 |
A few final clarifications:
- UUIDs are completely random; there is nothing in them linked to the visitor.
- Since Javascript’s random number generator is not very good, UUID’s are generated server-side.
- To prevent the number of UUIDs from growing indefinitely, AAM deletes UUIDs and their associated trait qualifications after a period of inactivity.
ID Syncs
I have a post devoted to ID Syncs with a full explanation of this capability. Here, I will just summarise it.
The main functionality of a DMP is to create audiences, which are then sent to different destinations, usually DSPs. The problem is that each provider uses its own ID. So, DMPs and DSPs need a mechanism to exchange IDs, which is what we call ID syncing. In this process, using HTTP 302 redirects, the 2 services exchange their IDs, so each side can build a table like the following:
| UUID | DSP1 ID | DSP2 ID | DSP3 ID |
|---|---|---|---|
| 12345 | a1b2c3 | abcde | 98765 |
| 54321 | z1x2c3 | zyxwv | 56789 |
| 13542 | d4e5f6 | hijklm | 57986 |
With this table, if browser 12345 qualifies for a segment that needs to be sent to DSP3, AAM will send the ID 98765 instead.
ECID Service
In case you did not know it, the Experience Cloud ID (ECID) service is provided by AAM and the ECID is generated from the UUID. While the UUID is unique per browser, the ECID is unique per browser and organization ID. There is a mathematical operation that links these 3 IDs (ORG ID, UUID and ECID), such that if you know 2 of them, you can get the 3rd. Think of it as an XOR operation.
In other words, the UUID is the same across all AAM clients, whereas the ECID is unique per client.
You will have noticed that the ECID service calls dpm.demdex.net. If there is already a demdex cookie, it will use it to generate the ECID.
This is why you always get the same ECID across your different domains, as long as the demdex cookie is present. This feature is key in setups with a global report suite in Adobe Analytics, where you send the data from multiple domains. Keeping a visitor’s ECID across domains prevents visitor overcounting and allows you to create cross-domain reports.
2nd party data
Another feature that AAM offers is to share audiences between AAM clients through the Adobe Marketplace. Examples I have seen are credit card companies and airlines, and mobile phone manufacturers and mobile carriers.
The process is very simple. A segment is created by one party and shared with the other party, which shows up as a trait. How can AAM do that? Well, very simple: the UUID is the same for all clients.
3rd party cookie
As I explained at the beginning, the demdex cookie is a 3rd party cookie. I hope that, by now, you understand why it has to be like that. But if you need a more detailed explanation, here it goes.
There are 3 main requisites regarding the UUID that force this decision:
- Must be unique per browser
- Must be stored in the browser
- Must be accessible under any domain (not directly, though)
The only solution to achieve these requirements is to use a 3rd party cookie. If the browser blocks 3rd party cookies, the UUID is still generated and stored in the AAM database. If the request comes from the ECID service (as shown above), AAM can still operate normally, since AAM can calculate the UUID from the ECID and the ORG ID. However, during ID syncs, the generated UUIDs are lost forever.
Regeneration of UUIDs
There is one final case I wanted to mention, which took me a while to understand. Consider a scenario where you have an ECID and no cookies. You can store this ECID in the AMCV cookie and the ECID service will gladly use it. However, it will refuse to regenerate the corresponding demdex cookie. Remember that AAM can calculate the UUID associated with the ECID and, in theory, could also set the demdex cookie accordingly.
The reason is that the browser may already have other ECIDs from other Adobe clients. There is no way to know that, as you cannot access cookies from other domains. If AAM regenerated the demdex cookie with the UUID associated to your ECID, this UUID would be unrelated to any other ECID present in the browser. When the user visited these other websites, the ECID and the UUID in the demdex cookie would be in conflict and unexpected results will happen.
Photo by Richy Great on Unsplash