Grafo o stitching

Comparación entre el identity graph y el stitching de Customer Journey Analytics, de arriba abajo en cinco etapas. Datos: eventos web del Web SDK con ECID, y con CRMID cuando hay login, y un CRM en batch con CRMID y email. Data Lake: eventos y registros llegan a sus datasets, con la identidad principal marcada como primary=true. Identidad: el Data Lake pasa las identidades a Identity Service, que las enlaza en un grafo con sus Linking Rules. Por otro lado, los datasets de eventos llegan a la connection de CJA, que fija un person ID por dataset. Resolución, para activar: el grafo llega a Profile, que fusiona en tiempo real según su merge policy, y el perfil fusionado sale a AJO y Destinations para actuar. Las audiencias se evalúan sobre ese perfil fusionado según su merge policy, que usa el grafo para reunir las identidades relacionadas. Las identity settings no se desactivan sin resetear el sandbox. Resolución, para medir, por dos caminos. Field-based stitching, desde CJA Select, recibe el persistent ID y el person ID del mismo dataset. Graph-based stitching, desde CJA Prime, recibe el persistent ID, lo busca en el grafo y obtiene un namespace. Ignora los timestamps y hereda la calidad del grafo. Uso: los dos entregan a Workspace un person ID por fila, para People y atribución, y el replay reescribe el histórico dentro de la ventana de lookback. La clave compartida: el namespace único de mayor prioridad en el grafo debería ser el person ID de la connection. Las audiencias de CJA que se publican en Profile envían ese person ID, y si no hay perfil con esa identidad se crea uno nuevo.