Gobierno de datos en Adobe Experience Platform (AEP): guía

Adobe Experience Platform (AEP) promete un perfil por cliente, construido con los datos de todos tus sistemas y listo para activarse en cualquier canal. Esa promesa depende de lo que entra. Cuando el gobierno de datos falla, se nota: la misma persona en dos perfiles o dos personas fusionadas en uno, audiencias que no cuadran con el CRM, un equipo de marketing que deja de confiar en la plataforma y nadie que pueda asegurar que un dato sin consentimiento no terminó en una campaña.

Tampoco es solo un tema operativo. La nueva Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), publicada en marzo de 2025, pide procurar que los datos personales sean exactos, completos, correctos y actualizados (artículo 10), y considera infracción mantener datos inexactos cuando es imputable a la empresa (artículo 58). Lo explicamos en nuestra guía de protección de datos y LFPDPPP.

En WolfSellers implementamos Adobe Experience Platform y Adobe Real-Time CDP para empresas en México. Qué es Real-Time CDP y cómo activa audiencias lo explicamos en nuestra guía de Adobe Real-Time CDP. Esta nota cubre la capa que decide si el proyecto funciona: el gobierno de los datos.

---

Qué es el gobierno de datos en Adobe Experience Platform

El gobierno de datos en Adobe Experience Platform es el conjunto de decisiones y controles que definen cómo se modelan los datos (esquemas XDM), cómo se reconoce a una persona (identidad), qué calidad mínima deben tener, para qué se pueden usar (etiquetas y políticas), quién puede verlos (control de acceso), con qué permiso se activan (consentimiento) y cuándo se eliminan (privacidad y ciclo de vida).

En la documentación de Adobe, Data Governance es un marco de tres elementos: etiquetas, políticas y su aplicación. En un proyecto real el gobierno también abarca la identidad, la calidad y el ciclo de vida. Y Adobe separa dos preguntas que se suelen mezclar: el gobierno controla cómo se usa un dato; el control de acceso, quién puede verlo.

Tomarlo en serio desde el primer día tiene una razón técnica: AEP une datos de muchas fuentes y, sin reglas, une también sus errores, que después viajan a cada audiencia y a cada destino conectado.

Las piezas del gobierno de datos en AEP

La aplicación automática ocurre al activar una audiencia: Experience Platform cruza las etiquetas de los datos con la acción de marketing del destino y, si hay una violación, no te deja guardar y muestra el linaje que la provoca. Las audiencias heredan las etiquetas de sus datos.

Tres cosas antes de diseñar:

1. Las políticas vienen desactivadas, incluidas las que Adobe trae de fábrica. Etiquetar campos no protege nada hasta que las activas.
2. Varias piezas dependen de tu licencia. Las políticas de consentimiento y su aplicación automática requieren Adobe Healthcare Shield o Adobe Privacy & Security Shield. El control de acceso basado en atributos tiene disponibilidad limitada para quienes compran esos Shields, que también dan acceso a las llaves propias, y Privacy & Security Shield amplía la cuota de eliminación de registros. Confirma con Adobe qué incluye tu contrato.
3. El esquema es difícil de corregir. Una vez que recibe datos o se habilita para perfil, solo admite cambios aditivos: no puedes renombrar ni quitar campos, ni cambiar la identidad principal de un esquema de perfil con datos.

Identidad: cómo evitar que AEP una perfiles de personas distintas

Identity Service liga las identidades que llegan juntas en un mismo evento: si un inicio de sesión envía el identificador del navegador (ECID) y el ID de cliente del CRM, AEP los une en un grafo de identidad. Así nace el perfil unificado y también el problema de gobierno más costoso, que Adobe llama graph collapse: datos engañosos que juntan en un perfil a personas distintas. Adobe describe tres causas; así pueden verse en una empresa mexicana:

Cómo diseñar la identidad

1. Una identidad de persona confiable por perfil, como el ID de cliente del CRM o el número de socio de un programa de lealtad, y un solo identificador de persona por evento autenticado, como recomienda Adobe.
2. Reglas de enlace del grafo (identity graph linking rules), ya disponibles de forma general. Un namespace único aparece una sola vez por grafo, así que dos IDs de cliente distintos no se fusionan. La prioridad de namespaces ordena su importancia; el de mayor prioridad debe ser único y se vuelve la identidad principal de los eventos que entran al perfil.
3. Qué pasa en un conflicto. El algoritmo de optimización de identidad conserva los enlaces más recientes y elimina los más antiguos: en un dispositivo compartido, el navegador queda con la última persona que inició sesión.
4. Normaliza antes de ingestar. Identity Service distingue mayúsculas y minúsculas: ana@gmail.com y ANA@GMAIL.COM son dos identidades distintas. Y desde el 3 de agosto de 2019 en México se marca a 10 dígitos, sin los prefijos 01, 044 ni 045, así que una base con historia mezcla formatos: estandarízalos en E.164 (+52 y los 10 dígitos), que tiene un namespace estándar en AEP.
5. Separa personas de cosas. Productos, tiendas u organizaciones van como non-people identifier, un tipo de identidad que no se conecta al grafo de una persona.
6. Prueba antes de producción. La simulación de grafos muestra qué enlaces se conservan con tu configuración, sin guardar nada. Después valida en una sandbox de desarrollo.

Si tu sandbox ya tiene grafos colapsados

La guía de Adobe parte de una sandbox sin datos. Con grafos ya colapsados, activar las reglas no los corrige de inmediato: solo cambian cuando llegan datos nuevos, y Adobe pide contactar a tu equipo de cuenta o a soporte. Para medirlo, en el tablero de identidades el indicador Graph count with multiple namespaces cuenta los grafos con dos o más identidades del mismo namespace, y el visor de grafos muestra qué dataset y qué lote creó cada enlace.

Calidad de datos: antes, durante y después de la ingesta

La calidad se trabaja en tres momentos:

• Antes, en el origen o en el warehouse, donde corregir sale más barato: perfila cada fuente (vacíos, formatos, duplicados), define qué registro gana cuando hay dos del mismo cliente, normaliza correos, teléfonos, fechas y catálogos, excluye valores basura en campos de identidad ("N/A", "sin correo", cuentas de prueba) y no ingestes lo que no tiene un caso de uso.
• Durante, en AEP: cada registro se valida contra su esquema XDM y los inválidos se rechazan. Data Prep transforma con funciones como lower, trim o iif, pero si una transformación falla, ese atributo queda en nulo y el resto de la fila sí entra: una ingesta "exitosa" puede esconder columnas vacías. La ingesta parcial por lotes tolera un porcentaje de errores antes de rechazar el lote completo (5% por defecto) y activa el diagnóstico de errores.
• Después, en el monitoreo: el monitoreo de flujos de datos compara registros recibidos, ingestados y fallidos (por ahora, solo en fuentes por lotes), y los tableros de perfiles e identidades muestran conteos y grafos colapsados. Query Service permite consultas SQL ad hoc de hasta 10 minutos; los procesos programados que limpian y escriben de vuelta en el data lake requieren Data Distiller, que es un add-on.

Cómo conectar tu data warehouse con AEP

Si ya consolidas tus datos de clientes en un data warehouse —Snowflake, Google BigQuery, Databricks, Amazon Redshift o Azure Synapse, por ejemplo—, hay dos caminos para usarlos en AEP, y se pueden combinar:

• Ingestar con conectores de origen. AEP copia las tablas que elijas a su data lake y, si el dataset está habilitado para perfil, alimenta la identidad y el perfil del cliente. Los conectores de Snowflake, Google BigQuery, Databricks y Amazon Redshift están disponibles para quienes tienen Real-Time CDP Ultimate.
• Componer audiencias con Federated Audience Composition. Una interfaz visual consulta el warehouse sin copiar los datos de fondo; en AEP solo quedan la audiencia y los atributos elegidos, listos para Adobe Real-Time CDP o Adobe Journey Optimizer, y también sirve para enriquecer audiencias y perfiles. Se conecta, entre otros, con Amazon Redshift, Azure Synapse, Databricks, Google BigQuery, Microsoft Fabric, Snowflake y Vertica, y requiere Real-Time CDP o Journey Optimizer en paquete Prime o Ultimate, más su propio add-on.

Se decide por dataset y caso de uso: ingesta lo que el perfil necesita en tiempo real y federa las tablas pesadas o sensibles. La calidad del modelo en el warehouse define lo que llega a AEP, y ahí trabaja nuestro equipo de ingeniería de datos e integraciones.

Consentimiento y LFPDPPP en AEP

Captura. AEP guarda el consentimiento en el perfil con el field group Consents and Preferences (estándar de Adobe) o con IAB TCF 2.0, y lo recibe por el Web SDK desde tu plataforma de gestión de consentimiento (CMP), por el Mobile SDK o por lotes. La política de fusión debe hacer que gane el consentimiento más reciente.

Aplicación. El Web SDK solo aplica de forma automática el permiso de recolección de datos. Los demás consentimientos se aplican en las reglas de audiencias y journeys, o automáticamente con políticas de consentimiento, que filtran perfiles al activar en destinos y requieren alguno de los dos Shields.

Así se operan los derechos ARCO con AEP:

Dos puntos para revisar con tu área legal y con Adobe:

• La LFPDPPP no está en la lista de regulaciones de Privacy Service. Cada solicitud se registra bajo una regulación de una lista cerrada —GDPR, CCPA, la LGPD de Brasil o la Ley 25 de Quebec, entre otras— y, al cierre de esta nota, la ley mexicana no aparece. Define antes de lanzar cómo registrarás las solicitudes de clientes en México.
• Los plazos. La LFPDPPP da hasta 20 días para comunicar la respuesta y 15 más para hacerla efectiva, ampliables una vez (artículo 31); en Privacy Service, cada aplicación de Adobe puede tardar de minutos a semanas. El flujo tiene que arrancar el día que llega la solicitud.

Esto no es asesoría legal: el aviso de privacidad y los criterios de cumplimiento se validan con un despacho especializado. Colaborar con datos de un socio comercial sin intercambiar datos crudos es otra capa, que cubrimos en data clean rooms con Adobe.

Del dato gobernado al primer caso de uso

El gobierno de datos es lo que vuelve creíble el primer resultado. Un buen piloto usa datos que ya están disponibles, una audiencia, un canal, una métrica con grupo de control y un dueño de negocio que decida con el resultado.

Customer AI, el servicio de AEP para scoring, calcula puntuaciones de propensión de conversión o de abandono, explica qué factores influyen y las escribe en el perfil para segmentar. Pide al menos 500 eventos que cumplen el objetivo y 500 que no, y el mismo namespace de identidad en todos los datasets; su disponibilidad depende de tu edición y paquete.

Por eso el scoring va al final: si el grafo fusiona a dos personas, el modelo aprende de un comportamiento que nadie tuvo, y si hay perfiles duplicados, cada cliente parece comprar menos de lo que compra. Para medir el piloto entre canales, Adobe Customer Journey Analytics trabaja sobre los mismos datasets de AEP.

Quién hace qué: el modelo operativo

La cadencia mínima que recomendamos: revisión de diseño e identidad antes de cada fuente nueva, errores de ingesta cada semana, grafos y conteos cada mes, y etiquetas, políticas y permisos cada trimestre.

Errores frecuentes

1. Ingestar todo y diseñar el esquema después.
2. Usar correo o teléfono como identidad sin normalizarlos.
3. Enviar varios identificadores de persona por evento, o identidades vacías.
4. Activar reglas de enlace sobre grafos colapsados sin un plan con Adobe.
5. Etiquetar campos sin activar las políticas.
6. Creer que el Web SDK aplica todo el consentimiento: solo aplica el de recolección.
7. Cambiar la política de fusión predeterminada sin revisar las audiencias existentes, que siguen con la anterior.
8. Atender derechos ARCO con la eliminación de registros en lugar de Privacy Service.
9. Medir el piloto sin grupo de control.

Cómo lo hacemos en WolfSellers

Empezamos con un diagnóstico: esquemas, namespaces e identidades, calidad por fuente, estado de los grafos, consentimiento, permisos y licencias contratadas. Con eso priorizamos la limpieza en el origen o en el warehouse y diseñamos la identidad, que probamos en simulación y en una sandbox antes de tocar producción.

Después configuramos lo que tu licencia permite —etiquetas, políticas, acceso, consentimiento y ciclo de vida—, documentamos qué se resuelve con procesos cuando una pieza no está contratada, lanzamos un piloto —recuperación de carritos, recompra o un modelo de scoring— y entregamos la operación: tableros, cadencias y responsables.

Si todavía no está claro qué casos de uso priorizar, empezamos con un discovery de CX Strategy. Nuestros servicios de Adobe Experience Platform, Adobe Real-Time CDP e ingeniería de datos cubren desde el diagnóstico hasta la operación. Si quieres revisar tu caso, puedes escribirnos.

---

Preguntas frecuentes sobre gobierno de datos en Adobe Experience Platform

¿Qué es el gobierno de datos en Adobe Experience Platform?

Es el conjunto de decisiones y controles sobre cómo se modelan, identifican, validan, usan, protegen y eliminan los datos en Adobe Experience Platform (AEP). Se apoya en esquemas XDM, Identity Service, políticas de fusión, etiquetas y políticas de uso, control de acceso, Privacy Service y Advanced Data Lifecycle Management.

¿Cómo evito que AEP una perfiles de personas distintas?

Configura una identidad de persona, como el ID de cliente, como namespace único y con la mayor prioridad en las reglas de enlace del grafo, y envía un solo identificador de persona por evento autenticado. Normaliza correos y teléfonos, excluye valores genéricos y prueba antes con la simulación de grafos.

¿Tengo que copiar mi data warehouse a AEP para activar audiencias?

No necesariamente. Con Federated Audience Composition, que es un add-on, compones audiencias consultando el warehouse y en AEP solo se guardan la audiencia y los atributos que elijas. Si necesitas perfil en tiempo real, ingesta con conectores de origen; los de warehouse requieren Real-Time CDP Ultimate.

¿AEP me ayuda a cumplir la LFPDPPP?

Te da herramientas —etiquetas y políticas, consentimiento en el perfil, control de acceso, Privacy Service y eliminación programada de datos—, pero no cumple por ti. La LFPDPPP no aparece en la lista de regulaciones de Privacy Service, así que el flujo ARCO se diseña con tu área legal; el GDPR sí está incluido, si también operas en Europa.

¿Qué son las etiquetas de uso de datos?

Son clasificaciones que se aplican a los campos de un esquema: de contrato (por ejemplo, no exportar a terceros), de identidad (datos que identifican directa o indirectamente a una persona), sensibles (como la geolocalización precisa) o propias. Con las políticas activadas, esos datos no pueden llegar a destinos cuya acción de marketing está restringida.

¿Por dónde empiezo si mis datos están dispersos?

Por un inventario de fuentes y una decisión: cuál es el identificador de persona confiable. Luego limpia en el origen, diseña esquemas e identidad en una sandbox de desarrollo e ingesta primero lo que necesita un piloto concreto.

¿Quién puede revisar la calidad de mis datos y mi modelo de identidad en AEP?

Un equipo que combine experiencia en la plataforma, ingeniería de datos y privacidad. En WolfSellers hacemos ese diagnóstico —esquemas, namespaces, reglas de enlace, grafos, calidad por fuente y consentimiento— y entregamos un plan priorizado con un piloto para demostrar valor.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

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