Consentimiento y activación: volver el opt-out físicamente no-activable | Cleon

Un segmento que apunta a la gente correcta igual va a enviarle a la equivocada. El segment builder evalúa membership contra comportamiento, atributos y Calculated Insights — y nada de esa lógica sabe si una persona hizo opt-out. Construís "clientes que navegaron pero no compraron" y la audiencia incluye a la persona que se desuscribió la semana pasada, porque nada en la regla lo preguntó. La activación después envía esa audiencia fielmente al canal. El opt-out no falla con ruido; viaja adentro, invisible, hasta que aterriza en un inbox que explícitamente lo rechazó.

Esta página es la profundidad detrás del gotcha 4 y el mecanismo detrás del principio 9: el consentimiento viaja con la data, y un segmento tiene que ser físicamente incapaz de activar a una persona en un canal que rechazó. El arreglo no es un filtro que alguien se acuerda de agregar a cada segmento — es estructural, enforced en el borde de activación por una parte de la plataforma construida exactamente para esto. Acá está qué es esa parte, qué la respalda, y la disciplina que la vuelve confiable en lugar de esperanzada.

Por qué la lógica del segmento no puede cargar el consentimiento

El consentimiento y el membership de un segmento responden preguntas distintas, y confundirlas es la raíz de la falla. Un segmento responde quién matchea estas reglas — una población, evaluada contra el unified profile. El consentimiento responde qué tengo permitido hacer con esta persona, en qué canal, para qué propósito — un permiso, atado a un contact point. Las dos son ortogonales: una persona puede matchear cada regla de un segmento de comportamiento y aun así haber revocado el permiso de email, y un segmento correcto la va a incluir precisamente porque matchear las reglas era todo lo que el segmento estaba preguntando.

Podés meter un chequeo de consentimiento dentro de la lógica del segmento — agregás un filtro "email opt-in = true" al container y la audiencia se angosta. Los equipos hacen esto, y es exactamente la trampa. Funciona hasta que el segmento que alguien construye el próximo trimestre se olvida del filtro, o la campaña reutiliza un segmento más viejo que es anterior a la regla, o sale un canal nuevo y nadie agrega la condición que le corresponde. La falla de compliance casi nunca es malicia; es un segmento al que nadie le avisó del opt-out. El consentimiento enforced como un filtro que hay que recordar es consentimiento enforced por disciplina, y la disciplina no escala a cada builder en cada segmento para siempre.

Así que el enforcement tiene que vivir por debajo del segmento — en el borde donde el membership se vuelve una activación — donde aplica sin importar cómo se escribió el segmento ni quién lo escribió.

La superficie de enforcement: Contact Point Filtering

En Data 360 (antes Data Cloud) el mecanismo del borde es Contact Point Filtering. Cuando configurás una activación, después de elegir el canal y su contact point — el email, el número de teléfono, el push token al que la destination le pega — la contact-point card expone un filtro. Ese filtro es donde se enforce el consentimiento: evalúa el consentimiento de cada miembro contra condiciones que vos seteás, y excluye de lo que efectivamente se envía a los contact points que no califican. El segmento todavía puede contener a la persona que hizo opt-out; Contact Point Filtering es la razón por la que esa persona no sale de la plataforma hacia el canal que rechazó.

La distinción es todo el punto. El segmento es ciego al consentimiento por diseño — cuenta quién matchea. Contact Point Filtering es la capa consciente del consentimiento que se sienta entre esa población y la destination, para que la audiencia que se publica sea la audiencia menos todos los que no tienen permitido recibirla. Membership y deliverability son dos hechos distintos, y el filtro es la costura que mantiene honesto al segundo.

Segmento           → quién matchea las reglas         (ciego al consentimiento: incluye el opt-out)
Contact Point      → el email / phone / push key      (a qué le envía el canal)
Contact Point Filtering → consentimiento enforced acá (excluye el contact point sin consentimiento)
Activación         → lo que efectivamente se envía    (la audiencia MENOS quién no puede recibirla)

Qué la respalda: el Contact Point Consent DMO

Un filtro es tan confiable como la data que lee, y Contact Point Filtering lee el consentimiento desde el modelo — específicamente del Contact Point Consent DMO, el objeto estándar que guarda el registro de consentimiento de un contact point. Para preferencias a nivel suscripción (una persona consintió esta comunicación pero no aquella) hay un objeto paralelo Contact Point Subscription Consent en el grano más fino. Estos son donde "esta persona hizo opt-out" deja de ser conocimiento tribal en algún sistema de origen y se vuelve un atributo modelado y consultable contra el que el borde de activación puede enforce.

El filtro evalúa dos atributos que viven los dos en ese DMO:

Consent status — si la persona hizo opt-in u opt-out para el contact point. En el DMO estándar esto es la referencia de consent status (ssot__ConsentStatusId__c), el campo que distingue un permiso vivo de uno retirado.
Data-use purpose — para qué es el permiso: marketing, analytics, un propósito de procesamiento específico. Se carga como la referencia de data-use purpose (ssot__DataUsePurposeId__c). Una persona puede estar opted in para un propósito y out para otro, y "opted in" no significa nada sin el propósito al que se ata.

Consent status es el atributo que la gente agarra primero; data-use purpose es el que vuelve correcto al enforcement. Filtrar solo sobre el status trata al consentimiento como un único interruptor on/off, cuando el consentimiento 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. Los dos atributos juntos son lo que le permite al filtro honrar esa distinción — y por eso los dos pertenecen al modelo, no solo el fácil.

La disciplina: modelá el consentimiento, no lo recuerdes

La postura de Cleon en esto es compliance by design, y es una decisión de modelado antes que una decisión de activación. Dos cosas tienen que ser verdad para que el camino seguro sea el único camino:

El consentimiento y el data-use purpose están modelados junto a la data, poblados en el Contact Point Consent DMO (y el objeto a nivel suscripción donde necesitás granularidad por mensaje) igual que cualquier otro atributo — para que la superficie de enforcement tenga data real y fresca que leer. El consentimiento que vive solo en un sistema de origen que la activación no puede ver es consentimiento que no se puede enforce. El DMO es donde tiene que aterrizar (data model objects).
Contact Point Filtering se aplica como convención permanente en cada activación hacia un canal con consentimiento, no como un agregado tardío por segmento. El objetivo es que una activación hacia email no pueda configurarse para ignorar el consentimiento de email — que excluir el contact point sin consentimiento sea la forma por default de cómo se construyen las activaciones acá, para que un segmento nuevo herede la protección sin que nadie la vuelva a derivar.

La razón para empujar esto al modelo y a la convención, en lugar de a la lógica de cada segmento, es la misma razón por la que toda otra disciplina de Data 360 empuja el leverage hacia arriba: la falla contra la que te estás cuidando es la que nadie está pensando. Un filtro de consentimiento adentro de un segmento protege ese segmento. El consentimiento modelado sobre el contact point y enforced en el borde protege cada activación, incluyendo la que un compañero construye el año que viene sobre un segmento que vos nunca viste. Hacé que el camino seguro sea el único camino, y "¿alguien se acordó del opt-out?" deja de ser una pregunta que tenés que hacer.

Por esto también el consentimiento es el hilo que corre por debajo de toda la subcategoría en lugar de ser preocupación de una sola página. La decisión de target es exactamente donde muerde — una destination keyed a un contact point es donde un email sin consentimiento saldría si no. Construir un segmento deliberadamente no lo resuelve, porque resolverlo ahí significaría resolverlo una vez en lugar de estructuralmente. Y el puente a Marketing Cloud carga la misma obligación a través de la costura entre plataformas: un opt-out honrado en Data 360 tiene que seguir honrado en lo que el Journey recibe.

Qué no es esta página

Esto es el modelo y el patrón de enforcement y la disciplina — no un setup click por click. Los pasos exactos para configurar un filtro de contact point, el permission set que te deja construir uno, el mapeo campo por campo hacia el Contact Point Consent DMO, y cómo se ingiere el consentimiento a nivel suscripción están documentados por Salesforce y son específicos por versión; las referencias de abajo son los puntos de partida canónicos. Lo que no cambia con las release notes es la forma de la cosa: la lógica del segmento es ciega al consentimiento, el borde de activación es donde el consentimiento se enforce, Contact Point Filtering es la superficie y el Contact Point Consent DMO es lo que lee, y la única versión durable de "honramos los opt-outs" es la que un builder no puede olvidar porque el modelo y la convención no dejan que la activación insegura exista.

Relacionado

Gotchas de segmentación y activación — el gotcha 4 es esta falla en breve; esta página es la profundidad detrás
Construir segmentos — por qué el segmento deliberadamente no carga el consentimiento
Activation targets — la destination keyed a un contact point donde el consentimiento muerde
Activar hacia Marketing Cloud — cargar el opt-out con honestidad a través de la costura entre plataformas
Style Guide de segmentación y activación — la disciplina que ata estas decisiones de activación
Principios de Data 360 — el consentimiento viaja con la data (principio 9)
Data Model Objects — dónde vive el Contact Point Consent DMO en el modelo

Reference: