RTCDP vs AAM
I think that I have said a few times that, when I got trained in Adobe Audience Manager (AAM) in September 2014, I only understood about 50% of it and it took me another year to become an expert. With the advent of the Adobe Experience Platform (AEP) and its Real-Time Customer Data Profile (RTCDP) application, I did not need that much time to feel comfortable with it. One could say that RTCDP is the successor of AAM, which makes the transition easier. However, the two have very different backgrounds. So, what are the commonalities and differences between the two?
The following is a list that I have compiled from my experience and what has called my attention. Please, let me know in the comments if you would like me to add some other features or capabilities.
Although the two tools look very different, some features are very similar.
Data in, data out
A few years ago I wrote a blog post entitled DMPs: data in, data out. I will not repeat what I said there, but the summary is that tools like AAM and RTCDP are engines that take data in, process it and send it somewhere else. The input data refers contains profile attributes and the output data are audiences.
At the end of the day, the main goal of both RTCDP and AAM and all the complexities of their implementation are just to create segments. We can argue that the UI and segmentation capabilities are different but, conceptually, the capability is the same. Let’s not forget that both are marketing tools.
Real-time & batch
Another major similarity is the frequency at which the input data is processed, the segments are evaluated and audiences are shared with destinations. In both tools, you have batch and real-time capabilities.
I have referred a few times to the Anatomy of an AEP project, with what I have coined as the “U-Turn”. This approach should be applied to both AEP and AAM projects. In both cases, you should:
- Start from the end, from the audiences you are trying to address; or in other words, the why you are doing this project
- Do all the business analysis and definitions while you make your way to the data sources
- Find the data that you need to bring into RTCDP/AAM
- Bring the data to the tool
- Configure the tool and create the segments
- Activate the segments in your destinations
I was expecting more commonalities when I started to write this blog, but I have realized that there are many more differences.
This is very obvious. AAM, like most DMPs, has a very flat data model. AAM has the concept of traits, which are the building blocks of the segments. I believe that other DMPs jump directly into the segmentation capability, using key-value pairs. On the other hand, RTCPD, as part of AEP, uses XDM, which is much richer. While you could flatten it, you have the option of adding custom classes, arrays and nested objects, defining data types, using various identities…
Another key difference is that in RTCDP you can separate the concept of profile attributes from profile events. AAM does not have this feature and all traits are created equal.
A few paragraphs above I explained that the segmentation capability was a commonality. However, this is where all similarities end. The segmentation engine in AAM only supports combinations of ANDs and ORs of traits, with the option to nest them and add recency and frequency.
AEP’s segmentation capability goes far beyond that of AAM. For starters, you can combine profile attributes, event attributes and other segments in a segment. AEP’s segmentation can also look into arrays and custom classes. Finally, you can sequence events in AEP, something impossible in AAM.
This is a very simple difference: AAM should not store any PII data, while AEP was explicitly designed to hold lots of PII data. One could argue that RTCDP does not need PII data, although this is only partially true. You are not likely to create a segment of all customers whose first name is “Pedro”, as it makes very little sense. However, you could send this PII data to your RTCDP destinations, which can then use to personalize the message.
1st vs 3rd party data and cookies
The world of display advertising relies completely on 3rd party cookies. When DMPs, DSPs, ad servers and other ad technologies were developed, it was standard practice to use these cookies. AAM’s cornerstone is the demdex cookie. And, when you did not have enough data, you could easily buy 3rd party data based on 3rd party cookies from multiple data providers.
AEP’s development took a radically different approach, knowing that 3rd party cookies will, sooner or later, disappear. Therefore, AEP relies mainly on 1st party data and 1st party cookies. In general, AEP ignores 3rd party cookies and does not have any ID sync capabilities.
When I was preparing for this post, I started by listing similarities and differences, so I could expand them later. In the case of destinations, I did not know where to put them. On the one hand, both tools have a destination capability, but this is like saying almost nothing. On the other hand, these destinations could not be more different. So, in the end, I decided to keep it as a difference.
AAM has 3 types of destination: cookies, URLs (pixels) and server-to-server. This last type is used to share audiences to advertising platforms and it only shares the identity, usually a 3rd party cookie.
RTCDP only supports the last type, but it has taken it to the next level. As I said above, RTCDP does not support 3rd party cookies, but it is heavily based on PII data. Therefore, the destinations RTCDP supports work based on PII data too. You can also create file-based destinations, connect to middleware technology and build your own destination with the destination SDK. Also, as stated before, you are not restricted to sharing the identity, but other PII data.
Similar to destinations, data sources may conceptually be similar but are very different.
Let’s start with the data model. AAM only supports a very simple, flat data model for data ingestion, based on identities and key/value pairs. AEP/RTCDP can ingest data in CSV, JSON and XDM formats and can query databases or other tools.
AAM only offers an edge network for real-time data and an S3 bucket for batch data. Except for the DIL code and 3rd party data providers, all source integrations are manual and require ETLs. RTCDP surpasses AAM, supporting out of the box multiple data sources, from generic streaming connectors to commercial products to cloud storage, with no need to code anything. The list of supported data sources keeps on growing over time. If your data source is not listed, you can always fall back to using an ETL.
Both AAM and RTCDP have configuration options to combine profile fragents into a full customer profile. However, the two tools could not be more different. Even the name of the functionality is different. In summary, these are the two approaches taken by each tool:
- In AAM you can combine anonymous with authenticated behavioral data and the rules revolve around the user being logged in or not.
- RTCDP supports any number of dataset and the rules are either a dataset priority list or the last fragment from any dataset.
People vs devices
Another clear difference between AAM and RTCDP is that AAM is device-based, with the demdex cookie at its heart, and RTCDP is people based. Even if AAM supports profile merge rules, like above, where we can combine data from devices and people, the device part is still the base. On the other hand, AEP in general is always about people. Yes, you can still use the ECID as an identity, but clickstream is just considered one of many event data sources.
Photo by Karolina Grabowska