ID sync

09 Apr 2017 » AAM

When I was following the Adobe Audience Manager training, I remember that one of the topics I found most difficult to understand was ID syncing. The enablers spent a lot of time using these words and I could see that it was a key part of any Data Management Platform (DMP). Once I finally understood what it meant, I felt relieved. Today I will explain this concept, in case you are also stuck.

What is an ID sync for?

I will start by explaining why we need this ID sync. DMPs Demand Side Platforms (DSP) alike generate a unique random number to identify each browser, stored as a 3rd party cookie. This is fine, as long as you are in the realms of the DMP or the DSP: they will receive their expected cookie. However, one of the main features of a DMP is to connect with DSPs and send audiences to them. An audience is, no more, no less than a list of unique identifiers. Now, as I have been explaining in a previous post, cookies are stored under a domain and browsers are very good at guaranteeing this expected behaviour. This means that the DMP, in principle, could only send its own unique identifiers to the DSP. However, as you will already realise, the DSP will not know what to do with these identifiers, as it has no access to them in the browser.

There needs to be a solution to this problem. DMPs and DSPs need to find a way of exchanging their IDs for a particular browser. With this exchange, either of them can create a translation table, something like:

DMP ID DSP1 ID DSP2 ID DSP3 ID
12345 a1b2c3 abcde 98765
54321 z1x2c3 zyxwv 56789
13542 d4e5f6 hijklm 57986

With this information, when the DMP sends an audience to a DSP, it can send the DSP IDs. In fact, it can be used not only with DSPs but with any data source or destination. As long as the DMP has an ID sync with any other party, it can expand the previous table with more columns. In the case of data sources, this is important as when a DMP receives a data file keyed off of the data source’s IDs, it can then map the data source’s data to the DMP IDs.

Manual ID syncs

This is the most straightforward approach. Just create a URL with the parameters the DMP/DSP requires. Since the call will include or generate a cookie, you get in one go both the data source ID, as a query string parameter, and the DMP/DSP ID, in the form of a cookie. With these two pieces of information, the DSP or DMP can create a mapping between the two IDs.

In the particular case of AAM’s ID sync, this URL has the following format (click here for the details):

http://dpm.demdex.net/ibs:dpid=[data source ID]&dpuuid=[data source unique ID]&redir=[redirect URL]

When the browser sends this request, it will include:

  • All cookies under the domain demdex.net, which includes the demdex cookie, where AAM stores its unique ID (UUID). If this cookie does not exist, a new one will be generated and stored in the browser.
  • The unique ID for the data source in the query string parameter dpuuid.

The limitation of this manual ID sync is that there are very few use cases when you can use it: only when you are in control of the unique ID of the dpid.

Automated ID syncs

This is the most common use case. When a user lands on a website, where the DMP code is present, it can trigger a negotiation with various servers. This negotiation relies on HTTP messages and the HTTP 302 status code, to issue redirects. It also requires that the DMP and DSPs have already agreed on how to perform this negotiation.

I believe that the best way of showing it is with an example using AAM and MediaMath (click for a larger image):

ID sync

Let me describe the previous process:

  1. Browser loads AAM code.
  2. The AAM code issues an HTTP request to the MediaMath server (sync.mathtag.com). This request includes the MediaMath cookie.
  3. MediaMath server reads the cookie, creates a redirect URL to AAM server and sends back to the browser a 302 redirect. When creating the redirect URL, it includes the value of the cookie in the right query string parameter. As you can see, the URL has exactly the format shown in the previous section, where dpuuid contains the MediaMath cookie value.
  4. The browser receives the 302 redirect with the new URL and issues a new HTTP request, this time to AAM servers. This request includes MediaMath’s unique ID in the URL and the AAM cookie.
  5. AAM server receives the request and adds the information to its internal table. It then sends a 200 status back to the browser.

So, after this process, AAM has been able to synchronise AAM’s unique ID and MediaMath’s unique ID.

This process is repeated with each data source or destination and, with all the information received, the DMP can build an ID sync table.

[UPDATE 23/07/2022] I have updated this post, as I have been showing it to clients lately and I realized it needed to be polished

 

Photo by cottonbro

Related Posts