Cuatro stacks, de la captura a la activación

Web: La web recoge eventos e identidades permitidas mediante Web SDK. El consentimiento condiciona la recogida y los usos posteriores. App móvil: La app envía eventos mediante Mobile SDK y la extensión Edge Network; el login aporta una identidad conocida cuando corresponde. CRM y soporte: Los sistemas de registro aportan atributos y preferencias con identificadores estables. Hay que decidir qué fuente prevalece. Pedidos y tiendas: Compras y devoluciones llegan desde el backend o mediante cargas de ficheros; no dependen de que el navegador confirme la operación. Edge Network: El datastream enruta a los servicios habilitados. El camino de personalización en sesión se configura aquí, separado del análisis histórico. Ingesta de fuentes: Los conectores y las API ingresan datos con sus cadencias y límites. Data Prep adapta campos al esquema XDM. Real-Time Profile: Los datasets habilitados aportan fragmentos. Identidad y políticas de combinación determinan el perfil disponible para activación. Data lake: Los datasets conservan los datos ingresados según su retención. No se presupone que toda escritura en Profile deje una copia aquí. Personalización Edge: La segmentación y los destinos compatibles con Edge permiten responder durante la visita cuando se cumplen sus requisitos. Audiencias RT-CDP: La evaluación de audiencias tiene su propia cadencia. Antes de exportar se aplican las políticas configuradas y las restricciones del destino. Journey Optimizer: El journey necesita una entrada configurada, un perfil elegible y controles de canal. Una pertenencia a audiencia no garantiza un envío inmediato. CJA: CJA combina datasets mediante una conexión y una vista de datos. No lee sin más el perfil unificado de RT-CDP. Web y app: La experiencia recibe decisiones mediante la integración configurada. Hay que contemplar ausencia de decisión y contenido de respaldo. Plataformas de ads: El destino recibe las identidades y audiencias permitidas. Aceptación y matching pertenecen al sistema receptor. Email, push y SMS: La ejecución depende del canal, sus credenciales y la elegibilidad del destinatario. Enviar no equivale a entregar. Análisis y retorno: El análisis relaciona interacciones y resultados. Ingresar los resultados permite revisar decisiones, sin convertir la medición en activación automática. Durante la visita: Web → Edge Network → Personalización Edge → Web y app. De CRM a publicidad: CRM y soporte → Ingesta de fuentes → Real-Time Profile → Audiencias RT-CDP → Plataformas de ads. De app a mensaje: App móvil → Edge Network → Real-Time Profile → Journey Optimizer → Email, push y SMS. De compra a análisis: Pedidos y tiendas → Ingesta de fuentes → Data lake → CJA → Análisis y retorno.

Web: La capa de datos web define eventos e identificadores; iQ y Collect los transportan según la configuración y el consentimiento. App móvil: El SDK recoge interacciones de la app con una taxonomía coherente con la web. Pedidos y backend: El backend envía eventos de negocio. Los identificadores de evento permiten diseñar la deduplicación donde sea necesaria. CRM y tiendas: Los datos offline requieren un contrato de identificadores y una importación configurada; no se cosen por parecido. Collect: Collect recibe eventos desde web, app y servidores. Los orígenes se identifican y validan antes de activar. File Import: La importación transforma filas en eventos con campos mapeados al modelo acordado. EventStream: EventStream valida y enriquece eventos y los enruta mediante feeds y conectores configurados. AudienceStream: AudienceStream mantiene atributos del visitante y audiencias. El stitching depende de atributos de identificación configurados. Conectores de evento: Una acción de conector envía el evento admitido por el destino. Reintentos y deduplicación se revisan para esa acción. Conectores de perfil: Los cambios de audiencia disparan acciones configuradas. Eliminar de una audiencia también necesita una operación de salida. Exportación de eventos: Una exportación a BigQuery conserva eventos para análisis; esquema y retención se diseñan en el destino. Conversiones de ads: Las API de publicidad reciben conversiones permitidas. El consentimiento, el matching y la deduplicación siguen siendo necesarios. Engagement y CRM: El sistema receptor usa atributos o pertenencias para sus propias campañas. Tealium no sustituye al motor de mensajes. BigQuery y BI: El warehouse reúne eventos y resultados de campaña para análisis y reconciliación, con ingestas de retorno explícitas. Conversión de backend: Pedidos y backend → Collect → EventStream → Conectores de evento → Conversiones de ads. Perfil desde la app: App móvil → Collect → EventStream → AudienceStream → Conectores de perfil → Engagement y CRM. Datos offline: CRM y tiendas → File Import → EventStream → AudienceStream → Conectores de perfil → Engagement y CRM. Histórico de eventos: Web → Collect → EventStream → Exportación de eventos → BigQuery y BI.

Web: La web recoge medición permitida. El etiquetado server-side no elimina las obligaciones de consentimiento ni crea identidades conocidas. App móvil: La app envía eventos de medición a GA4 mediante Firebase Analytics; sus datos pueden exportarse a BigQuery. Pedidos y backend: Los eventos operativos viajan por un pipeline propio; no es necesario convertir cada hecho de negocio en un evento analítico de GA4. CRM y soporte: Los registros se extraen con identificadores estables, preferencias y reglas de actualización explícitas. GTM server-side: El contenedor procesa peticiones mediante clientes y etiquetas. En este ejemplo envía medición a GA4. GA4: La exportación lleva eventos de GA4 a BigQuery con sus límites y cadencias. No es una exportación del perfil completo de una CDP. Pub/Sub + Dataflow: Pub/Sub recibe mensajes y Dataflow puede escribirlos en BigQuery. El equipo define esquema, errores y deduplicación. Cloud Storage: Los ficheros se cargan con esquema y control de actualización; hay que vigilar frescura y fallos de carga. BigQuery · origen: Se mantienen datasets de origen separados para medir calidad y reconstruir transformaciones. Modelo de cliente: Dataform ejecuta transformaciones SQL y comprobaciones. El equipo define unión por identificador, prioridad de fuentes y borrado. Ads Data Manager: Se conecta el modelo admitido de BigQuery a una importación de Customer Match, respetando elegibilidad, campos y consentimiento. Cloud Run · API: Un proceso propio publica atributos seleccionados en una capa de servicio. Debe implementar autenticación, borrados, reintentos y frescura. Looker: Looker consulta datos modelados para analizar resultados. Una visualización no ejecuta por sí misma una campaña. Google Ads: Google Ads recibe la lista y aplica sus requisitos de uso y matching. El número de registros no equivale al de usuarios alcanzables. Web y app propias: La aplicación consume la capa de servicio con una identidad autorizada. Esta personalización se desarrolla; no viene incluida en BigQuery. Análisis de resultados: Se contrastan ventas, comportamiento y resultados. Los datos de campañas requieren su propia ingesta de retorno. CRM a Customer Match: CRM y soporte → Cloud Storage → BigQuery · origen → Modelo de cliente → Ads Data Manager → Google Ads. Medición web: Web → GTM server-side → GA4 → BigQuery · origen → Modelo de cliente → Looker → Análisis de resultados. Activación propia: Pedidos y backend → Pub/Sub + Dataflow → BigQuery · origen → Modelo de cliente → Cloud Run · API → Web y app propias. Análisis de la app: App móvil → GA4 → BigQuery · origen → Modelo de cliente → Looker → Análisis de resultados.

Web: La web publica eventos permitidos con identificadores acordados entre colección, warehouse y destinos. App móvil: La app usa la misma taxonomía. La identidad de login se propaga solo cuando es válida y está autorizada. Pedidos y backend: Los eventos operativos permiten reaccionar a compras y devoluciones con menos dependencia de la medición del navegador. CRM y soporte: El CRM conserva su función operativa; sus registros se replican al warehouse bajo un contrato de actualización. Tealium EventStream: EventStream enruta eventos a conectores de engagement y a BigQuery. Son rutas configuradas con controles propios. Fivetran: Un conector compatible replica registros. La frecuencia y el tratamiento de borrados dependen del conector y su configuración. BigQuery: BigQuery reúne eventos y registros. Las respuestas de campaña necesitan también una integración de retorno. dbt · modelo cliente: Los modelos SQL calculan atributos y audiencias. La resolución de identidad y la propagación de bajas se diseñan explícitamente. Conector Braze: El conector envía eventos admitidos por Braze con el identificador de usuario correcto. No sustituye al modelo histórico. Braze: Braze recibe eventos y atributos sincronizados. Canvas decide según su configuración; las rutas rápidas y periódicas pueden llegar en distinto orden. Hightouch: Hightouch sincroniza modelos con los destinos configurados. Claves, operaciones de borrado y mapeos son parte del contrato. Looker: La capa analítica usa los modelos gobernados. La definición de conversión debe coincidir con la del negocio. Email, push y SMS: Braze ejecuta los canales configurados, con preferencias y límites de contacto. Los resultados vuelven por una ingesta aparte. Google y Meta Ads: Se sincronizan listas y exclusiones cuando el destino las admite. Matching, permisos y plazos se comprueban en cada plataforma. Análisis de resultados: El equipo compara la población calculada, la enviada y la aceptada. Cada número describe una etapa distinta. Evento a mensaje: Pedidos y backend → Tealium EventStream → Conector Braze → Braze → Email, push y SMS. Histórico a audiencia: CRM y soporte → Fivetran → BigQuery → dbt · modelo cliente → Hightouch → Google y Meta Ads. Enriquecer engagement: CRM y soporte → Fivetran → BigQuery → dbt · modelo cliente → Hightouch → Braze → Email, push y SMS. Medición y aprendizaje: Web → Tealium EventStream → BigQuery → dbt · modelo cliente → Looker → Análisis de resultados.