Chrome Privacy Sandbox e a Topics API: O Guia do Editor para 2026 sobre Consentimento, Segmentação e Medição
Durante a maior parte da última década, a publicidade digital funcionou com uma suposição simples: os cookies de terceiros sempre estariam presentes, transportando silenciosamente identificadores de utilizadores pela web. Essa suposição está agora quebrada. O caminho de descontinuação do Chrome mudou várias vezes, mas a direção da viagem não mudou: o rastreamento entre sites por meio de cookies de terceiros está a chegar ao fim, e o Privacy Sandbox do Google é o substituto que o Chrome quer que editores e anunciantes adotem. O Sandbox não é um produto único. É um conjunto de APIs do navegador — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage e mais — cada um substituindo um caso de uso específico que os cookies costumavam cobrir. Para um editor, a parte difícil não é entender as APIs individualmente. É construir uma camada de consentimento e um caminho de monetização que mantenha os fluxos do Privacy Sandbox, a conformidade com o GDPR e a lei estadual de privacidade todos alinhados simultaneamente. Este guia examina as peças em movimento em 2026 e como a sua pilha de consentimento precisa de se parecer.
O que o Privacy Sandbox Realmente Substitui
Os cookies de terceiros carregavam quatro funções publicitárias distintas: segmentação baseada em interesses, retargeting, medição de conversão e limitação de frequência. O Privacy Sandbox divide-as em APIs separadas, cada uma com o seu próprio perfil de consentimento.
Topics API — Segmentação Baseada em Interesses
A Topics API atribui a cada navegador um pequeno conjunto de tópicos de interesse de grão grosseiro — cerca de cinco tópicos por semana, extraídos de uma taxonomia curada de algumas centenas de categorias. Quando um editor chama document.browsingTopics(), o navegador retorna até três tópicos que o ecossistema de tecnologia publicitária pode usar para personalização contextual sem qualquer identificador entre sites. Os tópicos são calculados localmente, armazenados no dispositivo, rodados semanalmente e estão sujeitos a controlos do utilizador em chrome://settings/adPrivacy.
Protected Audience API — Retargeting e Remarketing
Protected Audience, anteriormente FLEDGE, mantém o retargeting vivo sem um identificador entre sites compartilhado. Os anunciantes adicionam um utilizador a um grupo de interesse no seu próprio site; quando o utilizador visita um editor participante, um leilão no dispositivo é executado num Fenced Frame e seleciona um criativo. O anúncio vencedor é renderizado sem que o editor saiba qual grupo de interesse correspondeu.
Attribution Reporting API — Medição de Conversão
Attribution Reporting substitui os pixels de conversão para um subconjunto de casos de uso de medição. Suporta relatórios no nível do evento (com ruído, com perda, por conversão) e relatórios de resumo agregado (resumos estatisticamente sem viés). Ao contrário do pixel legado, não expõe a ligação individual utilizador-para-conversão.
Shared Storage e Fenced Frames
Shared Storage é um armazenamento de chave-valor gravável em qualquer lugar, legível na sandbox para casos de uso entre sites, como limitação de frequência e consistência de experimentos A/B. Fenced Frames são iframes isolados que impedem a página circundante de ler o anúncio renderizado ou os seus dados de interação.
O Privacy Sandbox Requer Consentimento?
Esta é a pergunta mais mal compreendida no panorama da tecnologia publicitária de 2026, e a resposta é específica para cada jurisdição.
Sob o GDPR e ePrivacy
O Conselho Europeu de Proteção de Dados não emitiu uma posição abrangente, mas as autoridades nacionais foram mais explícitas. O ICO do Reino Unido, o Garante italiano e o CNIL francês adotaram todos o ponto de vista de que Topics e Protected Audience requerem consentimento opt-in prévio onde processam dados pessoais, incluindo qualquer processamento que escreva ou leia estado no dispositivo do utilizador. A lógica: o navegador ainda armazena tópicos de interesse e grupos de interesse localmente, e a chamada document.browsingTopics() transmite dados pessoais inferidos a um terceiro. Isso é regulamentado pelo Artigo 5(3) da Diretiva ePrivacy, que exige consentimento para qualquer acesso ou armazenamento no equipamento terminal do utilizador além do estritamente necessário para o serviço solicitado.
A posição do Google é mais permissiva — eles argumentam que as APIs são projetadas para preservar a privacidade e que os requisitos de consentimento podem não se aplicar em todos os contextos. Esta não é uma posição regulatória. Tratar o Privacy Sandbox como isento de consentimento na Europa é uma postura de alto risco.
Sob CCPA, CPRA e Leis Estaduais dos EUA
Nos Estados Unidos, os fluxos do Privacy Sandbox são geralmente tratados como partilha de informações pessoais para publicidade comportamental entre contextos sob a CPRA. Isso significa que acionam o direito de opt-out e devem ser respeitados através de sinais do Global Privacy Control e outros mecanismos universais de opt-out. O facto de os dados do Topics serem derivados do navegador em vez de vendidos por um corretor de terceiros não os isenta.
Os Próprios Controlos do Chrome
O Chrome fornece controlos visíveis para o utilizador em chrome://settings/adPrivacy para Topics, Protected Audience e Attribution Reporting. Estas escolhas do utilizador ficam ao lado — não no lugar — do estado de consentimento do seu CMP. Um utilizador que disse não aos cookies de publicidade no seu banner, mas sim ao Topics nas configurações globais do Chrome, ainda lhe disse não através do banner. A sua pilha deve respeitar o mais restritivo dos dois sinais.
A Camada de Consentimento que Você Realmente Precisa
Uma pilha de consentimento de 2026 pronta para produção trata as APIs do Privacy Sandbox como atividades de processamento distintas, cada uma gerida através de finalidades IAB TCF ou categorias equivalentes da lei estadual.
Mapeamento das APIs do Sandbox para Finalidades TCF
- Topics API — Finalidade IAB TCF 2 (Selecionar anúncios básicos) e Finalidade 3 (Criar um perfil de anúncios personalizados) como mínimo; Finalidade 4 (Selecionar anúncios personalizados) se os tópicos alimentarem a segmentação.
- Protected Audience — Finalidade 3 e 4, mais Finalidade 7 (Medir o desempenho dos anúncios) se o leilão usar dados de resultados.
- Attribution Reporting — Finalidade 7 (Medir o desempenho dos anúncios) e Finalidade 9 (Compreender audiências através de estatísticas).
- Shared Storage para limitação de frequência — Finalidade 3 onde alimenta a personalização, ou uma base de interesse legítimo onde é puramente controlo de frequência.
Mapeamento para o Google Consent Mode v2
Os sinais do Google Consent Mode v2 mapeiam para o comportamento do Privacy Sandbox:
- ad_storage negado — desativar completamente as chamadas às APIs Topics e Protected Audience
- ad_user_data negado — bloquear o Attribution Reporting de enviar dados com escopo do utilizador
- ad_personalization negado — ignorar as entradas do Topics na lógica de segmentação
Tratamento de Sinais Estaduais dos EUA
Para o tráfego dos EUA, a sua camada de consentimento deve inspecionar o Global Privacy Control e os sinais de opt-out estaduais aplicáveis. Quando um utilizador dos EUA tiver optado por não partilhar, suprima document.browsingTopics(), não chame joinAdInterestGroup e remova os cabeçalhos de registo do Attribution Reporting.
Padrões de Implementação Práticos
Os editores que já implementaram o Privacy Sandbox geralmente seguem um de dois padrões arquitetónicos.
Padrão 1: Orquestração do Lado do Servidor
Um gestor de tags de primeira parte na sua origem recolhe o estado de consentimento, a jurisdição do utilizador e quaisquer substituições de sinal, e depois renderiza condicionalmente os ganchos do Privacy Sandbox na página. O servidor de anúncios e o SSP recebem sinalizadores de consentimento através do pedido de licitação, e eles decidem se chamam Topics, Protected Audience ou nenhum. Este padrão centraliza a lógica e mantém o estado de consentimento como autoritativo.
Padrão 2: Integração com Wrapper de Header Bidding
O Prebid.js e outros wrappers de header bidding agora suportam módulos do Privacy Sandbox. O wrapper lê o sinal de consentimento, configura o comportamento da chamada do Topics e encaminha o resultado do leilão através do Protected Audience quando permitido. Esta abordagem é mais leve de implementar, mas empurra mais lógica para o cliente e aumenta a sua dependência da cadência de lançamento do wrapper.
O que Auditar
- Confirme que
document.browsingTopics()não é chamado a menos que o consentimento de publicidade do CMP seja afirmativo e nenhum sinal de opt-out esteja presente - Confirme que
joinAdInterestGrouperunAdAuctionsão controlados pelas mesmas condições - Confirme que os cabeçalhos de registo do Attribution Reporting são enviados apenas em respostas para utilizadores cujo estado de consentimento permite medição
- Confirme que a sua lista de fornecedores na string TCF ainda corresponde aos SSPs e DSPs que usam as APIs Sandbox no seu inventário
- Confirme que a sua política de privacidade descreve Topics, Protected Audience e Attribution Reporting como atividades de processamento distintas, com base legal e retenção
O que o Privacy Sandbox Não Faz
Vários equívocos comuns precisam de morrer antes de você orçar contra eles.
Não É uma Solução Alternativa para o Consentimento
As APIs reduzem os dados pessoais expostos aos anunciantes, mas não tornam o processamento subjacente isento de consentimento ao abrigo da lei europeia. A teoria de conformidade de que a adoção do Sandbox permite ignorar um CMP está errada em todas as jurisdições da EU/EEA.
Não É um Substituto Completo para Cookies Hoje
O Topics fornece um sinal de segmentação grosseiro e com perdas que é tipicamente mais fraco do que as audiências baseadas em cookies. As escalas de retargeting do Protected Audience ainda estão a amadurecer. O Attribution Reporting tem pisos de ruído de medição que podem esconder pequenos aumentos de conversão. Um editor que mova toda a monetização para o Sandbox hoje deve esperar quedas de RPM de 10-30 por cento em relação a uma pilha baseada em cookies em inventário típico.
Não É Permanente na Sua Forma Atual
A especificação do Privacy Sandbox ainda está a evoluir. A taxonomia do Topics está a expandir-se, os limites dos grupos de interesse do Protected Audience estão sob revisão, e a resposta regulatória está em curso. Projete a sua camada de consentimento para ser orientada por configuração, não codificada para a especificação atual.
A Postura Certa para 2026
O Privacy Sandbox é melhor compreendido como uma camada de uma estratégia mais ampla sem cookies, juntamente com dados de primeira parte, audiências definidas pelo vendedor, segmentação contextual e header bidding do lado do servidor. Os editores que vencerem em 2026 serão aqueles que tratam o consentimento como árbitro, não como obstáculo — alimentando as APIs do Sandbox apenas onde a lei e a escolha do utilizador permitem, recuando limpa e consistentemente para o contextual em todo o resto, e medindo os resultados em ambos os caminhos com ferramentas que não assumem identidade.
A pior postura é a de esperar para ver. Os reguladores já estão a escrever a próxima onda de regras — os compromissos do Sandbox da UK Competition and Markets Authority, a orientação contínua do CNIL e as disposições de perfilagem do EU AI Act tocam todas neste terreno. Os editores que integrarem o Privacy Sandbox numa pilha de consentimento devidamente controlada em 2026 estarão preparados para essas regras. Os que o adicionarem como um substituto de cookies de última hora encontrar-se-ão a reescrever sob pressão.