Data 360 Segmentación y Activación: Style Guide | Cleon

Esta es la página donde Cleon deja de describir qué es la activación de Data 360 (antes Data Cloud) y empieza a decir qué hacemos con ella. Salesforce define las superficies. Las páginas de referencia de esta subcategoría documentan cada una — construir el segmento, el activation target, batch versus tiempo real, el puente con Marketing Cloud, el consent — y los gotchas documentan dónde un segmento silenciosamente no llega a ser un resultado. Este Style Guide es la disciplina que mantiene confiable a un segmento el día que sale a un canal que recibe una persona real.

Usalo como checklist antes de que cualquier segmento o activación nuevo se publique. Las reglas son cortas a propósito — cuando una regla necesita explicación, la explicación está en la página que linkea. Una decisión está por encima de todas las demás, así que va primero.

La decisión central: batch publish vs. data action en tiempo real

Casi toda elección de activación en Data 360 se reduce a una bifurcación: ¿el destino necesita una población — quién califica ahora, recomputada en una cadencia — o una reacción a un único cambio en el momento en que ocurre? Un segment publish programado responde la primera; una data action en tiempo real responde la segunda. Acertá esto y el resto de la subcategoría es detalle. Erralo y o congelás una necesidad de evento dentro de un batch diario, o cableás un mecanismo de evento donde el trabajo era una audiencia recomputada — y en cualquier caso es un rebuild, no un setting que cambiás.

Tres preguntas lo deciden. Respondelas en orden.

1. ¿El destino necesita una población, o una reacción a un único cambio?

Separá las dos preguntas que se esconden adentro de la mayoría de los requisitos y parecen una: quién está en esta audiencia (una población — un segmento), y cuándo actúa el destino (una cadencia, o un evento — una data action). Un publish programado responde "quién, al momento de la última corrida". Una data action responde "reaccioná ahora a este único cambio". Si el destino necesita el conjunto de todos los que califican ahora, es un segment publish. Si necesita disparar a partir de un único cambio de registro en el momento en que ocurre — sin membresía, sin conteo — es una data action (batch vs. tiempo real). Nombrá cuál estás construyendo, en voz alta, antes de construirlo.

2. Si es una población — ¿qué tan fresca, y la regla entra en la ventana de Rapid?

Una población igual tiene dos tiers de cadencia, y el más rápido compra velocidad resignando alcance. Standard publish corre cada 12 a 24 horas y alcanza el horizonte de engagement completo — hasta dos años — a cualquier target. Rapid Segment Publish refresca tan seguido como por hora, pero solo sobre los últimos 7 días de engagement, solo a Marketing Cloud, con un conteo topeado y una cadencia a la que te comprometés de entrada (verificá los límites actuales de tu org). Así que la pregunta de frescura tiene una segunda mitad: ¿la regla siquiera entra en un segmento rapid? Una regla que depende de comportamiento más viejo que una semana no se puede expresar en Rapid por más fresca que la quieras. Decidí la frescura que la audiencia genuinamente necesita, chequeá que la regla entre en el tier que la entrega, y dejá la cadencia por escrito (construir segmentos).

3. ¿Es genuinamente tanto una población COMO una reacción por cambio?

Esta es la línea que los equipos pasan por alto. "Mandale un email a todos los del segmento de alto valor, y disparar un mensaje en el instante en que cualquiera de ellos abandona un carrito" no es un mecanismo con un setting ingenioso — es un segment publish para la población y una data action para la reacción por cambio, dos builds cableados por separado, cada uno haciendo el trabajo para el que tiene forma. Si el requisito es genuinamente ambos, construí ambos. Estirar uno para cubrir ambos es el rebuild.

Este es el paralelo exacto con la decisión Calculated Insight vs. Query en vivo de la capa de query, una capa más arriba — computar una población en una cadencia, o reaccionar a un cambio en vivo — y con la misma disciplina de frescura: seteá la cadencia de publish a la decisión más fresca que la audiencia alimenta, nunca a "lo más fresca posible".

Disciplina de target

Diseñá el activation target tan deliberadamente como el segmento

Un segmento perfecto activado al lugar equivocado es apenas un query caro (principio 8). El target merece la misma deliberación que las reglas de membresía; normalmente recibe una fracción de ella (activation targets). El segmento es reutilizable, el target es reutilizable, y la activación es el cableado específico de uno al otro — mantené los tres distintos en tu cabeza, y el destino deja de recibir un default.

Conocé el contrato del destino — identificador, canal, atributos — antes de que el segmento esté "listo"

Cada tipo de target declara el identificador sobre el que keyea, el canal que maneja, y los atributos sobre los que actúa, y ese contrato trabaja hacia atrás dentro del segmento (activation targets). Una plataforma de ads que matchea sobre hashed email necesita que el segmento cargue un email; un Journey que hace split sobre un loyalty tier necesita el tier mandado como atributo. Leé el contrato primero, después construí el segmento para satisfacerlo — no al revés, que es cómo descubrís que la audiencia no puede proveer el identificador que el canal necesita después de que ya está construida.

Mapeá solo los atributos que el destino de verdad usa — y cada uno carga la frescura de su origen

Los atributos que viajan junto son los únicos sobre los que el destino puede actuar; no hay "y además traé esto" una vez que la activación se mandó (activation targets). Mapeá lo que el canal personaliza o sobre lo que decide, y nada más — el payload no es gratis, y hay topes de atributos relacionados. Y cada atributo llega cargando la frescura de lo que sea que lo produjo: un Calculated Insight refrescado a diario, viajando dentro de una activación por hora, aterriza un valor de hasta un día en una columna que el destino trata como actual. La activación transporta un valor, no lo revalida.

Disciplina de costo y frescura

Filtrá selectivamente — el costo escala con lo que las reglas escanean, no con lo que devuelven

El costo en Data 360 escala con lo que procesás, no con lo que almacenás (principio 11), y el procesamiento de un segmento es lo que sea que sus reglas escanean en cada publish. Un filtro líder ajustado que elimina la mayor parte del perfil temprano es barato; un scan del perfil entero debajo de una pila de ANDs es una factura recurrente disfrazada de decisión de lógica (construir segmentos). El tamaño del resultado y el costo de producirlo son números distintos — filtrá sobre la condición más selectiva primero, apoyate en Calculated Insights ya computados en lugar de forzar recomputación, y no escanees dos años de historia para una audiencia que depende de los últimos noventa días.

Seteá la cadencia de publish a la decisión más fresca que la audiencia alimenta — y dejala por escrito

La membresía de un segmento es un snapshot, no una vista en vivo: entre publishes sirve el último conjunto que resolvió, con nada en el destino que diga que el mundo se movió (principio 6). Seteá la cadencia a la decisión más fresca que la audiencia genuinamente alimenta — no a "lo más fresca posible", que paga por frescura que nadie consume, y no a un publish diario detrás de una decisión en tiempo real. Un scan que corre por hora cuesta aproximadamente doce veces uno que corre dos veces al día, para las mismas reglas. Después dejá la cadencia por escrito al lado del segmento, para que el próximo no asuma que la lista está actual cuando está en un reloj de 24 horas.

El consent no es negociable

Aplicá el consent en el boundary de activación, nunca como un filtro que alguien se acuerda de poner

La lógica de segmento es ciega al consent por diseño — cuenta quién matchea, y nada en la regla sabe si una persona se dio de baja (principio 9). Así que el consent se aplica debajo del segmento, en el boundary donde la membresía se vuelve una activación, vía Contact Point Filtering respaldado por el Contact Point Consent DMO (consentimiento y activación). Podés meter un filtro "opt-in = true" dentro de la lógica de un segmento, y eso es justo la trampa: protege ese único segmento hasta que el próximo se lo olvida. Modelá el consent y el data-use purpose junto a la data, aplicá el filtro como convención permanente en cada activación a un canal que carga consent, y volvé el camino seguro el único camino — una activación a email que no se puede construir para ignorar el consent de email.

Filtrá sobre consent status Y data-use purpose — no status solo

El consent status (opted in u out para el contact point) es el atributo que la gente agarra primero; el data-use purpose (marketing, analytics, un propósito de procesamiento específico) es el que vuelve correcta la aplicación (consentimiento y activación). El consent real es permiso-para-un-propósito: la persona que permitió email transaccional pero rechazó marketing está opted in y tiene que quedar excluida de una activación de marketing. Filtrar solo sobre status trata al consent como un único switch on/off y manda a esa persona igual. Ambos atributos viven en el Contact Point Consent DMO, y ambos van en el filtro — la falla acá es la que llega a un regulador, y es silenciosa todo el camino.

Patrones a preferir

Un segment publish para cualquier requisito que necesita una población, una data action para cualquiera que necesita una reacción por cambio — y ambos cuando es genuinamente ambos.
Standard publish por default; Rapid solo cuando la regla entra en su ventana de 7 días y el destino es Marketing Cloud.
El contrato del destino leído primero — identificador, canal, atributos — y el segmento construido para satisfacerlo.
Solo los atributos sobre los que el destino actúa cargados junto, cada uno con la frescura de su origen conocida.
El filtro más selectivo primero, para que Data 360 deje de escanear temprano.
Contact Point Filtering en cada activación que carga consent, sobre status y purpose, como forma default — no un agregado por segmento.
La cadencia de publish escrita al lado del segmento, no guardada en la memoria de alguien.

Patrones a rechazar

Un segmento publicado a diario detrás de un requisito de "en el momento en que hacen X" — una reacción que llega hasta un día tarde.
Una data action donde el trabajo era una audiencia recomputada — un stream de eventos por cambio y ninguna población a la que mandarle una campaña.
Rapid agarrado porque por hora suena mejor antes de chequear que la regla entra en una ventana de 7 días y el target es Marketing Cloud.
Un segmento perfecto mandado al target equivocado — la gente correcta, el lugar equivocado, compute real gastado en ningún resultado.
Un atributo que el destino no usa rellenando el payload, o un valor obsoleto cargado como si fuera actual.
Consent como un filtro que alguien se acuerda de poner en cada segmento, en lugar de aplicado en el boundary sobre status y purpose.
"Se publicó" tratado como "llegó". El status de publish en Data 360 y la llegada al destino son dos hechos distintos (debuggear activación).

El checklist de pre-ship antes de que cualquier segmento o activación se publique

[ ] La decisión batch-vs-tiempo-real se tomó a propósito — segment publish para una población, data action para una reacción por cambio, ambos si es genuinamente ambos.
[ ] Población: Standard vs. Rapid elegido por la regla (¿entra en la ventana de 7 días + Marketing Cloud?), no por la aspiración de ser más fresco.
[ ] La cadencia de publish está seteada a la decisión más fresca que la audiencia alimenta, y escrita al lado del segmento.
[ ] El contrato del destino se leyó primero — identificador, canal, atributos — y el segmento carga lo que el canal keyea y sobre lo que hace split.
[ ] Solo los atributos sobre los que el destino actúa están mapeados, y la frescura de cada atributo está conocida y es aceptable.
[ ] Las reglas filtran selectivamente — la condición más selectiva lidera, y nada fuerza un scan del perfil entero que la audiencia no necesita.
[ ] El consent está aplicado en el boundary vía Contact Point Filtering sobre status y data-use purpose — no un filtro adentro del segmento.
[ ] La llegada está verificada en el destino, no solo el status de publish en Data 360.

Cuando todas tildan, el segmento o la activación está listo para publicar.

Relacionado

Gotchas de Segmentación y Activación — dónde un segmento no llega a ser un resultado, la versión de producción
Construir segmentos — las reglas de membresía, el grain, y la cadencia de publish que un segmento hereda
Activation targets — dónde aterriza un segmento y el contrato que el destino impone
Batch vs. tiempo real en activación — la decisión publish-programado-versus-data-action en profundidad
Activar en Marketing Cloud — el puente del segmento de Data 360 al Journey de MC
Consentimiento y activación — Contact Point Filtering y el Contact Point Consent DMO en el boundary
Debuggear activación — cuando un segmento publica pero la audiencia no llega
Principios de Data 360 desde producción — las meta-reglas por encima de estos específicos (6, 8, 9, 11)

Si encontrás una regla que falta — o una de estas reglas violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.