O problema: todos tocan o consentimento, ninguén se fai responsable

Pregunta quen é o responsable do consentimento nun publisher típico que vive da publicidade e escoitarás varias respostas. Xurídico escribiu a política de cookies. Ad ops engadiu os provedores. Enxeñaría instalou o banner. Produto cambiou o deseño o trimestre pasado. Márketing engadiu un píxel novo a semana pasada. Cada un destes cambios era razoable por si mesmo, pero ninguén era responsable de como encaixaban entre eles — e así é como un sitio acaba cunha etiqueta que se dispara antes do consentimento, un provedor ausente do banner, ou un redeseño que reduciu discretamente a taxa de consentimento.

Este artigo propón un modelo de responsabilidades sinxelo para que as decisións sobre consentimento teñan un responsable claro, un aprobador claro e un proceso claro.

Por que a responsabilidade importa tanto para os ingresos como polo risco

O consentimento sitúase entre dous obxectivos que tiran en direccións distintas. Os equipos xurídicos e de privacidade céntranse en se a configuración respecta as eleccións dos usuarios e as normas aplicables. Os equipos de ad ops e de ingresos céntranse en canto do inventario se pode monetizar a pleno valor. Ambos teñen razón en preocuparse. Sen un responsable definido, os desacordos resólvense segundo quen tocou a configuración por última vez, e non por unha decisión que alguén poida explicar despois.

Os roles

A maioría dos publishers poden asignar o traballo de consentimento a cinco roles, aínda que unha soa persoa ocupe varios:

• Privacidade ou xurídico — interpreta as normas, aproba as finalidades, as bases xurídicas e a redacción do banner, e é responsable da política de cookies.
• Ad ops ou ingresos — xestiona os socios de demanda e as listas de provedores, supervisa os ingresos relacionados co consentimento e solicita cambios que afectan a monetización.
• Enxeñaría — implementa o CMP, controla a carga de etiquetas e asegura que os scripts respecten os sinais de consentimento.
• Produto e deseño — é responsable da experiencia do banner dentro dos límites que fixa xurídico, e fai probas de maquetación e de texto.
• Márketing e analítica — solicita novas etiquetas e ferramentas de medición e apóiase nos sinais de consentimento para os informes.

Unha RACI para as decisións recorrentes

Unha RACI enumera quen é Responsable (fai o traballo), Aprobador (toma a decisión final), Consultado e Informado. Aquí tes un punto de partida:

Engadir un provedor ou unha etiqueta novos

• Responsable: ad ops ou márketing (quen o solicite).
• Aprobador: privacidade ou xurídico.
• Consultado: enxeñaría, sobre como se condicionará.
• Informado: produto.

Cambiar o deseño ou o texto do banner

• Responsable: produto e deseño.
• Aprobador: privacidade ou xurídico.
• Consultado: ad ops, sobre o impacto esperado nos ingresos.
• Informados: enxeñaría e márketing.

Cambiar finalidades ou bases xurídicas

• Responsable e aprobador: privacidade ou xurídico.
• Consultados: ad ops e enxeñaría.
• Informados: todos os que dependen dos datos de consentimento.

Configuración e lanzamentos do CMP

• Responsable: enxeñaría.
• Aprobador: un responsable do consentimento designado (ver máis abaixo).
• Consultados: privacidade e ad ops.
• Informados: produto e márketing.

Supervisión das métricas de consentimento e de ingresos

• Responsable: ad ops.
• Aprobador: o responsable do consentimento.
• Consultado: produto.
• Informado: privacidade ou xurídico, sobre todo sobre anomalías.

Designa un único responsable do consentimento

A RACI funciona mellor cando unha persoa é responsable da configuración do consentimento no seu conxunto. Non é necesariamente a persoa de maior rango; é a persoa que mantén aliñados a lista de provedores, a configuración do banner, o inventario de etiquetas e a política de cookies, e que reúne as persoas adecuadas cando algo cambia. Nos equipos pequenos adoita ser alguén de ad ops ou de enxeñaría con liña directa con xurídico.

Procesos que fan funcionar o modelo

1. Unha vía de solicitude para as etiquetas novas. Cada píxel, SDK ou socio novo pasa por unha única entrada, cun formulario breve: que fai, que datos recolle, que finalidades precisa, quen o solicitou.
2. Un rexistro de cambios. Anota cada cambio en provedores, finalidades, texto e deseño do banner, cunha data e un aprobador. É moi valioso cando unha métrica se move ou chega unha pregunta dun socio ou dun regulador.
3. Unha comprobación antes do lanzamento. Ningún lanzamento que toque etiquetas ou o banner sae a produción sen unha proba de consentimento nun navegador limpo.
4. Unha revisión periódica. Unha vez por trimestre, o responsable revisa a lista de provedores respecto ás etiquetas reais, as métricas de consentimento respecto aos ingresos, e a política de cookies respecto a ambas.
5. Unha vía de escalada. Cando xurídico e ingresos discrepan, a decisión vai a unha persoa designada, e o razoamento déixase por escrito.

Sinais de que che falta un modelo de responsabilidades

• Ninguén sabe dicir cando se revisou por última vez a lista de provedores.
• No sitio aparecen etiquetas que non están no CMP.
• Os cambios no banner publícanse sen que ninguén comprobe despois a taxa de consentimento.
• Equipos distintos dan respostas distintas sobre que socios reciben a TC string.
• As preguntas dos socios sobre os sinais de consentimento tardan días en responderse.

Ideas clave

• O consentimento toca xurídico, ad ops, enxeñaría, produto e márketing; necesita un único responsable coa última palabra.
• Unha RACI sinxela converte as decisións recorrentes nun proceso previsible.
• Fai pasar cada etiqueta nova por unha única entrada cunha revisión de consentimento.
• Leva un rexistro de cambios e revisa a configuración cada trimestre.
• Deixa por escrito como se resolven os desacordos entre ingresos e privacidade.