De quem é o consentimento? Um modelo simples de responsabilidade para equipes de editores
O problema: todos mexem no consentimento, ninguém é o dono
Pergunte quem é o dono do consentimento em um editor típico financiado por anúncios e você ouvirá várias respostas. O jurídico escreveu a política de cookies. O ad ops adicionou os fornecedores. A engenharia instalou o banner. O produto mudou o design no trimestre passado. O marketing adicionou um novo pixel na semana passada. Cada uma dessas mudanças era razoável por si só, mas ninguém era responsável por como elas se encaixavam — e é assim que um site acaba com uma tag disparando antes do consentimento, um fornecedor ausente do banner ou um redesign que reduziu silenciosamente a taxa de consentimento.
Este artigo propõe um modelo simples de responsabilidade para que as decisões sobre consentimento tenham um responsável claro, um aprovador claro e um processo claro.
Por que a responsabilidade importa tanto para a receita quanto para o risco
O consentimento fica entre dois objetivos que puxam em direções diferentes. As equipes jurídica e de privacidade se concentram em saber se a configuração respeita as escolhas dos usuários e as regras aplicáveis. As equipes de ad ops e de receita se concentram em quanto inventário pode ser monetizado pelo valor integral. Ambas têm razão em se importar. Sem um responsável definido, os desacordos são resolvidos por quem mexeu na configuração por último, e não por uma decisão que alguém possa explicar depois.
Os papéis
A maioria dos editores consegue mapear o trabalho de consentimento em cinco papéis, mesmo que uma só pessoa acumule vários:
- Privacidade ou jurídico — interpreta as regras, aprova finalidades, bases legais e o texto do banner, e é dono da política de cookies.
- Ad ops ou receita — gerencia os parceiros de demanda e as listas de fornecedores, monitora a receita relacionada ao consentimento e solicita mudanças que afetam a monetização.
- Engenharia — implementa o CMP, controla o carregamento de tags e garante que os scripts respeitem os sinais de consentimento.
- Produto e design — é dono da experiência do banner dentro dos limites definidos pelo jurídico e conduz testes de layout e texto.
- Marketing e analytics — solicita novas tags e ferramentas de medição e depende dos sinais de consentimento para os relatórios.
Uma matriz RACI para as decisões recorrentes
Uma matriz RACI lista quem é Responsável (faz o trabalho), Aprovador (toma a decisão final), Consultado e Informado. Eis um ponto de partida:
Adicionar um novo fornecedor ou tag
- Responsável: ad ops ou marketing (quem solicitar).
- Aprovador: privacidade ou jurídico.
- Consultada: a engenharia, sobre como ele será condicionado ao consentimento.
- Informado: o produto.
Mudar o design ou o texto do banner
- Responsável: produto e design.
- Aprovador: privacidade ou jurídico.
- Consultado: o ad ops, quanto ao impacto esperado na receita.
- Informados: engenharia e marketing.
Mudar finalidades ou bases legais
- Responsável e aprovador: privacidade ou jurídico.
- Consultados: ad ops e engenharia.
- Informados: todos que dependem dos dados de consentimento.
Configuração e lançamentos do CMP
- Responsável: engenharia.
- Aprovador: um dono do consentimento designado nominalmente (veja abaixo).
- Consultados: privacidade e ad ops.
- Informados: produto e marketing.
Monitoramento das métricas de consentimento e receita
- Responsável: ad ops.
- Aprovador: o dono do consentimento.
- Consultado: o produto.
- Informado: privacidade ou jurídico, principalmente sobre anomalias.
Designe um único dono do consentimento
A matriz RACI funciona melhor quando uma pessoa responde pela configuração do consentimento como um todo. Não é necessariamente a pessoa mais sênior; é quem mantém em sintonia a lista de fornecedores, a configuração do banner, o inventário de tags e a política de cookies, e quem reúne as pessoas certas quando algo muda. Em equipes pequenas, costuma ser alguém de ad ops ou de engenharia com linha direta com o jurídico.
Processos que fazem o modelo funcionar
- Um caminho de solicitação para novas tags. Todo novo pixel, SDK ou parceiro passa por uma única porta de entrada, com um formulário curto: o que faz, quais dados coleta, de quais finalidades precisa, quem solicitou.
- Um registro de mudanças. Registre cada alteração em fornecedores, finalidades, texto e design do banner, com data e aprovador. É valiosíssimo quando uma métrica se move ou chega uma pergunta de um parceiro ou regulador.
- Uma verificação de lançamento. Nenhum lançamento que mexa em tags ou no banner vai ao ar sem um teste de consentimento em um navegador limpo.
- Uma revisão regular. Uma vez por trimestre, o dono revisa a lista de fornecedores em relação às tags reais, as métricas de consentimento em relação à receita e a política de cookies em relação a ambos.
- Um caminho de escalonamento. Quando jurídico e receita discordam, a decisão vai para uma pessoa designada, e o raciocínio é registrado por escrito.
Sinais de que falta um modelo de responsabilidade
- Ninguém sabe dizer quando a lista de fornecedores foi revisada pela última vez.
- Aparecem no site tags que não estão no CMP.
- Mudanças no banner são publicadas sem que ninguém verifique depois a taxa de consentimento.
- Equipes diferentes dão respostas diferentes sobre quais parceiros recebem a string TC.
- As perguntas dos parceiros sobre sinais de consentimento levam dias para ser respondidas.
Principais conclusões
- O consentimento envolve jurídico, ad ops, engenharia, produto e marketing; precisa de um único dono responsável.
- Uma matriz RACI simples transforma decisões recorrentes em um processo previsível.
- Direcione toda nova tag por uma única porta de entrada com uma revisão de consentimento.
- Mantenha um registro de mudanças e revise a configuração trimestralmente.
- Registre por escrito como os desacordos entre receita e privacidade são resolvidos.