O problema do banner duplo

Muitos apps são em parte nativos e em parte web. Um jogo mostra sua loja, notícias ou páginas de ajuda em uma WebView; um app utilitário renderiza artigos do seu site; um app híbrido envolve a maior parte da interface em conteúdo web. Cada lado tem seu próprio mecanismo de consentimento: o app nativo usa um CMP ou SDK integrado, e as páginas web carregam um CMP web. Se não estiverem conectados, o usuário é consultado duas vezes, as escolhas feitas em um lugar são ignoradas no outro e as requisições de anúncios de dentro da WebView saem com os sinais errados.

Este guia mostra como fazer o consentimento nativo e o web concordarem, para que os usuários respondam uma vez e cada requisição de anúncio leve a mesma decisão.

Onde cada lado armazena o consentimento

Nativo

O IAB TCF especifica como um CMP dentro do app armazena o consentimento: em NSUserDefaults no iOS e em SharedPreferences no Android, usando chaves padrão como IABTCF_TCString, IABTCF_gdprApplies e IABTCF_PurposeConsents. Os SDKs de anúncios leem essas chaves diretamente. O IAB GPP define chaves semelhantes com o prefixo IABGPP_, como IABGPP_HDR_GppString.

Web

Um CMP web normalmente armazena sua decisão em cookies próprios ou no armazenamento local do domínio do site e a expõe por meio das funções JavaScript __tcfapi e __gpp. As tags de anúncios na página chamam essas funções, não o armazenamento nativo.

A lacuna

As WebViews têm seu próprio espaço de cookies e armazenamento, separado do navegador do dispositivo e das preferências nativas do app. No iOS, uma WKWebView que usa um data store não persistente esquece tudo quando é fechada. Nada flui entre os dois lados a menos que você construa isso.

Escolha uma única fonte da verdade

A primeira decisão é qual lado é dono do consentimento. Para a maioria dos apps, a resposta é o CMP nativo, porque:

• Ele roda primeiro, antes de qualquer WebView ser aberta.
• Os SDKs de anúncios nativos, que geralmente geram a maior parte da receita, leem o armazenamento nativo.
• No iOS, ele pode ser coordenado com o aviso do App Tracking Transparency.

Começar pela web pode fazer sentido para apps híbridos cuja interface inteira é conteúdo web, mas então você precisa gravar a decisão de volta no armazenamento nativo para os SDKs nativos.

Passando o consentimento nativo para a WebView

Com o nativo como fonte da verdade, a WebView precisa ver a mesma decisão. Padrões comuns:

1. Injetar uma implementação de __tcfapi. Antes de os scripts da página rodarem, injete um pequeno script que define __tcfapi (e __gpp, se necessário) e responde às chamadas com a string TC e os valores lidos do armazenamento nativo. As tags de anúncios na página obtêm então a decisão nativa pela API padrão.
2. Suprimir o banner web. Configure o CMP web para permanecer oculto quando a página é carregada dentro do seu app, por exemplo com base em um parâmetro de consulta ou em um token de user agent personalizado que você controla. Caso contrário, o usuário vê um segundo banner.
3. Passar a string no carregamento. Alguns CMPs web aceitam uma string de consentimento existente na inicialização e a adotam. Consulte a documentação do seu CMP web para ver os métodos compatíveis.

Qualquer que seja o padrão, garanta que os valores injetados sejam atualizados quando o usuário mudar a escolha na tela de configurações nativa, e não apenas na próxima abertura do app.

Devolvendo o consentimento web ao nativo

Se os usuários podem alterar o consentimento dentro da WebView, por exemplo por meio de uma página de configurações de privacidade, o app precisa ficar sabendo. Use uma ponte JavaScript: um manipulador de mensagens no iOS ou uma interface JavaScript no Android. O lado web escuta com __tcfapi('addEventListener', ...) e envia a nova string ao código nativo, que grava as chaves padrão. Valide a entrada vinda da WebView antes de gravá-la; aceite apenas mensagens do seu próprio conteúdo.

Anúncios dentro de WebViews

Os anúncios renderizados em uma WebView são anúncios web. Eles leem o consentimento da página, não do armazenamento nativo, a menos que o SDK de anúncios ofereça uma forma de vincular os dois. O Mobile Ads SDK do Google, por exemplo, oferece uma API para registrar WebViews de modo que os anúncios dentro delas possam usar sinais do app; consulte a documentação atual do seu SDK. De qualquer modo, confirme com um teste que as requisições de anúncios da WebView levam a mesma string TC ou GPP que as requisições de anúncios nativas.

Checklist de testes

• Instalação nova: um único aviso de consentimento, não dois.
• Rejeite tudo no CMP nativo, abra uma WebView, inspecione as requisições de anúncios: a string deve refletir a rejeição.
• Mude o consentimento nas configurações nativas, volte a uma WebView aberta: a página deve ver a nova decisão.
• Se existirem configurações web, mude o consentimento nelas e confirme que as chaves nativas são atualizadas.
• Encerre e reabra o app: as decisões persistem nos dois lados.
• Teste no iOS e no Android, pois o armazenamento da WebView se comporta de forma diferente em cada um.

Principais conclusões

• O consentimento nativo e o da WebView ficam em armazenamentos separados e não se sincronizam por padrão.
• Escolha uma fonte da verdade; para a maioria dos apps, é o CMP nativo.
• Exponha o consentimento nativo ao conteúdo web por meio de um __tcfapi ou __gpp injetado e oculte o banner web.
• Use uma ponte JavaScript para enviar as mudanças feitas na web de volta ao armazenamento nativo.
• Verifique se as requisições de anúncios das WebViews levam a mesma string de consentimento que as nativas.