DMPs: data in, data out

09 Feb 2020 » AAM

I still remember vividly how, after coming back from my summer holidays in 2014, my manager told me to book a flight to NYC to get trained on Adobe Audience Manager (AAM). The training was a hit and miss type: I understood some concepts, while others were totally alien to me. It did not help the fact that, after this training, I spent 6 months without working on AAM projects.

However, the 2 other EMEA consultants left and I became, for a while, the only AAM consultant for the whole region. That helped me learn a lot very fast and I started to understand in depth what a DMP was. I wrote an initial introduction to AAM long time ago and today I want to update how I understand it.

Double funnel

At the core of any DMP, there is a very simple functionality. It very much looks like an ETL: you feed it with raw data (signals), it processes this data and it spits segments out. This is the simplest explanation and the beauty of it. In fact, it does nothing else and, as you can see, on its own, it is pretty useless.

With this explanation, you may be wondering, why does it even make sense to have a DMP like AAM? Could an ETL do the same? The answer is speed: you need to create audiences in real time. Think about it: AAM is capable of evaluating 100,000 traits and 20,000 segments in less than a second, for every server call. Could your ETL do that?

Data in

AAM ingests data as key/value pairs associated with a visitor or user. Each key/value pair is called a signal. You can send signals to AAM in two different ways:

  • Real-time. These are the HTTP calls made directly to the Data Collection Servers (DCS) using the DCS API. There are in various data centres around the world, to make the round-trip time as low as possible. You usually see this case in:
    • Adobe Analytics Server-Side Forwarding, which is the most common way of sending your website data to AAM.
    • Tracking pixels, either in banners or 3rd party websites.
  • Batch. You can also send files to AAM, which are processed in batch. Typical use cases for this format:
    • 1st data coming from your own systems, typically from your CRM.
    • 2nd party data shared from another AAM customer.
    • 3rd party data from the Adobe Marketplace.

I already explained the UI and configuration in the post on data sources.

One word of caution, do not confuse the DCS API with the REST APIs. The former is used to send data to AAM, while the latter allows the configuration of AAM, instead of using the UI.

Processing

AAM gets the signals and applies the rules you have configured in the UI:

  • Traits. It would be impossible to process all signals, as there could be millions of them. Instead, you select those that you are interested in. These are your traits.
  • Segments. With the traits you have selected and using boolean logic, you define segments.

Although this may seem very simple, remember what I said earlier. For the real-time signals, AAM must be able to do all this processing in less than a second. I know I have simplified this part and left out some functionality, but AAMs core is made of traits and segments.

Data out

The only type of data AAM produces are audiences, which are the visitors or uses who qualify for each segment. However, as I have mentioned, AAM cannot do anything with the audiences internally. It is up to other systems to use these audiences. There are 3 types of destinations:

  • Server to server (S2S). These are the integrations with DSPs and similar tools. As with the data in, there are two types:
    • Real-time. These are HTTP calls from AAM servers to the DSP server, in (near) real-time, with an ID and the segments it qualifies for. In case it is not clear, AAM makes one of these calls for each visitor, as a consequence of a real-time call to the DCS.
    • Batch. Every predefined time, AAM calculates all audiences and sends them via files to the DSPs.
  • URL-based destination. Create a pixel on the HTML page the visitor is browsing if he/she qualifies for a segment.
  • Cookie-based destination. Create a cookie in the browser of the visitor with the segments he/she qualifies for.

There is one special case: Adobe Target. It has a special connection with AAM, which happens behind the scenes and Adobe takes care of it. The only configuration parameter, which you need to communicate to your Adobe CSM or Client Care, is whether you want this connection to be done on every page view or once per session.

Integrations

These are the connections to the left of the left funnel and to the right of the right funnel.

If you re-read the previous sections, you will notice that AAM has no activation features. Your display or Adwords campaigns, your personalisation activities, your creatives, your messages… must be managed in a separate tool. In other words, in order to make any useful use of the tool, AAM must be connected to other systems; on its own, it is meaningless. Since this is a fundamental requirement, AAM must very easily integrate with other tools. Its connections with Analytics and Target are not only out of the box, but seamless. Adding DSPs takes a bit of time, but it is only the initial configuration; AAM already has platform-wide connections with dozens of DSPs.

I remember speaking with a colleague a few years ago. He was surprised to see that AAM was the easiest tool to integrate with. But then he immediately realised that this was so because AAM was designed and built to be easily integrated with other platforms.

 

Image by rawpixel.com

Related Posts