Data Governance in Adobe Experience Platform (AEP): A Guide

Adobe Experience Platform (AEP) promises one profile per customer, built from the data in all your systems and ready to activate in any channel. That promise depends on what goes in. When data governance fails, it shows: the same person in two profiles or two people merged into one, audiences that don't match the CRM, a marketing team that stops trusting the platform, and no one who can guarantee that data collected without consent didn't end up in a campaign.

It isn't just an operational issue, either. Mexico's new federal personal data protection law (Ley Federal de Protección de Datos Personales en Posesión de los Particulares, or LFPDPPP), published in March 2025, asks companies to strive to keep personal data accurate, complete, correct and up to date (Article 10), and treats keeping inaccurate data as a violation when the company is responsible for it (Article 58). We cover it in our guide to data protection and the LFPDPPP.

At WolfSellers we implement Adobe Experience Platform and Adobe Real-Time CDP for companies in Mexico. We explain what Real-Time CDP is and how it activates audiences in our Adobe Real-Time CDP guide. This article covers the layer that decides whether the project works: data governance.

---

What is data governance in Adobe Experience Platform

Data governance in Adobe Experience Platform is the set of decisions and controls that define how data is modeled (XDM schemas), how a person is recognized (identity), what minimum quality it must meet, what it can be used for (labels and policies), who can see it (access control), what permission it needs to be activated (consent) and when it's deleted (privacy and lifecycle).

In Adobe's documentation, Data Governance is a framework with three elements: labels, policies and enforcement. In a real project, governance also covers identity, quality and data lifecycle. And Adobe separates two questions that often get mixed up: governance controls how data is used; access control controls who can see it.

There's a technical reason to take it seriously from day one: AEP brings together data from many sources and, without rules, it brings together their errors too, which then travel to every audience and every connected destination.

The building blocks of data governance in AEP

Automatic enforcement happens when you activate an audience: Experience Platform checks the data's labels against the destination's marketing action and, if there's a violation, it won't let you save and shows the lineage that caused it. Audiences inherit the labels of their data.

Three things before you design:

1. Policies are disabled by default, including the ones Adobe provides out of the box. Labeling fields protects nothing until you enable them.
2. Several pieces depend on your license. Consent policies and their automatic enforcement require Adobe Healthcare Shield or Adobe Privacy & Security Shield. Attribute-based access control has limited availability for customers who purchase those Shields, which also give access to customer managed keys, and Privacy & Security Shield raises the record delete quota. Confirm with Adobe what your contract includes.
3. The schema is hard to fix later. Once it receives data or is enabled for Profile, it only accepts additive changes: you can't rename or remove fields, or change the primary identity of a Profile schema that already has data.

Identity: how to keep AEP from merging different people's profiles

Identity Service links identities that arrive together in the same event: if a login sends the browser identifier (ECID) and the CRM customer ID, AEP joins them in an identity graph. That's how the unified profile is born, and also the costliest governance problem, which Adobe calls graph collapse: misleading data that merges different people into a single profile. Adobe describes three causes; here's how they can look at a Mexican company:

How to design identity

1. One reliable person identity per profile, such as the CRM customer ID or the member number of a loyalty program, and a single person identifier per authenticated event, as Adobe recommends.
2. Identity graph linking rules, now generally available. A unique namespace appears only once per graph, so two different customer IDs don't merge. Namespace priority ranks their importance; the highest-priority namespace should be unique and becomes the primary identity of the events that enter Profile.
3. What happens in a conflict. The identity optimization algorithm honors the most recent links and removes the oldest ones: on a shared device, the browser stays with the last person who logged in.
4. Normalize before ingesting. Identity Service is case-sensitive: ana@gmail.com and ANA@GMAIL.COM are two different identities. And since August 3, 2019, Mexico dials 10 digits, without the 01, 044 or 045 prefixes, so a database with years of history mixes formats: standardize on E.164 (+52 plus the 10 digits for Mexico, +1 for the U.S. and Canada), which has a standard namespace in AEP.
5. Keep people apart from things. Products, stores or organizations go in as a non-people identifier, an identity type that doesn't connect to a person's graph.
6. Test before production. Graph simulation shows which links are kept with your configuration, without saving anything. Then validate in a development sandbox.

If your sandbox already has collapsed graphs

Adobe's guide assumes a sandbox with no data. With graphs that have already collapsed, enabling the rules doesn't fix them right away: they only change when new data arrives, and Adobe asks you to contact your account team or support. To measure the problem, the Graph count with multiple namespaces metric in the identity dashboard counts graphs with two or more identities from the same namespace, and the identity graph viewer shows which dataset and batch created each link.

Data quality: before, during and after ingestion

Quality is handled at three moments:

• Before, at the source or in the warehouse, where fixing is cheapest: profile each source (empty values, formats, duplicates), decide which record wins when there are two for the same customer, normalize emails, phone numbers, dates and reference lists, exclude junk values in identity fields ("N/A", "no email", test accounts) and don't ingest anything without a use case.
• During, in AEP: every record is validated against its XDM schema, and invalid ones are rejected. Data Prep transforms data with functions such as lower, trim or iif, but if a transformation fails, that attribute is set to null and the rest of the row is still ingested: a "successful" ingestion can hide empty columns. Partial batch ingestion tolerates a percentage of errors before failing the whole batch (5% by default) and turns on error diagnostics.
• After, in monitoring: dataflow monitoring compares records received, ingested and failed (for now, batch sources only), and the profile and identity dashboards show counts and collapsed graphs. Query Service runs ad hoc SQL queries of up to 10 minutes; scheduled jobs that clean data and write it back to the data lake require Data Distiller, an add-on.

How to connect your data warehouse to AEP

If you already consolidate customer data in a data warehouse —Snowflake, Google BigQuery, Databricks, Amazon Redshift or Azure Synapse, for example—, there are two ways to use it in AEP, and they can be combined:

• Ingest with source connectors. AEP copies the tables you choose into its data lake and, if the dataset is enabled for Profile, feeds identity and the customer profile. The Snowflake, Google BigQuery, Databricks and Amazon Redshift connectors are available to customers who have Real-Time CDP Ultimate.
• Compose audiences with Federated Audience Composition. A visual interface queries the warehouse without copying the underlying data; AEP keeps only the audience and the attributes you choose, ready for Adobe Real-Time CDP or Adobe Journey Optimizer, and it can also enrich existing audiences and profiles. It connects to Amazon Redshift, Azure Synapse, Databricks, Google BigQuery, Microsoft Fabric, Snowflake and Vertica, among others, and requires Real-Time CDP or Journey Optimizer in the Prime or Ultimate package, plus its own add-on.

Decide per dataset and use case: ingest what the profile needs in real time and federate heavy or sensitive tables. The quality of the warehouse model defines what reaches AEP, and that's where our data engineering and integrations team works.

Consent and Mexico's LFPDPPP in AEP

Capture. AEP stores consent in the profile with the Consents and Preferences field group (Adobe's standard) or with IAB TCF 2.0, and receives it through the Web SDK from your consent management platform (CMP), through the Mobile SDK or in batches. Your merge policy should make the most recent consent win.

Enforcement. The Web SDK automatically enforces only the data collection permission. Other consents are enforced in audience and journey rules, or automatically with consent policies, which filter profiles when activating to destinations and require one of the two Shields.

This is how ARCO rights (access, rectification, cancellation and opposition, as Mexican law calls them) work with AEP:

Two points to review with your legal team and with Adobe:

• The LFPDPPP isn't on Privacy Service's list of regulations. Every request is filed under a regulation from a closed list —GDPR, CCPA, Brazil's LGPD or Quebec's Law 25, among others— and, as of this writing, the Mexican law isn't there. Before launch, decide how you'll file requests from customers in Mexico.
• Deadlines. The LFPDPPP gives up to 20 days to communicate the response and 15 more to carry it out, extendable once (Article 31); in Privacy Service, each Adobe application can take anywhere from minutes to weeks. The process has to start the day the request arrives.

This isn't legal advice: the privacy notice and compliance criteria should be validated with a specialized law firm. Collaborating with a business partner's data without exchanging raw data is a separate layer, which we cover in data clean rooms with Adobe.

From governed data to a first use case

Data governance is what makes the first result credible. A good pilot uses data that's already available, one audience, one channel, one metric with a control group and a business owner who will make decisions with the result.

Customer AI, the AEP service for scoring, calculates conversion or churn propensity scores, explains which factors influence them and writes them to the profile for segmentation. It needs at least 500 events that meet the goal and 500 that don't, and the same identity namespace across all datasets; its availability depends on your edition and package.

That's why scoring comes last: if the graph merges two people, the model learns from behavior nobody had, and if there are duplicate profiles, each customer seems to buy less than they actually do. To measure the pilot across channels, Adobe Customer Journey Analytics works on the same AEP datasets.

Who does what: the operating model

The minimum cadence we recommend: a design and identity review before each new source, ingestion errors every week, graphs and counts every month, and labels, policies and permissions every quarter.

Common mistakes

1. Ingesting everything and designing the schema later.
2. Using email or phone as identity without normalizing it.
3. Sending several person identifiers per event, or empty identities.
4. Enabling linking rules on collapsed graphs without a plan with Adobe.
5. Labeling fields without enabling the policies.
6. Assuming the Web SDK enforces all consent: it only enforces data collection.
7. Changing the default merge policy without reviewing existing audiences, which keep using the previous one.
8. Handling ARCO rights with record deletes instead of Privacy Service.
9. Measuring the pilot without a control group.

How we do it at WolfSellers

We start with an assessment: schemas, namespaces and identities, quality by source, the state of the graphs, consent, permissions and licensed capabilities. With that we prioritize cleanup at the source or in the warehouse and design the identity strategy, which we test in simulation and in a sandbox before touching production.

Then we configure what your license allows —labels, policies, access, consent and lifecycle—, document what gets handled through processes when a piece isn't licensed, launch a pilot —cart recovery, repurchase or a scoring model— and hand over operations: dashboards, cadences and owners.

If it isn't clear yet which use cases to prioritize, we start with a CX Strategy discovery. Our Adobe Experience Platform, Adobe Real-Time CDP and data engineering services cover everything from assessment to operations. If you'd like to review your case, you can contact us.

---

Frequently asked questions about data governance in Adobe Experience Platform

What is data governance in Adobe Experience Platform?

It's the set of decisions and controls over how data is modeled, identified, validated, used, protected and deleted in Adobe Experience Platform (AEP). It relies on XDM schemas, Identity Service, merge policies, data usage labels and policies, access control, Privacy Service and Advanced Data Lifecycle Management.

How do I keep AEP from merging profiles of different people?

Configure a person identity, such as the customer ID, as a unique namespace with the highest priority in the identity graph linking rules, and send a single person identifier per authenticated event. Normalize emails and phone numbers, exclude generic values and test first with graph simulation.

Do I have to copy my data warehouse into AEP to activate audiences?

Not necessarily. With Federated Audience Composition, an add-on, you compose audiences by querying the warehouse, and AEP keeps only the audience and the attributes you choose. If you need a real-time profile, ingest with source connectors; the warehouse ones require Real-Time CDP Ultimate.

Does AEP help me comply with Mexico's LFPDPPP?

It gives you tools —labels and policies, consent in the profile, access control, Privacy Service and scheduled data deletion—, but it doesn't comply for you. The LFPDPPP isn't on Privacy Service's list of regulations, so the ARCO process has to be designed with your legal team; GDPR, CCPA and Quebec's Law 25 are on that list if you also operate under them.

What are data usage labels?

They're classifications applied to schema fields: contract labels (for example, no export to third parties), identity labels (data that directly or indirectly identifies a person), sensitive labels (such as precise geolocation) or your own. Once policies are enabled, that data can't reach destinations whose marketing action is restricted.

Where do I start if my data is scattered?

With an inventory of sources and one decision: which person identifier is reliable. Then clean up at the source, design schemas and identity in a development sandbox, and ingest first what a specific pilot needs.

Who can review my data quality and identity model in AEP?

A team that combines platform expertise, data engineering and privacy. At WolfSellers we run that assessment —schemas, namespaces, linking rules, graphs, quality by source and consent— and deliver a prioritized plan with a pilot to prove value.

Related services

If this topic is relevant to your business, these services from WolfSellers can help you implement it:

• Adobe Experience Platform
• Adobe Real-Time CDP
• Data Engineering & Integrations