Saltar al contenido principal
Adrià García
← Volver a los simuladores

Experience Platform · Identity Service

¿Cuántos perfiles tiene una persona?

Laura añade un producto al carrito en la web y lo compra en la app. Si ambas fuentes no comparten una identidad, parecen clientes distintos. Empieza por conectarlas. Después puedes explorar los perfiles de Marc y Núria y el riesgo de unir a dos personas.

Escenario

Prueba este cambio

Laura navega en la web y compra en la app, pero sus datos quedan separados. Conecta ambas fuentes con el CRM y observa qué perfiles se unen. El botón recupera los demás ajustes iniciales.

Web SDK envía Email tras el login

En el identityMap, junto al ECID.

Mobile SDK envía CRMID tras el login

Si no, la compra de la app entra sin CRMID.

Ver el resultado completo ↓
Más ajustes (5)
La centralita manda el teléfono en E.164

+34600000111 en Phone (E.164), como lo guarda el CRM. Si no, 600 000 111 en Phone.

La landing del email de AJO identifica el clic

La landing identifica a la clienta y el Web SDK lo envía con el ECID.

El TPV de tienda resuelve el CRMID

Desde la tarjeta de fidelización, junto al loyaltyId.

Job nocturno de Data Distiller

Cruza campos que no son identidad y escribe registros puente en un dataset habilitado para Profile.

Linking Rules: CRMID único

Un grafo no puede contener dos CRMID.

Escenario ilustrativo ↑ Volver a los controles
Supuestos del ejemplo

Personas, valores y tienda inventados. CRMID y loyaltyId son namespaces personalizados del ejemplo.

Real-Time Customer Profile

Los perfiles que salen

Compara con el estado inicial y sigue primero a Laura. El detalle de identidades y eventos está debajo.

AJO · Target · operación

Qué pasa en AJO, Target y la operación

Lo que ve cada equipo con los perfiles de arriba.

La recomendación

Identidades comunes en origen, CRMID como namespace único y el stitching solo como puente

El grafo no puede inventar relaciones que las fuentes no emiten. Lo que dura se arregla en la recogida de datos. Identity Service lo protege, y el job de Data Distiller solo tapa el hueco mientras tanto.

  1. 01

    Contrato de identidad por fuente

    Web SDK con ECID y, tras el login, Email en el identityMap. Mobile SDK con CRMID. La landing de AJO identifica el clic. El TPV resuelve el CRMID desde la tarjeta de fidelización.

  2. 02

    El teléfono, como lo guarda el CRM

    La centralita manda +34600000111 en el namespace Phone (E.164). Si lo manda como 600 000 111 en Phone, son dos identidades distintas.

  3. 03

    Identity Graph Linking Rules

    CRMID como namespace único y con la prioridad más alta. Un teléfono o un dispositivo compartido ya no junta a dos personas. Adobe pide que ese namespace esté en todos los perfiles conocidos.

  4. 04

    Stitching con fecha de caducidad

    Si hace falta un job de Data Distiller que escriba registros puente, que tenga responsable y condición de retirada. Cuando lleve varias semanas sin escribir nada, se apaga.

Nota de arquitectura · 01 La identidad es un contrato con el origen Un grafo resuelve evidencia. No inventa relaciones que los orígenes nunca emiten. Leer la nota →
Prueba otra decisión ¿Podemos guardar menos sin perder lo que necesitamos? → ¿Qué eventos tienen que estar en Profile y cuáles basta con que vivan en el data lake?