Web SDK · consentimiento y datastreams
El viaje de un evento
Laura entra en la ficha de unas zapatillas y le sale el banner de cookies. Lo que pasa con sus eventos depende del defaultConsent del Web SDK antes de que conteste y de lo que la CMP pase a setConsent después. Cuando un evento sale, el datastream decide a qué servicios llega.
Supuestos del ejemplo
Visita, eventos y configuración de ejemplo. Los cambios en un datastream pueden tardar hasta 35 minutos en aplicarse en toda la Edge Network.
La visita
Qué pasa con cada evento
Eventos de la visita en orden, con la decisión de Laura en medio y los servicios que reciben cada evento enviado.
Lectura
Qué conviene revisar
Las consecuencias de la configuración elegida, para la privacidad de Laura y para los servicios.
Arquitectura
Dónde encaja en la plataforma
Diagrama de secuencia de una petición del Web SDK, con siete participantes: la página, que es una ficha de producto; el Web SDK, alloy.js; el Edge Network con su datastream; Journey Optimizer, que decide en el Edge Network; Experience Platform, con un dataset y Profile; Customer Journey Analytics con su conexión; y event forwarding hacia la API de conversiones de Meta. Salida: la página pasa al Web SDK el consentimiento in de la CMP con setConsent y después llama a sendEvent con commerce.productViews. El Web SDK hace un POST al endpoint interact con el evento XDM. Decisión: el Edge Network pide propuestas a Journey Optimizer, que devuelve un banner. El Edge Network responde al Web SDK con las propuestas y el ECID, que el Web SDK reutiliza, y el Web SDK pinta el banner sin una segunda llamada. Solo la propuesta de Journey Optimizer viaja en esa respuesta, y para eso hace falta una merge policy Active-On-Edge. Reparto: el Edge Network manda el evento XDM al dataset y a Profile, la conexión de Customer Journey Analytics lee ese dataset, y el Edge Network aplica la regla de vista de producto para reenviarla a CAPI. Medición: después de pintar, el Web SDK envía la notificación de display. Con el consentimiento en out, el evento no sale del navegador, y sin evento en el Edge Network no hay nada que reenviar.
La recomendación
defaultConsent en pending donde la ley lo pide, setConsent lo antes posible y un datastream con lo justo
El Web SDK hace lo que se le configura. Los problemas vienen de no decidir qué pasa antes de que el usuario conteste y de conectar servicios por si acaso.
- 01
defaultConsent en pending donde se requiere consentimiento
No se crea ECID ni cookies de identidad hasta que el usuario decide, y los eventos esperan en cola. Con in por defecto se recoge antes de preguntar.
- 02
setConsent en cuanto se sabe
Al cargar la página con la decisión guardada en la CMP, y justo al contestar el banner. La cola de pending vive en memoria: si cambia de página antes, esos eventos se pierden.
- 03
Un datastream con lo justo
Cada servicio activado recibe los eventos. Añadir Target, Analytics o event forwarding por si acaso es mandar datos a donde no hacen falta. Un datastream por entorno.
- 04
Consentimiento también en el perfil
Con un profile dataset en el datastream y el field group de consentimiento en el schema, la preferencia llega a Real-Time Customer Profile y AJO la puede respetar.