Skip to main content

Debuggear activación — cómo hacerlo en Data 360

La audiencia no llegó, llegó mal, llegó vieja, o incluyó a alguien que no debía. El diagnóstico tiene siempre la misma forma — elegí la capa a la que apunta el síntoma, después bajá desde membership hasta arrival y encontrá la primera que está rota. El playbook de debugging de segmentación y activación.

Cómo hacerlo·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Lanzaste una campaña y la audiencia está mal. Capaz no llegó nadie. Capaz llegó la gente equivocada. Capaz llegó la gente correcta cargando la data de ayer, o alguien que hizo opt-out recibió un mensaje que rechazó. El segmento se veía bien en el canvas, la activación reportó éxito, y nada tiró error para decirte dónde se rompió — porque las peores fallas en activación son las silenciosas, igual que los bugs de mapping y query. Así que el diagnóstico tiene siempre la misma forma: averiguá a qué capa apunta el síntoma, después bajá desde membership hasta arrival, y la primera capa que está rota es la dueña del bug.

Las capas

[ MEMBERSHIP — ¿la persona está en el segmento siquiera? ]
        ↓
[ FRESHNESS — ¿la membership es un snapshot viejo? ]
        ↓
[ MECANISMO — publish programado o data action, ¿está cableado el correcto? ]
        ↓
[ TARGET / MAPPING — ¿destino correcto, y el atributo viajó? ]
        ↓
[ CONSENT — ¿se coló un opt-out, o sobre-filtraste de más? ]
        ↓
[ ARRIVAL — "se publicó" no es "llegó": verificá en el destino ]

A diferencia de un número equivocado, donde siempre empezás por el modelo, un síntoma de activación normalmente apunta a una capa. "Alguien recibió un mensaje del que hizo opt-out" es la capa de consent; "la audiencia está un día vieja" es freshness; "no llegó nadie" te manda a mecanismo o arrival. Empezá donde apunta el síntoma, pero bajá desde ahí — cada capa asume que las de arriba están sanas, así que confirmá la membership antes de culpar al target, y confirmá el target antes de culpar al arrival. La tabla de síntomas a capas del final es el índice; el recorrido de abajo es el diagnóstico.

Capa 1 — Membership: ¿la persona está en el segmento siquiera?

Antes de nada sobre adónde fue la audiencia, confirmá quién está en ella. Si el reclamo es "esta persona tendría que haber recibido la campaña y no", la primera pregunta es si alguna vez estuvo en la membership del segmento — porque un filtro puede excluir a alguien en silencio, sin error y sin warning.

  • El chequeo — leé la membership del segmento para la persona que esperabas y la que no. ¿Están? Si la persona que tendría que haber llegado ni siquiera es miembro, la activación es inocente — la audiencia ya estaba mal antes de salir.
  • El síntoma — la audiencia es silenciosamente más chica o de forma distinta a lo que pidió el negocio. Las dos causas habituales: un filtro sobre un atributo que está null para una porción de la gente los descarta sin decir nada (tier = 'Gold' excluye a todos los que nunca tuvieron tier seteado, no solo a los que no son Gold), o el segmento se construyó sobre el objeto equivocado y está contando registros donde querías personas, o al revés. (Ver gotchas de segmentación y activación, gotchas 8 y 9.)
  • El arreglo — para el caso del null, decidí explícitamente qué tiene que hacer cada filtro con las filas donde el atributo está vacío, y escribí la regla para que no se caigan por accidente. Para el caso del objeto equivocado, confirmá que el objeto del Segment On sea el unified individual cuando querías personas. Los dos arreglos están en la definición del segmento, no en la activación. (Ver construir segmentos.)

Si la gente correcta está en la membership y la equivocada no, la población del segmento está bien. El bug está más abajo. Bajá.

Capa 2 — Freshness: ¿la membership es un snapshot viejo?

Si la persona está en el segmento ahora pero no estaba cuando corrió la campaña — o calificó después del último publish — la membership que activaste era un snapshot, no una vista en vivo. La membership de un segmento publicado se materializa cuando se publica y después queda ahí hasta el próximo run; entre publishes es quién calificó entonces, no quién califica ahora.

  • El chequeo — ¿cuándo publicó por última vez este segmento, y cuál es su cadencia? Compará el timestamp del último publish contra cuándo calificó la persona. Alguien que cumplió el criterio esta mañana no está en un segmento que publicó por última vez anoche, y la membership se ve completa todo el tiempo.
  • El síntoma — falta la persona correcta, o está la equivocada, y la diferencia es timing: calificó (o dejó de calificar) después del último publish. El segmento no está mal, está tarde.
  • El arreglo — emparejá la cadencia de publish con qué tan fresca necesita ser realmente la audiencia en el momento en que activa. Standard publish corre en un schedule de 12 a 24 horas; Rapid Segment Publish refresca tan seguido como cada hora pero cambia horizonte y destino por esa velocidad — elegí el tier que la decisión realmente necesita, y no subas la cadencia más allá de lo que consume, porque el costo escala con cada refresh. (Ver construir segmentos sobre Standard vs. Rapid.)

Si la membership está lo bastante fresca para la decisión, la población es correcta y actual. El bug está en cómo salió. Bajá.

Capa 3 — Mecanismo: ¿publish programado o data action, y está cableado el correcto?

Si la audiencia es correcta y actual pero el timing de la entrega está mal — una reacción que llega horas tarde, o un chorro de eventos sueltos donde esperabas una audiencia entera — sospechá que está cableado el mecanismo equivocado. Hay dos, responden preguntas distintas, y agarrar el equivocado es un rebuild, no un setting.

  • El chequeo — ¿qué estaba pidiendo realmente este trabajo: una población refrescada en un reloj, o una reacción a un cambio a medida que pasa? Después leé qué está cableado. Un scheduled segment publish envía una audiencia recomputada en una cadencia; un real-time data action dispara un solo cambio de data a medida que se propaga. ¿El mecanismo cableado coincide con la pregunta?
  • El síntoma — dos fallas simétricas. Un requerimiento de "en el momento en que hacen X" servido por un segmento de publish diario entrega una reacción hasta un día tarde. Un requerimiento de población cableado como data action entrega un chorro de eventos por cambio y ninguna audiencia a la que mandarle una campaña. Los dos se ven plausibles; solo el requerimiento te dice cuál está mal.
  • El arreglo — cableá el mecanismo que el requerimiento realmente necesita. Si genuinamente necesita los dos — una población y una reacción inmediata por cambio — son dos mecanismos construidos por separado, no uno estirado para cubrir ambos. (Ver activación batch vs. real-time.)

Si el mecanismo correcto está cableado y disparando, la audiencia está saliendo de Data 360 (antes Data Cloud) como debe. El bug está en adónde va o qué carga. Bajá.

Capa 4 — Target y mapping: ¿destino correcto, y el atributo viajó?

Si la audiencia es correcta, actual y sale por el mecanismo correcto pero el destino igual no puede actuar sobre ella, el problema es el activation target o los atributos mapeados hacia él. Un segmento perfecto mandado al lugar equivocado, o mandado sin el campo que el destino necesita, es esfuerzo que produjo una población y ningún resultado.

  • El chequeo — dos preguntas distintas. Primero, ¿el activation target es ese en el que la campaña realmente corre — el canal correcto, la business unit correcta, el objeto destino correcto? Segundo, ¿cada atributo sobre el que el destino decide viajó en la activación? Una activación carga solo los atributos que mapeaste; un campo que el destino lee pero la activación nunca mandó simplemente no está ahí.
  • El síntoma — para el target equivocado: la audiencia aterriza en un lado donde nadie actúa sobre ella, y la campaña "corrió" contra un canal vacío. Para el atributo faltante: el destino no puede ramificar ni personalizar — un Journey que hace split por tier no puede splitear si tier nunca viajó, por bueno que fuera el segmento. No hay error; la columna simplemente no está en el Data Extension.
  • El arreglo — apuntá la activación al target en el que la campaña corre, y mapeá cada atributo que la lógica del destino necesita antes de dar por terminado el segmento. Una vez que la activación escribió, no existe el "y también traé este campo" — el destino solo puede actuar sobre lo que viajó. (Ver activation targets.)

Si el target está bien y cada atributo necesario llegó, la audiencia está aterrizando donde debe con lo que necesita. Las fallas que quedan son consent y arrival. Bajá.

Capa 5 — Consent: ¿se coló el opt-out, o sobre-filtraste?

Si la audiencia llegó pero llegó el conjunto equivocado de gente por una razón de consent — alguien que hizo opt-out fue alcanzado, o se excluyó a demasiada gente — el bug está en el borde de consent. Esta capa falla en las dos direcciones, y se ven opuestas pero comparten causa: consent aplicado en el lugar equivocado o sobre el atributo equivocado.

  • El chequeo — ¿está configurado Contact Point Filtering en esta activación, y qué exactamente filtra? Leé el filtro, no solo si existe uno. Sub-filtrado: no hay Contact Point Filtering en absoluto, así que la membership consent-ciega del segmento sale intacta, opt-outs incluidos. Sobre-filtrado: el filtro evalúa consent status solo sin el data-use purpose, así que excluye gente que está válidamente opted in para el propósito por el que estás mandando.
  • El síntoma — el sub-filtrado termina en el inbox de un regulador: una persona con opt-out alcanzada, status verde todo el camino, porque Data 360 hizo exactamente lo que pidió el segmento consent-ciego. El sobre-filtrado es el desperdicio más callado: una audiencia mucho más chica de lo esperado, porque filtrar por status sin purpose trató un opt-out transaccional como uno general y descartó gente que nunca rechazó este canal.
  • El arreglo — aplicá consent en el borde de la activación con Contact Point Filtering, y filtrá por ambos consent status y data-use purpose, porque el consent real es permiso-para-un-propósito, no un solo switch on/off. Hacelo una convención permanente en cada activación hacia un canal con consent, no un agregado por segmento — así un builder no puede enviar la versión insegura. (Ver consent y activación.)

Si el consent está aplicado correctamente — sin dejar pasar un opt-out ni sobre-excluir — la gente correcta está saliendo de Data 360. La última pregunta es si realmente llegó. Bajá.

Capa 6 — Arrival: "se publicó" no es "llegó"

La última capa es la que es más probable saltearse, porque el lado de Data 360 se ve sano. Un segmento puede publicar, una activación puede correr, el status puede leer éxito — y la audiencia igual puede llegar tarde, parcial, o no llegar al destino, porque la falla pasó en el handoff, que es un hecho distinto del éxito en Data 360.

  • El chequeo — verificá en el destino, no en el publish status de Data 360. Abrí el Data Extension de Marketing Cloud y contá las filas, o chequeá la propia recepción de la plataforma externa — ¿la audiencia está realmente ahí, al tamaño y la frescura que esperás? Dos status ayudan del lado de Data 360: Segment Status (active, processing, recounting, error, inactive) y Publish Status (succeeded, failed, skipped, deferred, in progress) — un publish skipped o deferred quiere decir que no corrió este ciclo por capacidad, lo cual no se parece en nada a un error pero significa que la audiencia no refrescó.
  • El síntoma — el canvas del segmento se ve perfecto y la audiencia downstream está vieja, parcial o ausente. Una activación diaria que dejó de refrescar en silencio hace tres días es idéntica, desde el canvas, a una que corre perfecto — el único lugar donde el gap es visible es el destino. (Ver gotchas de segmentación y activación, gotcha 10.)
  • El arreglo — hacé que la verificación en el destino sea parte del lanzamiento, no un agregado, y vigilá la cadencia de activación como vigilarías un job de producción. Para el bridge a Marketing Cloud en particular, acordate de que el handoff es un Data Extension compartido que el Journey lee, gobernado por dos relojes independientes — el de la activación y el del Journey — así que confirmá los dos, no solo que el publish dio verde. (Ver activar hacia Marketing Cloud.)

Un diagnóstico que podés correr

Cuando el reclamo es "la audiencia es más chica de lo que debería" y todavía no sabés qué capa, el triage más rápido es comparar tres conteos y encontrar dónde cae el número. Sin más herramienta que leer cada superficie:

  1. Conteo de membership del segmento — cuánta gente resolvió el segmento en su último publish. Si esto ya está corto de lo que esperaba el negocio, el bug es Capa 1 (un filtro excluyendo gente) o Capa 2 (un publish viejo que es anterior a cuándo calificaron). Nunca llegás a la activación.
  2. Conteo de activación — cuántos de esos miembros la activación realmente envió. Si esto está marcadamente por debajo del conteo de membership, la caída es Capa 5 (Contact Point Filtering excluyendo gente — correctamente para opt-outs, o de más si está filtrando por status sin purpose) o Capa 4 (un mismatch de target o contact point descartando filas que no se pueden enviar).
  3. Conteo de filas en el destino — cuántas aterrizaron en el Data Extension de Marketing Cloud o la plataforma externa. Si esto está por debajo del conteo de activación, la caída es Capa 6 — el handoff perdió filas, o el último refresh fue skipped, deferred, o se frenó en silencio.

La capa dueña del bug es el primer lugar donde el número cae. Una membership de 50.000 que se vuelve una activación de 50.000 que se vuelve un Data Extension de 12.000 es una falla de arrival, no del segmento — y acabás de localizarla sin tocar la definición del segmento en absoluto.

Síntomas comunes mapeados a capas

| Síntoma | Capa probable | Dónde mirar | |---|---|---| | Una persona que debería estar en la audiencia falta | Membership | Manejo de null en un filtro; el objeto del Segment On | | La audiencia no reconcilia con el conteo de un sistema origen | Membership | Unified individuals vs. filas origen (correcto por diseño) | | Audiencia correcta, pero está un día vieja | Freshness | Timestamp del último publish vs. cadencia de publish | | Reacción horas tarde, o eventos sueltos donde querías una población | Mecanismo | Scheduled publish vs. data action — cuál está cableado | | La audiencia aterrizó donde nadie actúa sobre ella | Target | Activation target: canal, BU, objeto destino correctos | | El destino no puede ramificar ni personalizar | Mapping | El atributo que el destino lee nunca viajó | | Una persona con opt-out fue alcanzada | Consent | Contact Point Filtering ausente o apagado | | Mucha menos gente de la esperada, sin error | Consent | Filtrar por status sin data-use purpose | | El canvas se ve perfecto, el destino está viejo o vacío | Arrival | Contar en el destino; ¿Publish Status = skipped/deferred? |

Relacionado

Reference: