El problema: tothom toca el consentiment, ningú no se'n fa responsable

Pregunta qui és el responsable del consentiment en un editor típic que viu de la publicitat i sentiràs diverses respostes. Jurídic va escriure la política de cookies. Ad ops va afegir els proveïdors. Enginyeria va instal·lar el bàner. Producte va canviar el disseny el trimestre passat. Màrqueting va afegir un píxel nou la setmana passada. Cadascun d'aquests canvis era raonable per se, però ningú era responsable de com encaixaven entre ells — i així és com un lloc acaba amb una etiqueta que es dispara abans del consentiment, un proveïdor absent del bàner, o un redisseny que ha reduït discretament la taxa de consentiment.

Aquest article proposa un model de responsabilitats senzill perquè les decisions sobre consentiment tinguin un responsable clar, un aprovador clar i un procés clar.

Per què la responsabilitat importa tant per als ingressos com pel risc

El consentiment se situa entre dos objectius que tiren en direccions diferents. Els equips jurídics i de privacitat se centren en si la configuració respecta les eleccions dels usuaris i les normes aplicables. Els equips d'ad ops i d'ingressos se centren en quanta part de l'inventari es pot monetitzar a ple valor. Tots dos tenen raó de preocupar-se. Sense un responsable definit, els desacords es resolen segons qui va tocar la configuració per última vegada, i no per una decisió que algú pugui explicar després.

Els rols

La majoria d'editors poden assignar el treball de consentiment a cinc rols, encara que una sola persona n'ocupi diversos:

• Privacitat o jurídic — interpreta les normes, aprova les finalitats, les bases jurídiques i la redacció del bàner, i és responsable de la política de cookies.
• Ad ops o ingressos — gestiona els socis de demanda i les llistes de proveïdors, supervisa els ingressos relacionats amb el consentiment i sol·licita canvis que afecten la monetització.
• Enginyeria — implementa el CMP, controla la càrrega d'etiquetes i s'assegura que els scripts respectin els senyals de consentiment.
• Producte i disseny — és responsable de l'experiència del bàner dins dels límits que fixa jurídic, i fa proves de maquetació i de text.
• Màrqueting i analítica — sol·licita noves etiquetes i eines de mesura i es recolza en els senyals de consentiment per als informes.

Una RACI per a les decisions recurrents

Una RACI enumera qui és Responsable (fa la feina), Aprovador (pren la decisió final), Consultat i Informat. Aquí tens un punt de partida:

Afegir un proveïdor o una etiqueta nous

• Responsable: ad ops o màrqueting (qui ho sol·liciti).
• Aprovador: privacitat o jurídic.
• Consultat: enginyeria, sobre com es condicionarà.
• Informat: producte.

Canviar el disseny o el text del bàner

• Responsable: producte i disseny.
• Aprovador: privacitat o jurídic.
• Consultat: ad ops, sobre l'impacte esperat en els ingressos.
• Informat: enginyeria i màrqueting.

Canviar finalitats o bases jurídiques

• Responsable i aprovador: privacitat o jurídic.
• Consultat: ad ops i enginyeria.
• Informat: tothom qui depèn de les dades de consentiment.

Configuració i llançaments del CMP

• Responsable: enginyeria.
• Aprovador: un responsable del consentiment designat (vegeu més avall).
• Consultats: privacitat i ad ops.
• Informat: producte i màrqueting.

Supervisió de les mètriques de consentiment i d'ingressos

• Responsable: ad ops.
• Aprovador: el responsable del consentiment.
• Consultat: producte.
• Informat: privacitat o jurídic, sobretot sobre anomalies.

Designa un únic responsable del consentiment

La RACI funciona millor quan una persona és responsable de la configuració del consentiment en conjunt. No és necessàriament la persona de més rang; és la persona que manté alineats la llista de proveïdors, la configuració del bàner, l'inventari d'etiquetes i la política de cookies, i que reuneix les persones adequades quan alguna cosa canvia. En equips petits sol ser algú d'ad ops o d'enginyeria amb línia directa amb jurídic.

Processos que fan funcionar el model

1. Una via de sol·licitud per a les etiquetes noves. Cada píxel, SDK o soci nou passa per una única entrada, amb un formulari breu: què fa, quines dades recull, quines finalitats necessita, qui ho ha sol·licitat.
2. Un registre de canvis. Anota cada canvi en proveïdors, finalitats, text i disseny del bàner, amb una data i un aprovador. És molt valuós quan una mètrica es mou o arriba una pregunta d'un soci o d'un regulador.
3. Una comprovació abans del llançament. Cap llançament que toqui etiquetes o el bàner no surt en producció sense una prova de consentiment en un navegador net.
4. Una revisió periòdica. Un cop per trimestre, el responsable revisa la llista de proveïdors respecte a les etiquetes reals, les mètriques de consentiment respecte als ingressos, i la política de cookies respecte a totes dues.
5. Una via d'escalada. Quan jurídic i ingressos discrepen, la decisió va a una persona designada, i el raonament es deixa per escrit.

Senyals que et falta un model de responsabilitats

• Ningú no sap dir quan es va revisar per última vegada la llista de proveïdors.
• Al lloc apareixen etiquetes que no són al CMP.
• Els canvis al bàner es publiquen sense que ningú comprovi després la taxa de consentiment.
• Equips diferents donen respostes diferents sobre quins socis reben la TC string.
• Les preguntes dels socis sobre els senyals de consentiment triguen dies a respondre's.

Idees clau

• El consentiment toca jurídic, ad ops, enginyeria, producte i màrqueting; necessita un únic responsable amb l'última paraula.
• Una RACI senzilla converteix les decisions recurrents en un procés previsible.
• Fes passar cada etiqueta nova per una única entrada amb una revisió de consentiment.
• Porta un registre de canvis i revisa la configuració cada trimestre.
• Deixa per escrit com es resolen els desacords entre ingressos i privacitat.