El problema: todos tocan el consentimiento, nadie es su responsable

Pregunta quién es responsable del consentimiento en un publisher típico financiado con publicidad y oirás varias respuestas. Legal redactó la política de cookies. Ad ops añadió los proveedores. Ingeniería instaló el banner. Producto cambió el diseño el trimestre pasado. Marketing añadió un píxel nuevo la semana pasada. Cada uno de esos cambios era razonable por sí solo, pero nadie era responsable de cómo encajaban entre sí — y así es como un sitio acaba con una etiqueta que se dispara antes del consentimiento, un proveedor ausente del banner o un rediseño que redujo en silencio la tasa de consentimiento.

Este artículo propone un modelo de responsabilidades sencillo para que las decisiones sobre el consentimiento tengan un responsable claro, un aprobador claro y un proceso claro.

Por qué la responsabilidad importa tanto para los ingresos como para el riesgo

El consentimiento se sitúa entre dos objetivos que tiran en direcciones distintas. Los equipos legales y de privacidad se centran en si la configuración respeta las elecciones de los usuarios y las normas aplicables. Los equipos de ad ops e ingresos se centran en cuánto inventario se puede monetizar a pleno valor. Ambos hacen bien en preocuparse. Sin un responsable definido, los desacuerdos los resuelve quien tocó la configuración por última vez, en lugar de una decisión que alguien pueda explicar después.

Los roles

La mayoría de los publishers pueden asignar el trabajo de consentimiento a cinco roles, aunque una misma persona reúna varios:

• Privacidad o legal — interpreta las normas, aprueba los propósitos, las bases jurídicas y la redacción del banner, y es responsable de la política de cookies.
• Ad ops o ingresos — gestiona los socios de demanda y las listas de proveedores, supervisa los ingresos relacionados con el consentimiento y solicita los cambios que afectan a la monetización.
• Ingeniería — implementa el CMP, controla la carga de etiquetas y se asegura de que los scripts respetan las señales de consentimiento.
• Producto y diseño — es responsable de la experiencia del banner dentro de los límites que fije legal, y realiza pruebas de maquetación y textos.
• Marketing y analítica — solicita nuevas etiquetas y herramientas de medición y depende de las señales de consentimiento para los informes.

Una matriz RACI para las decisiones recurrentes

Una matriz RACI enumera quién es Responsable (hace el trabajo), Aprobador (toma la decisión final), Consultado e Informado. Este es un punto de partida:

Añadir un nuevo proveedor o etiqueta

• Responsable: ad ops o marketing (quien lo solicite).
• Aprobador: privacidad o legal.
• Consultado: ingeniería, para saber cómo se condicionará al consentimiento.
• Informado: producto.

Cambiar el diseño o los textos del banner

• Responsable: producto y diseño.
• Aprobador: privacidad o legal.
• Consultado: ad ops, por el impacto esperado en los ingresos.
• Informados: ingeniería y marketing.

Cambiar propósitos o bases jurídicas

• Responsable y aprobador: privacidad o legal.
• Consultados: ad ops e ingeniería.
• Informados: todos los que dependen de los datos de consentimiento.

Configuración y despliegues del CMP

• Responsable: ingeniería.
• Aprobador: un responsable del consentimiento designado por nombre (véase más abajo).
• Consultados: privacidad y ad ops.
• Informados: producto y marketing.

Supervisión de las métricas de consentimiento e ingresos

• Responsable: ad ops.
• Aprobador: el responsable del consentimiento.
• Consultado: producto.
• Informado: privacidad o legal, en especial sobre anomalías.

Designa a un único responsable del consentimiento

La matriz RACI funciona mejor cuando una sola persona responde de la configuración del consentimiento en su conjunto. No es necesariamente la persona de mayor rango; es quien mantiene sincronizados la lista de proveedores, la configuración del banner, el inventario de etiquetas y la política de cookies, y quien reúne a las personas adecuadas cuando algo cambia. En los equipos pequeños suele ser alguien de ad ops o ingeniería con línea directa con legal.

Procesos que hacen funcionar el modelo

1. Una vía de solicitud para las etiquetas nuevas. Cada píxel, SDK o socio nuevo pasa por una única entrada, con un formulario breve: qué hace, qué datos recoge, qué propósitos necesita, quién lo solicitó.
2. Un registro de cambios. Anota cada cambio en proveedores, propósitos, texto y diseño del banner, con fecha y aprobador. Es muy valioso cuando se mueve una métrica o llega una pregunta de un socio o de un regulador.
3. Una comprobación previa al despliegue. Ningún despliegue que afecte a etiquetas o al banner sale a producción sin una prueba de consentimiento en un navegador limpio.
4. Una revisión periódica. Una vez por trimestre, el responsable revisa la lista de proveedores frente a las etiquetas reales, las métricas de consentimiento frente a los ingresos y la política de cookies frente a ambos.
5. Una vía de escalado. Cuando legal e ingresos discrepan, la decisión recae en una persona designada y el razonamiento se deja por escrito.

Señales de que falta tu modelo de responsabilidades

• Nadie sabe decir cuándo se revisó por última vez la lista de proveedores.
• Aparecen en el sitio etiquetas que no están en el CMP.
• Los cambios en el banner se publican sin que nadie compruebe después la tasa de consentimiento.
• Distintos equipos dan respuestas diferentes sobre qué socios reciben la cadena TC.
• Las preguntas de los socios sobre las señales de consentimiento tardan días en responderse.

Puntos clave

• El consentimiento afecta a legal, ad ops, ingeniería, producto y marketing; necesita un único responsable designado.
• Una matriz RACI sencilla convierte las decisiones recurrentes en un proceso predecible.
• Canaliza cada etiqueta nueva por una única entrada con una revisión de consentimiento.
• Mantén un registro de cambios y revisa la configuración cada trimestre.
• Deja por escrito cómo se resuelven los desacuerdos entre ingresos y privacidad.