A Comprehensive Migration Guide – Adobe Audience Manager to Adobe Real-Time CDP
Introduction
Adobe Audience Manager (AAM) is an industry-leading Data Management Platform (DMP) from Adobe that is slowly taking a back seat to Adobe Real-Time CDP. Why? Adobe RT-CDP is a more robust, first-party DMP solution that is future-proofed for the initiatives around 3rd party cookie blocking and restrictions.
You can continue using AAM, or another DMP, if you focus on limited data sources like Adobe Analytics and some people-based social destinations like Facebook. But migrating to RT-CDP takes your customer experience management to a whole new level. We cover the top reasons to migrate from AAM to Adobe CDP here.
This is an in-depth guide to migrating from AAM to RT-CDP, with multiple migration paths and pointers for each.
Migration Considerations
Typically, an AAM implementation involves various stakeholders and teams, from analytics teams to agencies. For organizations deeply invested in AAM, the migration process can be pretty complex. Nevertheless, we reckon many will take this migration path sooner or later to keep up with data privacy progress. View this migration as a marketing activities reset, especially for those powered by 3rd party cookies/IDs.
As with any organizational change, this migration needs to be done with careful planning, transitions, and any necessary training.
Top 10 Considerations when Planning a Migration:
| Consideration | Comments |
| Marketing use cases | Not all use cases will be migrated to RT-CDP. Due to industry dynamics, some use cases are more affected or unhelpful to continue. Examples of these are detailed in the sections below. |
| Destinations | Third-party cookie sharing (“demdex” cookie or UUID) is the basis of many AAM destinations. These need to be migrated to people-based or 1st- and 2nd-party cookie data sharing during migration. |
| Visitor Volumes for prospecting | Suppose you are using display advertising for prospecting and top-of-the-funnel marketing. In that case, your visitor volumes will take a hit posting when moving to the 1st party-only strategy (or RT-CDP). Advanced planning is suggested. |
| Mobile Analytics & Destinations | Your ID syncs in mobile have synced with a global data source for GAID or IDFA, but this will not be available in RT-CDP. You can still leverage these IDs with appropriate consent to track users across the apps and marketing destinations. |
| Audience Labs and Look-a-like modeling | These two features are not yet in the RT-CDP roadmap, and related use cases are impacted in the short term. |
| Data Sources | Even though the AAM Connector brings all the data into RT-CDP, you need to re-wire them to exploit new data connectors and streaming ingestion. This sometimes warrants a time-consuming migration process. |
| Privacy Labelling | It is worth double-checking any specific data labels and privacy settings applied to sources and destinations after migration. |
| Segmentation Taxonomy | RT-CDP does not have a folder structure to manage large volumes of segments. So, you need to follow a naming convention to name and group the segments. It is recommended to group segments by use cases and teams. |
| Role-based access controls | If you have a large, diversified team with defined role-based access controls for AAM, migrating to RT-CDP might take more time to do bulk updates or API-based updates. In this case, account for more time. |
Migration Options
Here we have outlined a modular approach to RT-CDP migration. You can treat each option as an individual item with almost no interdependencies. These options can also be accomplished together or parallelly.
Option 1: Lift-and-Shift with AAM Source Connector
A good starting point for the migration would be to explore the out-of-the-box AAM source connector. The data from AAM goes into the Adobe Experience Platform (AEP) and is then consumed by RT-CDP (an application sitting on top of AEP). So, in RT-CDP, you are using the data ingestion features of AEP, which is common to other solutions like analytics, campaigns, etc.
How Do You Do It?
- Find the connector in the “Sources” tab under “Adobe Applications.”
- This is a three-step wizard for selecting the segments and mostly does not have any other dependencies.
What is Accomplished?
- All real-time data, like Adobe Analytics SSF, Pixel calls, and email calls, are sent to AEP.
- All integrated profile data from onboarded sources and authenticated profiles are sent to AEP.
- About 8 data sets are created automatically to hold the data in DXM format (can be easily used across other solutions and marketing destinations).
- Segments (and Traits) migrate to AEP.
- Segment size and qualification data migrate as well.
What is Not?
- Destinations are not set up using this connector. (Talk to Adobe Client Care or Consulting to access the list of S2S (server-to-server) destinations and set them up in RT-CDP. Some destinations require ID syncs).
- 3rd-party and 2nd-party data feed and marketplace traits do not migrate.
- Role-based access controls do not migrate. Manually create this.
- Audience Labs and Look-a-like models are not a part of this.
- Destination Data Export Labels do not migrate using this connector.
- Tableau reports like Audience Optimization Reports and Data Explorer are not yet there as a feature in RT-CDP. So, these are not available.
What’s the Catch?
- Even though this is a decent lift-shift migration, this does not allow you to exploit the new futuristic features of AEP.
- Reporting is a serious limitation in RT-CDP, and you might need additional licenses for Query Services and Customer Journey Analytics (CJA) for detailed reports.
- Match rate computations are no longer valid as RT-CDP operates on a 1st party basis.
- Latency of <35 mins for real-time data and <2 days for onboarded (profile data).
After this Migration:
- Marketing teams and agencies stop using AAM UI and switch to RT-CDP UI.
- Campaigns and personalization initiatives continue to run just like pre-AEP days.
Option 2a: Re-Wire Source Connections
This option involves re-wiring or re-implementing the source data collection through AEP’s robust connectors. This is done after option 1 is completed or at the same time. AAM typically has 3-4 sources of data, as is pictured below:
We can look at the migration strategies for the key sources below:
- Adobe Analytics: Undoubtedly, one of the most significant data sources for AAM is behavioral data from Adobe Analytics. To re-wire this efficiently into AEP, you can either use Adobe Analytics source data connector or re-implement the tags to use AEP Web SDK (alloy.js) to send data directly to AEP.
- CRM: The second most popular most extensive data set would be CRM. AEP has out-of-the-box connectors to popular CRMs like Microsoft Dynamics and Salesforce. You can also use cloud stores and databases to send data into AEP. This should replace the slow and inefficient key-value pair-based files used in AAM.
- Ad Pixels and Email pixels: There are two ways to ingest this data. If you have a source connector, you can set up the connector and configure a data flow. If it is not there, then AEP has streaming endpoints to ingest real-time data, as long as it is in XDM format for AEP. Currently, this can be accomplished only using a custom solution that takes the pixel hits (coming in as Query Strings), transforms them to XDM format, and streams them back to AEP. The true user identity needs to be passed when sending in the hits.
- 3rd party data: RT-CDP does not support a 3rd party marketplace. 2nd party data should be brought in from file storage or cloud storage.
How Do You Do It?
- All the connectors can be found in the “Sources” tab.
- Setting up source connectors is typically a two-step process:
- The first step involves setting up a connection (supplying credentials or account details for the source).
- In the second step, a data flow is configured. You typically need a schema and a data set at this step to ingest the data. It is not recommended to use the data set created in option 1. So, you need to create new schemas and data sets. In AEP, the concept of IDs works differently than AAM. AEP can accept any ID as a primary ID, but the data set can also have a secondary ID. If the data set is enabled for profile, then the look–ups and integration are based on any of these IDs. These IDs contribute and make a “private graph.”
What Is Accomplished?
- A complete re-wiring of the source data to exploit new features of AEP is completed, giving you more flexibility and scalability.
- The foundation for future use cases, AI/ML-based use cases, and journey analytics is laid.
- Data labels need to be migrated from AAM when setting up the schemas and data sets (manually).
What Is Not?
- Only inbound sources are handled. All other things need to be migrated (discussed in the upcoming options).
- Role-based access controls do not migrate. This needs to be manually set up.
- Audience Labs, Look-a-like models, are not a part of this migration.
- Tableau reports like Audience Optimization Reports and Data Explorer are not yet there as a feature in RT-CDP. So, these would not be available.
What’s the Catch?
- Since profiles are based on the same primary identifier (ECID or CRM ID), 1st party profiles and counts would not take a hit.
- But fluctuations in the audience size are expected as AAM numbers are based on UUID (demdex 3rd party cookie), which is not there in RT-CDP.
- You would be required to create new schemas and data set to bring in the data, which would warrant a change in the segment definitions (If you have an option 1 lift & shift migration done).
After This Migration:
- Almost a reset in terms of data ingestion and segment definitions. Capability to ingest more data set into the profiles.
- Marketing teams and agencies can still not use the data (as segments and destinations are not yet set up).
- If you have already accomplished option 1, then marketing initiatives continue to run as BAU.
Option 2b: Re-Wire Destinations and Segments
This phase typically follows option 2, but if you are only re-wiring your destinations, you can do this independently as well. Destinations are a vital component of RT-CDP, and unlike AAM, you can set up the S2S destinations all by yourself. You also get deeper insights on data push and meta-data for troubleshooting the destinations.
During migration from AAM, you need to evaluate each destination to find the relevance to RT-CDP. The latter only supports destinations with durable identifiers. Ex: Google Ad words would require a new setup called “Google Customer Match.” If any destination is not available out-of-the-box, you could share the data using flat files or create a new one using APIs or develop a destination with Adobe Partners using Destinations SDK (new feature). Experts in NextRow can precisely help you here!
How Do You Do It?
- This is done using the “Destinations” section in AEP UI.
- The “Catalog” tab displays a list of all destinations available in AEP, where segments are activated.
- Activating a destination is a two-step process- The first step is to create a destination connection (where you will name the connection and supply credentials for that destination).
- Second, you need to activate the segments (like the segment mapping step in AAM).
- Activation (Shared) data from RT-CDP can be of two types (a) Segments (b) Profiles which depend on the type of the destination.
What Is Accomplished?
- Re-vamped destinations powered by durable identifiers (this step is critical if you are looking to mitigate the effect of 3rd party cookie sunset).
- If you have implemented option 2, then you need to update the segment conditions with new fields.
- Activation data flows to the destinations are set up. You should monitor the data flows either in the “Destinations” section or “Monitoring” section.
What Is Not?
- Only destinations (and segments) migrate. All other things need to be migrated.
- Role-based access controls do not migrate. This needs to be manually set up.
- Audience Labs, Look-a-like models, are not a part of this migration.
- Tableau reports like Audience Optimization Reports and Data Explorer are not yet there as a feature in RT-CDP. So, these would not be available.
- Privacy labels at the data source levels need to be validated manually.
What’s the Catch?
- URL destinations are available as HTTP connection, but it is in the “Alpha” release.
- Some 3rd party data-powered destinations might not be available in RT-CDP.
- 3rd party cookies and ID sync is possible in AEP and is optional. So this could be used till Google sunsets 3rd party cookies (early 2023).
- Metrics like “Overall Match Rate” and “Segment Match Rate” are not available in RT-CDP (instead, it provides some proxy, 1st party metrics like “Activation Rate”).
- Custom destination setup will take time to implement and test. So, it needs to be factored into the migration plan.
- You cannot take transactional data out of RT-CDP for destination or segment performance reporting. You would require licenses for Query Service or Customer Journey Analytics for this.
After This Migration:
Almost a reset in terms of destinations.
- More power is given to marketing and analytics teams to set up destinations and control the type of data shared for activation.
- Some transformations on PII are available out-of-the-box to cover destinations like email providers.
Option 3: Use-Cases Based Migration
You could start the migration process by prioritizing the use cases and accomplishing the new use cases powered by 1st party data with RT-CDP. Then migrate the other use cases to RT-CDP either using an AAM connector or re-wiring the sources and destinations.
A Guide on the Impact of the Significant Use Cases
| Use Case | Visitor Type | Impact on the use cases | Why is there an impact? |
| Personalization | Authenticated & known customers | Low | Easy to integrate and stitch data. Segment activation through People-based and 1st party ID-based destinations. |
| Unauthenticated (Next Page) | Low | This is based on 1st party cookies and will continue as-is. | |
| Unauthenticated (First Page) | High | This is powered by 3rd party marketplace in AAM and would no longer be available in RT-CDP. | |
| Prospecting | Publisher Direct | Low | Easy to accomplish using RT-CDP’s profile sharing. |
| Cohort Targeting | Low | Reaching groups of audiences in a network to continue as-is. | |
| Authenticated & known customers | Low | Easy to integrate and stitch data. Segment activation through People-based and 1st party ID-based destinations. | |
| Targeting Unknown/unauthenticated audiences | High | This depends on 3rd party cookies for targeting and attribution, which would go away with the 3rd party cookie sunset. |
How Do You Do It?
Identify and prioritize use cases based on durable (1st party) identifiers
- Check the sources of the identifiers.
- Implement sources and destination connectors for the use cases.
- Create segments (using the new data sets) and map them to the destinations (If you have many segments, then use the Segmentation APIs).
Identify and prioritize or de-prioritize use cases based on 3rd party data/identifiers
- There are three main uses for 3rd party cookies, which would not be possible once the industry moves to sunset the 3rd party cookies: (1) Cross-property/app tracking, (2) Programmatic Advertising (prospecting) & (3) Measurement and attribution.
- If an alternate 1st party-based solution is available (Ex: Google Customer Match), plan and implement the sources and destinations set up for that.
- Create the segments in RT-CDP based on new data sources.
If use cases can only be accomplished using 3rd party data/identities, start planning to capture and harvest the IDs and establish a 2nd party relationship with the data provider.
What Is Accomplished?
- A use case-based validation and a slow migration process.
- Futuristic use cases are prioritized, and a specific team is assigned to run the campaigns and segment sharing.
What Is Not?
- Role-based access controls need to be manually replicated across RT-CDP.
- Audience Labs, Look-a-like models, would not be possible to migrate.
- Tableau reports like Audience Optimization Reports and Data Explorer are not yet there as a feature in RT-CDP. So, these would not be available.
- Privacy labels at the data source levels need to be validated manually.
What’s the Catch?
- If any customizations are done for data sources or destinations, the time taken for implementation would be high depending on the complexity.
- Any custom destination setup will take time to implement and test. So, additional time for review needs to be factored into the migration plan.
After This Migration:
- There are two separate teams for AAM and RT-CDP. One team executing 3rd party-based campaigns and other 1st party-based ones.
- A hub and spoke model can be established as a part of this to keep both teams in sync.
Closing Thoughts
As you can see, migrating from AAM to RT-CDP requires careful planning, technical execution, follow-through, and time for review. Given the long-term benefits and competitive edge that RT-CDP brings, every CMO organization should prioritize this.
If you have any questions about the migration options discussed above or need further assistance, we are here to help. Working with some of the world’s leading organizations in the field of RT-CDP has given NextRow Digital the experience needed to execute successful migrations.
About NextRow
NextRow Digital is an Adobe Silver Partner with more than a decade of experience supporting clients across industries. We have the right skillsets and proven processes to support your complex needs, from IT to marketing. Grow your business with the help of RT-CDP experts at NextRow!
To learn more about our CDP offerings, visit our RTCDP page.
To learn more about our Adobe Experience Platform offerings, click here.
To learn how NextRow can help with Adobe Analytics assessments, planning, and integrations, contact us at +1-847-592-2920.
