Construir un segmento: las reglas de membership antes de que active en ningún lado | Cleon

Un segmento es un set guardado de reglas de membership que resuelve a una lista de personas. Definís "clientes en España con lifetime value mayor a 5.000 que no compraron en 90 días", y Data 360 (antes Data Cloud) lo evalúa contra el unified profile y te devuelve los individuos que califican. Esa lista es la membership del segmento, y producirla correctamente es el trabajo entero de esta página.

Todo lo demás que hace un segmento pasa después de esto. Un segmento construido es energía potencial — no hace nada hasta que activa en algún lado donde hace trabajo (principios de Data 360, principio 8). Esta página es el frente de ese funnel: cómo se define la membership. Dónde va (el activation target), cada cuánto se manda ahí (batch publish vs. data action en tiempo real) y qué permite el consent — esas son las páginas hermanas a las que esta enlaza hacia adelante. Acá el tema es angosto y carga peso: las reglas que deciden quién está adentro.

Sobre qué segmentás: el objeto en el que se cuenta la membership

Un segmento se construye sobre un objeto — Salesforce lo llama la elección Segment On — y ese objeto decide qué es cada miembro de la lista resultante. Segmentás sobre el unified individual y cada miembro es una persona resuelta; segmentás sobre un DMO distinto y estás construyendo una lista de ese objeto en cambio. Para las audiencias que construye Cleon, la respuesta es casi siempre el unified individual: el segmento cuenta personas, deduplicadas por la resolución de identidad, no filas crudas del source.

Es la misma distinción de conteo sobre la que advierte la capa de query, vista desde el lado del segmento. El unified individual es el perfil resuelto — una fila por persona real, después de que la resolución de identidad fusionó los registros del source (principios de Data 360, principio 4). Construí el segmento sobre él y "5.000 clientes" significa cinco mil personas. Construilo sobre un objeto alineado al source por error y la misma regla cuenta registros, que es un número distinto y normalmente más grande — el tipo de desajuste que aparece como dos dashboards que no reconcilian.

El objeto sobre el que segmentás es también el ancla relativa a la que está cada filtro. Una regla sobre el objeto de segmentación es un filtro directo sobre sus propios atributos; una regla sobre cualquier otra cosa es un traversal hacia un objeto relacionado, que funciona solo donde la relación está modelada. Esa distinción son las próximas dos secciones.

Reglas de membership: containers, atributos y AND/OR

La membership se construye con filtros agrupados en containers. Un filtro es una condición sobre un atributo — Country = Spain, Lifetime Value > 5000. Un container es un grupo de filtros, y los containers son donde vive la lógica: el operador entre filtros en un container, y el operador entre containers, es AND u OR, y los containers anidan. Ese anidamiento es la superficie expresiva entera — es cómo decís "(en España OR en Portugal) AND lifetime value mayor a 5.000 AND no opted out".

Container  (AND)
├─ Country = Spain      OR      Country = Portugal     ← container interno (OR)
├─ Lifetime Value > 5000                               ← filtro (AND con el grupo de arriba)
└─ Email Opt-In = true                                 ← filtro (AND)
   la membership es cada unified individual para el que todo el árbol evalúa true

El agrupamiento no es cosmético — cambia quién califica. A AND (B OR C) y (A AND B) OR C son audiencias distintas, y el canvas de segmentación hace fácil construir ambas, lo que significa que hace fácil construir también la equivocada. La disciplina es la misma que exige un WHERE de SQL, salvo que los paréntesis son containers que arrastrás en vez de caracteres que tipeás: decidí la forma booleana de la audiencia antes de acomodar los containers, porque el anidamiento es la lógica.

Cada filtro angosta el set; nada lo ensancha salvo un OR. Un segmento con un container demasiado amplio y una pila de ANDs debajo normalmente está escaneando mucho más del perfil de lo que la audiencia final necesita — lo que es una decisión de costo, cubierta más abajo.

Filtrar sobre un Calculated Insight: recuperá el número, no lo recomputes

Algunas de las reglas de membership más útiles filtran sobre un valor que el segmento no puede computar por sí mismo — lifetime value, un engagement score, órdenes por persona. No re-derivás esos adentro del segmento. Los definís una vez como un Calculated Insight y el segmento filtra sobre el resultado pre-computado, igual que filtra sobre un campo del perfil.

Es el principio 7 — computá una vez, recuperá muchas — en el punto de consumo (consumir resultados de query). El CI aparece en el segment builder como un atributo directo: "lifetime value mayor a 5.000" es un filtro sobre la measure del CI, y el segmento lee el número que el CI ya agregó en vez de re-correr la agregación en cada refresh. Dos segmentos filtrando sobre el mismo CI coinciden por construcción, porque hay una definición de lifetime value y ambos la citan.

El costo de esa comodidad es que el segmento hereda el grain del CI y su frescura, sin forma de ver ninguno de los dos desde el canvas. Si el insight de LTV se computa por unified individual, el filtro significa personas; si se computó por accidente en un grain más fino, el mismo filtro significa silenciosamente otra cosa, y nadie que filtre sobre él lo puede notar (consumir resultados de query). Y un CI diario alimentando un segmento horario significa que la membership reacciona a un número que puede tener un día — la frescura es del CI, pero el segmento es donde muerde.

Filtrar sobre un objeto relacionado: el traversal tiene que estar modelado

Una regla sobre el objeto de segmentación es directa. Una regla sobre un objeto relacionado — "individuos cuyas órdenes este trimestre superan un umbral", donde Order es un DMO separado — es un traversal, y un traversal funciona solo donde la relación se modeló (relationships & keys). El segment builder te deja alcanzar los atributos de un objeto relacionado exactamente cuando el modelo ya conecta los dos; donde la relación no existe, el camino simplemente no se ofrece, y la regla no se puede escribir.

Es la decisión de relación de arquitectura de datos vista desde el lado de la segmentación: el segmento es donde un traversal no modelado finalmente aparece como una pregunta que no podés hacer. No hay error — el atributo simplemente no está ahí para filtrar. El arreglo está upstream, en el modelo, con todo ya dependiendo de él, que es por qué las relaciones que un segmento va a necesitar conviene modelarlas antes de construir el segmento (principios de Data 360, principio 1).

Un traversal es invisible pero siempre presente: el alcance desde un objeto de engagement alineado al source de vuelta a la persona. Un objeto source nunca se une directo al unified individual — el camino pasa por el identity link que mantiene el proceso de resolución, el bridge que ata una fila del source al perfil resuelto en el que fue fusionada. Ese join no lo escribís, y no lo podés atajar; existe porque la resolución de identidad lo construyó, y una regla que necesita conectar un engagement event a una persona unificada depende de que ese link esté en su lugar. Modelá la relación primero, y el segmento la puede traversar; salteala, y la audiencia que te pidieron no se puede expresar.

Frescura de la membership: un segmento está tan fresco como su último publish

La membership de un segmento no es en vivo. Se computa cuando el segmento se publica, y entre publishes sirve el último set de miembros que resolvió — exactamente la disciplina de frescura que gobierna los streams y los Calculated Insights (principios de Data 360, principio 6), ahora aplicada a la audiencia misma. Publicá con cadencia diaria y la membership puede tener un día de antigüedad; la persona que calificó esta mañana no está en la lista hasta la próxima corrida.

La cadencia de publish es una elección deliberada con un tradeoff real. El standard publish corre con un schedule de cada 12 horas hasta cada 24, y evalúa contra hasta dos años de historia de engagement — la audiencia profunda, histórica. El Rapid Segment Publish refresca mucho más seguido, tan frecuente como por hora, pero cambia horizonte por velocidad: mira solo una ventana reciente (los últimos siete días de engagement) en vez de los dos años completos, y apunta a Marketing Cloud específicamente. La elección entre ellos es la misma pregunta de frescura-versus-costo que plantea cada capa de Data 360 — y cómo se manda la membership una vez publicada (y la decisión batch-vs-real-time completa) es la página hermana de activación, no esta.

El encuadre honesto: decidí qué tan fresca necesita ser la audiencia, seteá la cadencia de publish para cumplirlo, y escribilo al lado del segmento — para que el próximo no asuma que la lista está actual cuando está en un reloj de 24 horas.

Tamaño y costo del segmento: pagás por lo que escanean las reglas

El costo en Data 360 escala con lo que procesás, no con lo que almacenás (principios de Data 360, principio 11), y el procesamiento de un segmento es lo que sea que sus reglas escanean en cada publish. Un segmento con un filtro líder ajustado que elimina la mayor parte del perfil temprano es barato; uno que escanea el perfil entero en cada publish para aplicar una pila de ANDs es una factura recurrente vestida de decisión de lógica.

El tamaño del resultado y el costo de producirlo son números distintos. Un segmento que resuelve a una audiencia chica puede igual ser caro si las reglas fuerzan un escaneo de perfil completo para llegar ahí. La palanca es la forma de las reglas: filtrá primero por la condición más selectiva, apoyate en Calculated Insights que ya se computaron en vez de forzar recomputación, y no escanees dos años de historia cuando la audiencia solo depende de los últimos noventa días. El segmento más barato es aquel cuyas reglas dejan que Data 360 pare temprano.

Qué no es esta página

Construir la membership es una decisión; qué le pasa son varias otras, cada una con su propia página en esta subcategoría. Esta página para deliberadamente en la lista de individuos que califican. Lo que no cubre, por diseño:

Dónde activa el segmento — el activation target, y por qué un segmento perfecto mandado al lugar equivocado es apenas un query caro. Ver activation targets.
Cómo se manda — batch publish vs. data action en tiempo real — la decisión central de activación, la que vertebra toda la subcategoría. Cubierta junto al target, no acá.
Qué permite el consent — un segmento no debe poder activar a una persona en un canal del que se dio de baja (principios de Data 360, principio 9). Ver consent and activation.

El orden es deliberado: construís una membership correcta primero, después decidís dónde va, qué tan fresca se manda, y qué tiene permitido hacer. Esta página es el paso uno. Las reglas que deciden quién está adentro son la base sobre la que se para cada decisión posterior — equivocalas y la activación más limpia del mundo está entregando la audiencia equivocada, fielmente.

Relacionado

Gotchas de Segmentación & Activación — dónde muerde construir y activar segmentos, la versión de producción
Activation targets — dónde va un segmento construido, y por qué el destino es tan deliberado como las reglas
Consent y activación — por qué un segmento no puede físicamente activar a una persona dada de baja
Segmentation & Activation Style Guide — las convenciones que mantienen legibles las definiciones de segmentos
Principios de Data 360 — frescura (6), computá-una-vez-recuperá-muchas (7), activación (8), costo (11)
Calculated Insights — la métrica pre-computada sobre la que un segmento filtra en vez de recomputar
Consumir resultados de query — cómo un segmento recupera un CI, y el grain que hereda

Reference: