Problema: toată lumea atinge consimțământul, nimeni nu răspunde de el

Întreabă cine deține consimțământul la un editor obișnuit finanțat din publicitate și vei auzi mai multe răspunsuri. Echipa juridică a scris politica de cookie-uri. Ad ops a adăugat furnizorii. Ingineria a instalat bannerul. Produsul a schimbat designul trimestrul trecut. Marketingul a adăugat un pixel nou săptămâna trecută. Fiecare dintre aceste schimbări era rezonabilă singură, dar nimeni nu răspundea de modul în care se îmbinau — și așa ajunge un site cu un tag care se declanșează înainte de consimțământ, un furnizor lipsă din banner sau o regândire a designului care a redus pe nesimțite rata de consimțământ.

Acest articol propune un model simplu de responsabilitate, astfel încât deciziile despre consimțământ să aibă un responsabil clar, un aprobator clar și un proces clar.

De ce contează responsabilitatea pentru venituri, nu doar pentru risc

Consimțământul se află între două obiective care trag în direcții diferite. Echipele juridice și de confidențialitate se concentrează pe dacă configurarea respectă alegerile utilizatorilor și regulile aplicabile. Echipele de ad ops și de venituri se concentrează pe cât din inventar poate fi monetizat la valoare deplină. Ambele au dreptate să fie preocupate. Fără un responsabil definit, dezacordurile se rezolvă după cine a atins ultimul configurarea, nu printr-o decizie pe care cineva o poate explica mai târziu.

Rolurile

Majoritatea editorilor pot asocia munca legată de consimțământ cu cinci roluri, chiar dacă o singură persoană le ocupă pe mai multe:

• Confidențialitate sau juridic — interpretează regulile, aprobă scopurile, bazele legale și formularea bannerului și deține politica de cookie-uri.
• Ad ops sau venituri — gestionează partenerii de cerere și listele de furnizori, monitorizează veniturile legate de consimțământ și solicită modificări care afectează monetizarea.
• Inginerie — implementează CMP-ul, controlează încărcarea tagurilor și se asigură că scripturile respectă semnalele de consimțământ.
• Produs și design — deține experiența bannerului în limitele stabilite de juridic și rulează teste de aspect și de text.
• Marketing și analitică — solicită taguri și instrumente de măsurare noi și se bazează pe semnalele de consimțământ pentru raportare.

Un RACI pentru deciziile recurente

Un RACI enumeră cine este Responsabil (face munca), Aprobator (ia decizia finală), Consultat și Informat. Iată un punct de pornire:

Adăugarea unui furnizor sau tag nou

• Responsabil: ad ops sau marketing (cine îl solicită).
• Aprobator: confidențialitate sau juridic.
• Consultat: ingineria, cu privire la modul în care va fi condiționat.
• Informat: produsul.

Schimbarea designului sau a textului bannerului

• Responsabil: produs și design.
• Aprobator: confidențialitate sau juridic.
• Consultat: ad ops, pentru impactul estimat asupra veniturilor.
• Informați: ingineria și marketingul.

Schimbarea scopurilor sau a bazelor legale

• Responsabil și aprobator: confidențialitate sau juridic.
• Consultați: ad ops și ingineria.
• Informați: toți cei care se bazează pe datele de consimțământ.

Configurarea și lansările CMP

• Responsabil: ingineria.
• Aprobator: un responsabil de consimțământ numit (vezi mai jos).
• Consultați: confidențialitatea și ad ops.
• Informați: produsul și marketingul.

Monitorizarea metricilor de consimțământ și de venituri

• Responsabil: ad ops.
• Aprobator: responsabilul de consimțământ.
• Consultat: produsul.
• Informat: confidențialitatea sau juridicul, mai ales cu privire la anomalii.

Numește un singur responsabil de consimțământ

RACI funcționează cel mai bine când o singură persoană răspunde de configurarea consimțământului în ansamblu. Aceasta nu este neapărat persoana cea mai înaltă în funcție; este persoana care ține în pas lista de furnizori, configurarea bannerului, inventarul de taguri și politica de cookie-uri și care adună oamenii potriviți când se schimbă ceva. În echipele mici, este adesea cineva din ad ops sau din inginerie, cu legătură directă la juridic.

Procese care fac modelul să funcționeze

1. Un traseu de solicitare pentru taguri noi. Fiecare pixel, SDK sau partener nou trece printr-un singur punct de intrare, cu un formular scurt: ce face, ce date colectează, de ce scopuri are nevoie, cine l-a solicitat.
2. Un jurnal al modificărilor. Înregistrează fiecare modificare a furnizorilor, scopurilor, textului și designului bannerului, cu o dată și un aprobator. E de neprețuit când se mișcă o metrică sau vine o întrebare de la un partener ori de la un organism de reglementare.
3. O verificare înainte de lansare. Nicio lansare care atinge tagurile sau bannerul nu intră în producție fără un test de consimțământ într-un browser curat.
4. O revizuire periodică. O dată pe trimestru, responsabilul compară lista de furnizori cu tagurile reale, metricile de consimțământ cu veniturile și politica de cookie-uri cu ambele.
5. O cale de escaladare. Când juridicul și veniturile nu sunt de acord, decizia merge la o persoană numită, iar raționamentul este consemnat în scris.

Semne că îți lipsește un model de responsabilitate

• Nimeni nu poate spune când a fost revizuită ultima oară lista de furnizori.
• Pe site apar taguri care nu sunt în CMP.
• Schimbările de banner sunt lansate fără ca cineva să verifice ulterior rata de consimțământ.
• Echipe diferite dau răspunsuri diferite despre ce parteneri primesc TC string.
• Întrebările partenerilor despre semnalele de consimțământ durează zile până primesc răspuns.

Concluzii-cheie

• Consimțământul implică juridicul, ad ops, ingineria, produsul și marketingul; are nevoie de un singur responsabil care răspunde.
• Un RACI simplu transformă deciziile recurente într-un proces previzibil.
• Trece fiecare tag nou printr-un singur punct de intrare, cu o revizuire a consimțământului.
• Ține un jurnal al modificărilor și revizuiește configurarea trimestrial.
• Consemnează în scris cum se rezolvă dezacordurile dintre venituri și confidențialitate.