AdMob UMP em React Native: mensagens de privacidade não são só painel

Privacidade no AdMob parece trabalho de painel até a primeira build candidata contar outra história.

Você cria o app no AdMob, adiciona blocos, publica GDPR, vincula à Play — e ainda assim a build pode não estar pronta para pedir anúncios. O que falta quase nunca é opção escondida no console. É o contrato entre o AdMob, o SDK da User Messaging Platform e o ponto do startup em que o app decide se pode fazer requests.

Este artigo vem do release Android do Daily Sudoku: Offline Puzzle, Expo/React Native com react-native-google-mobile-ads. Os detalhes são do Sudoku; o modo de falha é comum: ad unit IDs reais e app bloqueado, limitado ou incompleto em privacidade porque mensagem virou papelada em vez de comportamento de runtime.

Não é aconselhamento jurídico. É engenharia: onde essa decisão acontece no app.

Os três sistemas envolvidos

Há três sistemas separados. Quando viram um único “AdMob configurado”, a correção vai pro lugar errado.

Cadastro do app no AdMob — App ID Android, blocos, vínculo com a Play, revisão de veiculação. Pendente aqui, o console mostra preparação, revisão ou veiculação limitada. Não é bug de SDK.

Privacidade e mensagens — GDPR, regulamentos estaduais dos EUA e outras superfícies, por app e região. Publicar significa que o AdMob tem mensagem disponível. Não significa que qualquer build vai mostrá-la sozinha.

Runtime do app — No React Native, o Google Mobile Ads SDK via react-native-google-mobile-ads. Esse código pede consentimento à UMP, mostra formulários quando precisa e bloqueia ou libera requests conforme o resultado.

Console define o que pode ser mostrado; o app decide quando pode pedir anúncios.

O que o release precisava provar

No Sudoku, o setup de release só ficou confiável quando estas validações estavam verdadeiras ao mesmo tempo:

• O package Android na Google Play era com.sunstoneapps.dailysudoku.
• O app no AdMob usava o App ID Android de produção, não o App ID público de teste do Google.
• Banner, interstitial e rewarded tinham ad unit IDs de produção.
• O app-ads.txt estava publicado no domínio público do app.
• A ficha da Play Store foi vinculada no AdMob depois de ficar visível.
• A mensagem GDPR estava publicada para o app Android.
• A mensagem dos regulamentos estaduais dos EUA estava publicada para o app Android.
• O app nativo chamava UMP antes do primeiro request de anúncio.
• O app desativava anúncios quando a UMP dizia que requests não estavam liberados.

Cada linha pega uma classe diferente de falha. Vínculo ausente com a Play deixa revisão pendente. Mensagem ausente faz a UMP dizer que não há formulário. Gate de runtime ausente deixa o app pedir anúncio antes de saber o consentimento. App ID nativo errado é o pior: JavaScript perfeito, manifesto apontando para app de teste.

Por isso validação de release olha config e saída nativa gerada. Ad unit ID em JS não é configuração AdMob inteira.

GDPR publicado não é linha de chegada

A mensagem europeia costuma ser a primeira que desenvolvedores mobile lembram. No AdMob, ela aparece em Privacidade e mensagens como o fluxo de regulamentações europeias. Para um app pequeno, a mensagem gerenciada pelo Google costuma ser suficiente para começar: ela pede consentimento, oferece opções de privacidade e permite recusa.

Mas o status no console só diz que o AdMob tem uma mensagem pronta. O app ainda precisa:

1. chamar UMP no startup ou antes do primeiro request de anúncio;
2. ler se anúncios podem ser solicitados;
3. evitar inicializar ou solicitar anúncios quando o resultado diz não;
4. oferecer um caminho para reabrir opções de privacidade quando necessário.

No Sudoku, o comportamento importante não é existir um texto chamado “Opções de privacidade dos anúncios” em configurações. O comportamento importante é a implementação nativa chamar AdsConsent.gatherConsent(), depois ler AdsConsent.getConsentInfo() e transformar esse resultado em um estado pequeno:

type AdsPrivacyState = {
  canRequestAds: boolean;
  privacyOptionsRequired: boolean;
};

Esse estado alimenta a configuração de anúncios do app. Se canRequestAds vem falso, o app troca para uma configuração de ads desativados. Isso mantém o restante do jogo simples. Telas e placements não precisam conhecer todos os detalhes da UMP. Elas só precisam saber se anúncios estão disponíveis.

Esse controle vale mais do que checks defensivos espalhados por cada banner ou rewarded.

A mensagem dos EUA tem outro trabalho

A mensagem de regulamentos estaduais dos EUA não é um segundo formulário GDPR. Ela responde a outro requisito: usuários em estados compatíveis dos EUA podem recusar a venda ou o compartilhamento de informações pessoais. No AdMob, o fluxo atual permite segmentar todos os estados aceitos hoje e no futuro.

Para um app Android global disponível nos Estados Unidos, criar essa mensagem é uma decisão conservadora de compliance. Não é um recurso de monetização. Ela não aumenta eCPM por si só. Em usuários que recusarem, pode inclusive reduzir o valor de anúncios personalizados.

O benefício não é eCPM. É ter caminho explícito para honrar escolhas de privacidade onde a lei exige — melhor do que config incompleta e torcer pro SDK interpretar o vazio certo.

No caso do Sudoku, a mensagem publicada ficou assim:

• nome da mensagem: Daily Sudoku - US States Privacy - Android;
• app: Daily Sudoku: Offline Puzzle;
• idioma: en-US;
• geografia: todos os estados dos EUA aceitos atualmente e no futuro;
• status: publicada.

O próprio console avisou que o SDK da UMP precisa estar integrado no app e que a propagação pode levar até uma hora. Esse aviso parece burocrático, mas é o ponto central: a mensagem só tem efeito quando o app usa o SDK.

Vínculo com a loja e revisão do AdMob

Vincular a ficha da Play Store ao app no AdMob é outro passo separado. Ele só funciona quando a ficha já está suficientemente encontrável para o AdMob localizar por package ou URL. Antes disso, o AdMob pode mostrar que a loja não está vinculada, mesmo quando blocos de anúncio existem e já há algum tráfego chegando à conta.

Depois do vínculo, o AdMob revisa o app para decidir se ele está pronto para veicular anúncios normalmente. O console pode dizer que a revisão costuma levar de dois a três dias e que a veiculação fica limitada até a conclusão.

Esse estado limitado não deve ser depurado como se fosse bug de layout em React Native. É um estado externo de revisão. A ação correta é confirmar que o app está vinculado, as mensagens de privacidade estão publicadas, a Central de políticas não tem bloqueios e o app não trava gameplay quando anúncios estão indisponíveis.

Para um jogo, essa distinção importa. Um resultado no-fill, uma revisão pendente e um estado em que UMP exige consentimento levam ao mesmo sintoma para o jogador: nenhum anúncio aparece. Eles não têm a mesma causa.

Anúncios não personalizados são escolha de produto

Um detalhe sutil nesse setup: o app pode pedir apenas anúncios não personalizados, mesmo depois de consentimento. Essa é uma decisão válida quando o time quer uma postura de privacidade mais simples, mas ela não é neutra para monetização.

Em react-native-google-mobile-ads, os requests podem passar:

requestNonPersonalizedAdsOnly: true;

Isso mantém o request conservador. Também significa que o app não deve esperar o mesmo perfil de monetização de uma configuração que pede anúncios personalizados onde permitido. Configuração de privacidade e estratégia de receita estão conectadas. Um formulário de consentimento não melhora receita automaticamente; ele cria as condições para o app fazer requests compatíveis.

Se o objetivo é melhorar receita, o próximo trabalho não é “criar mais mensagens”. É decidir se anúncios personalizados serão permitidos em algumas regiões, como essa escolha aparece no app e como a telemetria separa no-fill, consentimento recusado, request desativado e revisão limitada.

Um checklist que pega falhas reais

Para um app Android Expo/React Native usando AdMob, o checklist útil é:

1. Confirmar o App ID Android de produção do AdMob na configuração nativa.
2. Confirmar todos os ad unit IDs de produção no ambiente/config do app.
3. Confirmar app-ads.txt publicado no domínio usado pela ficha da Play.
4. Vincular a ficha da Play Store no AdMob depois que ela ficar encontrável.
5. Publicar a mensagem GDPR para o app Android.
6. Publicar a mensagem dos estados dos EUA se o app atende usuários nos Estados Unidos.
7. Chamar UMP antes do primeiro request de anúncio.
8. Controlar o provider de ads com canRequestAds.
9. Expor opções de privacidade em configurações quando o SDK disser que são necessárias.
10. Tratar no-fill como falta de inventário, salvo quando logs mostrarem erro de integração.
11. Validar em uma build de release real, não só em debug local. (Escrevemos sobre por que __DEV__ é false em builds de release e como gatear ferramentas de dev por config — a mesma lição vale para os diálogos de consentimento do UMP.)

Esse checklist separa console, código e runtime de propósito. Corrigir só o painel sem mudar o gate do app é a armadilha mais comum.

O caminho simples é o que aguenta release

A implementação que aguenta release não é esperta. É um estado pequeno de privacidade, uma chamada no startup, uma entrada em configurações e um controle na configuração de anúncios.

Esse formato simples é o que torna o comportamento testável. O app pode simular canRequestAds: false e verificar que anúncios ficam desativados. Pode simular opções de privacidade necessárias e verificar que a tela de configurações mostra o botão de gerenciamento. Pode manter a lógica de recompensa separada para que um rewarded falho ou cancelado nunca conceda benefício de gameplay.

O console do AdMob ainda terá esperas: revisão em dias, mensagem nova em até uma hora, no-fill em request real. Nada disso deve travar partida nem fazer o time tratar revisão pendente como bug de layout.

Mensagem publicada no AdMob só vale quando o app executa o contrato — política, plataforma e runtime no mesmo fluxo.