Activar hacia Marketing Cloud: el puente que conecta las dos plataformas que la mayoría de los clientes ya corre | Cleon

Dos plataformas, un cliente. Data 360 (antes Data Cloud) tiene el perfil unificado y resuelve quién califica; Marketing Cloud Engagement corre los envíos y los Journeys que efectivamente llegan a la persona. Para la mayoría de los clientes de Cleon esas son las dos plataformas que ya están en producción, y la pregunta que decide si trabajan juntas es angosta: cómo una audiencia computada en una se vuelve una decisión sobre la que se actúa en la otra. Esta página es ese puente — un segmento de Data 360 activándose hacia Marketing Cloud Engagement, de punta a punta, con las costuras nombradas.

El puente es real y muy transitado, que es exactamente por qué se lo trata como un pipe y no lo es. El principio 8 lo nombra como la conexión que la mayoría de los clientes corre (principios de Data 360), y la versión profunda de "Marketing Cloud Engagement es un activation target más" vive en la página del target (activation targets). Acá el tema es el handoff mismo: qué se mueve físicamente entre las plataformas, qué gobierna su timing, y dónde un lanzamiento se desincroniza en silencio.

No hay un pipe de segmento a Journey — el handoff es una Data Extension

Lo primero que hay que desaprender: un segmento de Data 360 no fluye adentro de un Journey. Nada en Marketing Cloud se suscribe a un segmento directamente. Lo que pasa de verdad está corrido un paso, y todo el puente depende de verlo con claridad.

Cuando activás un segmento hacia un target de Marketing Cloud Engagement, Data 360 crea y popula una Data Extension compartida y sendable en la business unit de destino — una Data Extension de MC normal, marcada sendable, que el tooling de email y mobile y Journey Builder pueden usar como cualquier otra. En la primera activación Salesforce crea automáticamente una carpeta Data 360 Segments dentro de las Shared Data Extensions de la business unit, y la DE de la activación aterriza ahí. El Journey después lee esa Data Extension — apuntás el Data Extension entry source de un Journey hacia ella, igual que cualquier Journey manejado por una DE.

Data 360                                  Marketing Cloud Engagement
─────────────                               ──────────────────────────
Segmento ──activa──▶  Data Extension compartida y sendable
(membership +         (Shared Data Extensions ▸ carpeta Data 360 Segments)
 atributos)                          │
                                     └──leída por──▶  Journey  ──▶  envíos

Así que el handoff es la Data Extension. El segmento le escribe; el Journey la lee; nunca se tocan entre sí. Esa indirección no es un detalle — es la fuente de cada costura de abajo, porque una escritura y una lectura sobre la misma tabla son dos eventos independientes con dos relojes independientes, y la tabla no le avisa a ninguno de los dos lados cuándo corrió el otro por última vez.

Los dos relojes: una activación stale hace que un Journey decida hoy con la audiencia de ayer

Esta es la costura que más importa, y se desprende directo de que el handoff es una DE y no un pipe. Dos schedules gobiernan el puente, y se setean de forma independiente uno del otro:

La cadencia de activación — cada cuánto el segmento publica y refresca las filas en la Data Extension compartida. El segmento es energía potencial hasta que se activa (armar segmentos); este reloj decide cada cuánto esa activación efectivamente dispara.
El schedule de entry/run del Journey — cuándo el Journey evalúa la Data Extension, admite contactos y actúa.

Un Journey actúa sobre lo que sea que estuvo en la Data Extension al momento del último refresh de la activación — no al momento de ahora. Si la activación refrescó esta mañana y el Journey corre todo el día, cada contacto que el Journey admite después de ese refresh se decide sobre un snapshot que ya está envejeciendo. La membership dejó de ser live en el instante en que la activación terminó de escribir; el Journey no tiene forma de saberlo, y ningún asterisco aparece en el envío.

La trampa es que las dos mitades se ven sanas por separado. La activación reporta éxito; el Journey corre sin error; solo la combinación está stale, y ninguna consola muestra la combinación. Una activación diaria que dejó de refrescar en silencio hace tres días alimenta a un Journey que corre perfecto con decisiones de hace tres días, y el primer síntoma es alguien río abajo preguntando por qué la audiencia se ve mal — cubierto como modo de falla en debugging de activación y en el gotcha 6 de los gotchas de segmentación.

La activación keyea sobre un contact point

Un envío necesita una dirección. La activación de Marketing Cloud Engagement se keyea sobre un contact point — un email o un número de mobile, elegido para coincidir con el canal en el que corre el Journey — porque ese es el identificador al que MC efectivamente envía. El contact point es lo que hace a la Data Extension sendable: es la columna sobre la que el envío resuelve al destinatario.

Esa elección tiene que coincidir con el canal, y vuelve hacia atrás hasta el segmento. Un Journey de email necesita que el segmento cargue un contact point de email; un Journey de SMS necesita uno de mobile. Si la audiencia que armaste resuelve personas que tienen un mobile pero no un email, una activación de email de ese segmento entrega una DE sendable llena de filas que no se pueden enviar — el contact point que el canal necesita es el que el segmento no pudo proveer. El contrato del destino vuelve hacia atrás hasta el segmento, que es todo el argumento de activation targets: conocé el identificador sobre el que keyea el canal antes de decidir que el segmento está terminado.

Los atributos viajan — y cada uno carga su propia frescura

Un Journey rara vez solo envía; hace splits y personaliza. Para eso necesita más que el contact point — necesita los atributos de los que dependen la decisión y el mensaje. Esos viajan en la activación: los atributos adicionales que mapeás viajan hacia la Data Extension compartida como columnas, y el Journey ramifica e interpola sobre ellos exactamente como lo haría con cualquier campo de una DE.

Acá es donde los valores de un Calculated Insight cruzan el puente. Un tier, un engagement score, un valor predicho computado una vez en Data 360 viaja hacia la DE como una columna sobre la que el Journey puede hacer split (consumir resultados de query) — y la activación transporta ese valor, no lo revalida. Cada atributo llega cargando la frescura de lo que sea que lo produjo: un CI refrescado a diario, viajando hacia una activación horaria, aterriza un valor de hasta un día de antigüedad en una columna que el Journey trata como actual. El Journey ramifica sobre él con total confianza, viéndose tan autoritativo como se vería sobre un valor que fue verdadero hace un minuto.

Dos consecuencias que vale la pena sostener antes de mapear el payload:

Mapeá lo que el Journey efectivamente usa. Una vez que la activación escribió la DE, no hay "y también traé este campo" — el Journey solo puede ramificar sobre columnas que viajaron. Un segmento activado sin el tier sobre el que el Journey hace split es un Journey que no puede ramificar, no importa qué tan bueno fuera el segmento (activation targets).
La frescura de cada atributo es la de la fuente, no la de la activación. La activación no vuelve fresco un valor stale por cargarlo. Para cada columna sobre la que el Journey decide, la pregunta honesta es la que hace consumir resultados de query: ¿cuál es su cadencia de refresh, y es esa la frescura sobre la que el envío está por actuar como actual?

El orden de las operaciones

El puente se arma hacia atrás desde el envío, no hacia adelante desde el segmento. Las necesidades del Journey son el contrato; todo lo de río arriba existe para satisfacerlo:

Decidí qué hace el Journey — el canal en el que envía, los splits sobre los que ramifica, los campos con los que personaliza. Esto fija el contrato: el tipo de contact point, y cada atributo que la DE tiene que cargar.
Armá el segmento para satisfacer ese contrato — la audiencia correcta, cargando el contact point que coincide y cada atributo que el Journey va a leer (armar segmentos).
Configurá la activación hacia el target de Marketing Cloud Engagement — mapeá el contact point y los atributos adicionales, y seteá la cadencia de activación a la frescura que la decisión necesita (activation targets).
Apuntá el Data Extension entry source del Journey hacia la DE de la activación — en la carpeta Data 360 Segments bajo Shared Data Extensions — y seteá el schedule propio del Journey teniendo en cuenta la cadencia de activación.

Acertá ese orden y el puente es aburrido, que es el objetivo. Hacelo al revés — armar el segmento primero, y después descubrir que el Journey necesita un atributo que la activación nunca cargó, o un contact point que la audiencia no tiene — y estás rehaciendo el segmento para que encaje en un contrato que podrías haber leído primero. La costura entre las plataformas es exactamente donde "lo cableamos después" se convierte en un rebuild.

Qué no es esta página

Esto es el puente, no una receta de setup. El click a click de crear el activation target, los permisos que la conexión necesita, y la configuración de business unit son los propios docs de setup de Salesforce (linkeados abajo), y cambian más rápido de lo que esta página debería. Lo durable — y lo que a Cleon le pagaron por aprender — es la forma: que el handoff es una Data Extension y no un pipe, que dos relojes independientes lo gobiernan, que el contact point y los atributos cargados son un contrato que el segmento le debe al Journey, y que cada valor que cruza el puente conserva la frescura de donde vino. Dominá esa forma y las pantallas de setup son obvias; memorizá las pantallas sin ella y el primer incidente de Journey stale es un misterio.

Un hilo corre por debajo y nunca llega a ser opcional: una persona que se dio de baja del canal no debe poder activarse hacia la Data Extension desde la que el Journey envía. Esa enforcement le pertenece al consent modelado en Data 360, no a un filtro que alguien se acuerda de agregar — tiene su propia página (consent y activación), señalada acá porque el límite de la activación es exactamente donde muerde.

Gotchas de segmentación y activación — el gotcha 6 es este puente en su forma de trampa de producción
Activation targets — Marketing Cloud Engagement como un tipo de target más, y el contrato que impone
Batch vs. real-time activation — el mecanismo de publish que alimenta el puente: activación programada versus real-time data action
Consent y activación — por qué una persona dada de baja no debe poder activarse hacia la Data Extension sendable
Armar segmentos — definir la audiencia, y cargar el contact point sobre el que keyea el puente
Segmentation & Activation Style Guide — la disciplina que ata estas decisiones de activación
Principios de Data 360 — el puente (8), la frescura (6), la activación como donde el modelo se encuentra con el mundo
Consumir resultados de query — la vista del lado query de los valores de CI viajando hacia el Journey
Agentforce y Marketing Cloud — la vista del catálogo de MC sobre el mismo modelo de Data 360 desde el que activa el puente

Reference: