Skip to main content

Batch vs. tiempo real en activación: segment publish programado o una data action en tiempo real

La decisión sobre la que gira toda la subcategoría: un segment publish programado recomputa una audiencia entera en una cadencia y la manda a un activation target; una data action en tiempo real dispara a partir de un único cambio de data en el momento. Una responde 'quién, al momento de la última corrida'; la otra responde 'reaccioná ahora a este único cambio'. Los dos mecanismos, sus límites reales, y cómo saber cuál necesita de verdad un requisito — el paralelo exacto con la decisión Calculated-Insight-versus-Query-en-vivo de la capa de query.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Esta es la página sobre la que gira la subcategoría de Segmentación y Activación. Cada otra página de acá — construir el segmento, elegir el target, el puente con Marketing Cloud, el consent — asume que ya sabés cómo sale la audiencia de Data 360 (antes Data Cloud). Hay dos mecanismos, no son intercambiables, y agarrar el equivocado es un rebuild, no un setting que cambiás. Así que antes de esas decisiones, esta: un segment publish programado o una data action en tiempo real.

La forma de la decisión es idéntica a la decisión central de la capa de query (Calculated Insight versus Query en vivo). Ahí, la bifurcación es computar una vez y dejar que todos retrieven versus correrla en vivo cada vez. Acá es recomputar una población entera en una cadencia versus reaccionar a un cambio en el momento. El mismo instinto abajo, la misma falla cuando adivinás: o congelás una necesidad de evento dentro de un batch diario, o cableás un mecanismo de evento donde el trabajo era en realidad una población.

Los dos mecanismos, lado a lado

Un segment publish y una data action responden preguntas distintas. Decilas en una línea cada una y la mayor parte de la confusión se disuelve:

Segment publish programado → "quién está en esta audiencia, al momento de la última corrida"  (una población, en una cadencia)
Data action en tiempo real → "reaccioná ahora a este único cambio"                            (un evento, en el momento)

Un segment publish programado recomputa la membresía entera del segmento en una cadencia y empuja el resultado a un activation target — Marketing Cloud, una plataforma de ads, un archivo en un bucket. Es la audiencia completa: cada filtro, cada container, cada Calculated Insight que el segmento referencia, evaluado contra el modelo y resuelto en una lista de personas. Su latencia es el intervalo de publish — la audiencia es exactamente tan fresca como la última corrida (construir segmentos cubre la mecánica de frescura).

Una data action en tiempo real es otra cosa por completo. No recomputa una audiencia. Vigila un único cambio de data — un registro creado, actualizado, borrado — y dispara un mensaje sobre ese único cambio en el momento en que se propaga. Tiene forma de evento: reacciona a una cosa, no produce una población. Salesforce la construye sobre el change data feed de la plataforma (el mecanismo de change data capture), que es por qué su timing es near-real-time, no instantáneo — más sobre eso abajo.

La trampa es que las dos pueden terminar apuntando a Marketing Cloud, así que parecen dos settings para el mismo trabajo. No lo son. Una manda una audiencia en un reloj; la otra retransmite un evento en el momento en que ocurre.

Segment publish programado: los dos tiers de cadencia

Un segment publish no es una sola velocidad. Hay dos tiers, y el más rápido compra velocidad resignando alcance.

Standard publish — la audiencia profunda y completa

Standard publish corre en un schedule en el rango de 12 a 24 horas y evalúa contra un horizonte de engagement largo: hasta dos años de historia de engagement, con un lookback default de 90 días que configurás hacia arriba desde ahí. Funciona con cualquier activation target — Marketing Cloud, plataformas de advertising, cloud storage, todo. Es el default y el que la mayoría de las audiencias quiere: expresividad completa de segmento, la historia entera, todos los destinos disponibles. El costo es latencia medida en horas — la audiencia es un snapshot de la última corrida, de hasta un día.

Rapid Segment Publish — más fresco, pero más angosto en cada eje

Rapid Segment Publish refresca mucho más seguido — en una cadencia de 1 hora o 4 horas — pero resigna alcance por esa velocidad en tres ejes a la vez:

  • Horizonte. Evalúa solo los últimos 7 días de engagement, no la historia de dos años que standard publish puede alcanzar. Una regla que depende de comportamiento más viejo que una semana no se puede expresar en un segmento rapid.
  • Destino. Está construido para Marketing Cloud Engagement como target. (Salesforce extendió el rapid publishing a algunos tipos de target adicionales con el tiempo — confirmá qué soporta la versión de tu org antes de diseñar alrededor de eso; tratá a Marketing Cloud como el caso confiable.)
  • Volumen. Hay un tope de cuántos segmentos rapid puede correr una org, y un segmento con schedule standard existente generalmente no se puede pasar a rapid después — la cadencia la elegís como propiedad del segmento, no como un dial que girás más tarde. Ambos son límites específicos de org y de versión; verificá los números actuales en tu org en vez de comprometerte con una cifra de un doc.

Cualquiera de los dos tiers, lo que se manda es lo mismo: una población recomputada. La cadencia setea la latencia. Lo que no puede hacer es reaccionar a un único cambio entre corridas — eso es el otro mecanismo.

Data action en tiempo real: un evento, no una audiencia

Una data action publica un único cambio de data a un target en el momento en que ocurre. La configurás contra un objeto y una condición — cuando un registro así cambia — y cuando el cambio se propaga por la plataforma, la data action dispara un mensaje describiéndolo. Tres tipos de target lo reciben:

  • Un platform event de Salesforce — soltado en el platform event bus, donde muy seguido lo consume un Flow disparado por platform event que hace el trabajo downstream. Es la forma común cuando la reacción vive adentro de Salesforce.
  • Un webhook — un request HTTP a un endpoint externo, cargando el cambio como payload, para que un sistema fuera de Salesforce actúe.
  • Marketing Cloud — el cambio se manda a Marketing Cloud Engagement, donde puede manejar un evento de entrada o una interacción de streaming.

La propiedad que la define: una data action reacciona a un cambio, no evalúa una audiencia entera. No hay membresía, no hay conteo de población, no hay "todos los que califican ahora". Hay un cambio, y un mensaje sobre él. Eso es justo por qué es rápida — no hay nada que recomputar — y justo por qué no puede responder "quién está en este segmento". Pregunta distinta, herramienta distinta.

"Tiempo real" es near-real-time, con límites

Una data action es rápida, pero no es instantánea y no es ilimitada. El propio framing de Salesforce es near-real-time: el cambio se propaga a través del change data feed y sale al target con latencia real, gobernada por límites y guidelines documentados — no por cero. Prometerle a un cliente "instantáneo" y diseñar como si una data action fuera un callback sincrónico es cómo se atrasa un launch cuando el comportamiento real resulta ser near-real-time con topes de throughput.

La decisión: qué pregunta estás respondiendo en realidad

Toda la decisión se reduce a una separación. Dos preguntas se esconden adentro de la mayoría de los requisitos y parecen una:

  1. Quién está en esta audiencia? — una población, evaluada contra el modelo. Eso es un segmento, y un segmento se manda vía un publish programado.
  2. Cuándo tiene que actuar el destino? — en una cadencia, o en el momento en que una cosa cambia. Una cadencia es el intervalo de publish; "en el momento en que cambia" es una data action.

Respondé las dos, en voz alta, antes de construir:

¿Necesitás una población, refrescada en un reloj?       → segment publish programado (standard, o rapid si entra en la ventana de 7 días + MC)
¿Necesitás reaccionar a un único cambio en el momento?  → data action en tiempo real (platform event, webhook, o Marketing Cloud)
¿Necesitás una población Y una reacción inmediata por cambio? → AMBOS — dos mecanismos, no uno estirado para cubrir ambos

Esa última línea es la que los equipos pasan por alto. "Mandale un email a todos los del segmento de alto valor, y además 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. Nombrar cuál (o ambos) necesita un requisito es el paso más barato de toda la subcategoría, y saltearlo es el más caro.

Los errores simétricos son predecibles. Agarrar un segmento publicado a diario para satisfacer un requisito de "en el momento en que hacen X" te da una reacción que llega hasta un día tarde. Cablear una data action donde necesitabas una audiencia recomputada te da un stream de eventos por cambio y ninguna población a la que mandarle una campaña. Los dos compilan. Los dos se ven plausibles en una demo. Los dos son un rebuild una vez que el requisito es real.

El paralelo con la capa de query, dicho sin vueltas

Esta es deliberadamente la misma bifurcación que Calculated Insight versus Query en vivo, una capa más arriba. Ahí, computás una métrica una vez y dejás que cada consumidor la retrieve, o la corrés en vivo cada vez que se pide — y la frescura es "tan fresca como la decisión más fresca que alimenta", nunca "tan fresca como sea posible". Acá, recomputás una audiencia entera en una cadencia, o reaccionás a un cambio en el momento — y aplica la misma disciplina de frescura: seteá la cadencia de publish a la decisión más fresca que la audiencia alimenta, y no agarres la inmediatez de una data action donde una población diaria era el trabajo real.

El test honesto, en una línea: si el requisito es "quién califica ahora", es un segment publish; si es "reaccioná a este único cambio ahora", es una data action — y si es genuinamente ambos, construí ambos. La mayoría de los debates de "¿esto debería ser batch o tiempo real?" se disuelven en el momento en que decís en voz alta si el destino necesita una población o una reacción por cambio.

Relacionado

Reference: