Experience Platform · Ingesta de registros de perfil
La carga que borró los nombres
A las 02:00 entra el batch diario del ecommerce en el dataset de clientes, de clase XDM Individual Profile y habilitado para Profile. Solo trae un cambio: Laura tiene email nuevo. Por la mañana, su perfil ya no tiene nombre. Nadie ha borrado nada.
Supuestos del ejemplo
Clienta, datasets, valores y volúmenes inventados.
Dataset de clientes
El perfil de Laura, ayer y hoy
Atributo por atributo: lo que había, si el batch de las 02:00 lo trae y lo que queda. En rojo, lo que se borra.
Journey Optimizer · web
Qué pasa a las 09:00 en AJO y en la web
Tres momentos de la mañana. El email del journey personaliza con {{profile.person.name.firstName}}.
Todo el batch
Y no es solo Laura
A todos los clientes del batch les pasa lo mismo.
La recomendación
Upsert en los datasets de perfil, un origen por dataset y probarlo antes en un sandbox
La ingesta estándar no es un error: es el comportamiento documentado. El problema es no decidir cómo tiene que entrar cada fuente antes de conectarla.
- 01
Decidir cómo entra cada fuente
Antes de conectarla: si manda el registro entero o solo lo que cambió. De eso depende cómo se configura el dataset.
- 02
Upsert donde entran cambios parciales
En batch, un dataset habilitado para Profile y para upsert. En streaming, las actualizaciones parciales de Data Prep. Así cada fuente manda solo lo que cambió y no vacía el resto.
- 03
Un dataset, un sistema que escribe
El nivel del club, en su propio dataset, que solo escribe el programa de fidelización. Real-Time Customer Profile une los fragmentos con la merge policy, y ninguna carga pisa lo de otro sistema.
- 04
Probarlo en un sandbox de desarrollo
Un batch de prueba con un solo registro y revisar el perfil en el visor de Profile: qué atributos quedan en null. Diez minutos antes de conectar la fuente en producción.