Experience Platform · Merge policies
Qué dato gana
Laura está en tres datasets habilitados para Profile y no dicen lo mismo. Ayer a las 18:10 cambió el email y la ciudad en su cuenta del ecommerce, y se dio de baja de los emails. Esta mañana entraron los batch del CRM y de fidelización con datos anteriores. La merge policy decide qué valor ve AJO.
Supuestos del ejemplo
Clienta, datasets, valores y horas de ejemplo.
Datasets habilitados para Profile
Los tres fragmentos de Laura
Una fila por atributo y una columna por dataset, en el orden en que los aplica la merge policy. Gana la primera celda con valor.
Real-Time Customer Profile
Lo que ve AJO
Cuántos atributos acierta el perfil unido, y qué se rompe por cada uno que falla.
La recomendación
Un dueño por atributo y un solo dueño por dataset. Entonces la merge policy es trivial
Ningún orden acierta los cinco atributos, porque cada dataset mezcla datos propios con copias de otros sistemas. Una merge policy ordena datasets, no campos. Se arregla en lo que manda cada fuente.
- 01
Un dueño por atributo
Email y ciudad, la cuenta del ecommerce. Consentimiento, el centro de preferencias. Idioma, el CRM de atención al cliente. Nivel del club, el programa de fidelización.
- 02
Cada fuente manda solo lo suyo
El CRM deja de reexportar cada noche el email y el consentimiento que no controla, y fidelización deja de mandar el email. Cada dataset lleva solo atributos de su sistema, con upsert.
- 03
Merge policy sin conflictos
Con un dueño por dataset casi no hay conflictos, y timestamp ordered basta. Dataset precedence sirve de red para los pocos solapes que queden, ordenada por confianza.
- 04
Misma lógica en el Edge
Solo hay una merge policy activa en el Edge por sandbox, y la usan la personalización web y los mensajes entrantes. Si no resuelve igual que la de AJO, la web y el email verán a otra Laura.