Teste anúncios do AdMob numa VPN sem arriscar a sua conta

Quer saber se a sua integração de anúncios sobrevive à rede que os seus utilizadores têm realmente. Uma VPN é a forma mais fácil de reproduzir uma saída distante. O erro é tratar essa experiência como uma experiência de receita.

Mudar o país de saída não cria uma nova audiência nem transforma os seus próprios toques em tráfego elegível. Apenas muda o caminho de um pedido.

Por isso, execute-o como um teste de conectividade com uma sequência documentada, e mantenha o inventário ativo completamente de fora. Os passos abaixo valem a pena repetir em cada build.

Decida para que serve o teste

Duas perguntas confundem-se. A primeira é se um pedido chega a ser servido a partir de um determinado caminho de rede, o que é uma questão de integração e conectividade. A segunda é quanto ganhariam os utilizadores reais desse país, o que é uma questão de relatórios e de negócio que o SDK não pode responder por si.

Apenas a primeira é testável a partir de um dispositivo de desenvolvimento. Os ganhos estimados também podem mudar antes de um período de relatórios ser encerrado, pelo que um número observado durante uma experiência que gerou você mesmo não é prova de receita elegível nem uma previsão para mais ninguém.

Escreva a pergunta antes de se ligar: por exemplo, um pedido de banner devolve um preenchimento quando o dispositivo sai pela Alemanha nesta build. Se a resposta que quer é um número de receita, pare aqui, porque nenhuma configuração de VPN produz um.

Antes da descolagem: registe o dispositivo, não o endereço

A documentação da Google sobre anúncios de teste oferece duas vias suportadas. Utilize as unidades de anúncio de demonstração para o formato que está a integrar, ou as suas próprias unidades com o dispositivo físico registado como dispositivo de teste. Ambas estão documentadas por plataforma e por geração de SDK, e os guias Next-Gen e Legacy não são intercambiáveis.

O registo é um identificador de dispositivo e não tem nada a ver com o endereço de rede. Mudar por onde sai o tráfego do telemóvel não regista nada. No Android o identificador é registado pelo SDK, e você aplica-o no código:

RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))

Confirme o registo antes de mudar de rede, caso contrário não consegue distinguir um preenchimento falhado de um anúncio ativo servido a um dispositivo que nunca foi registado. Se o anúncio mostrar a etiqueta Test Ad, o pedido passou pelo inventário de teste; se não mostrar, está a ver outra coisa e não o deve tocar.

Execute a sequência numa ordem fixa

Mantenha tudo constante exceto a rede. O mesmo build, a mesma unidade de anúncio, o mesmo posicionamento, o mesmo estado da aplicação. Mude duas variáveis e não aprende nada.

Primeiro a linha de base. Com a VPN desligada, carregue o posicionamento e confirme que aparece um anúncio de teste. Capture o pedido no logcat com adb logcat | grep -i ads e registe o código de resposta. Uma falta de preenchimento na linha de base não é um problema de VPN.

Depois ligue e repita. O mesmo build, a mesma unidade, o mesmo posicionamento, VPN ligada. Capture as mesmas linhas de registo. O que procura é uma diferença: um preenchimento que se torna num tempo limite, um pedido que nunca sai, um código de erro que muda. Um preenchimento que continua a ser preenchimento diz-lhe que a integração está bem nesse caminho e que o teste terminou.

Registe o ambiente. Versão do SDK, versões dos adaptadores, tipo de build, formato do anúncio, país de saída e o resultado observado. Sem esse registo, a pessoa seguinte repete a experiência de zero e chega a uma conclusão diferente com as mesmas provas.

A mediação é um teste à parte

Os anúncios mediados não têm a etiqueta Test Ad da Google, o que os torna o local mais fácil para clicar em algo que não devia. Cada rede da pilha de mediação tem o seu próprio modo de teste e a sua própria configuração, e a configuração de teste da Google não se estende a elas.

Verifique os adaptadores um a um, com o modo de teste próprio do adaptador ativo, e confirme pelo registo qual rede serviu o anúncio. Se não conseguir dizer qual adaptador preencheu e se era um criativo de teste, trate a impressão como inventário ativo e deixe-a em paz.

É também aqui que a política de tráfego inválido importa. Autoclics, impressões repetidas, interações automatizadas e tráfego enganoso estão todos abrangidos, e um clique incerto para ver o que acontece é exatamente o padrão que essas regras descrevem.

Reversão e a porta do lançamento

A configuração de teste não pode ser lançada. Antes de um build de lançamento, substitua as unidades de anúncio de demonstração por unidades de produção, remova a lista de dispositivos de teste e apague quaisquer sinalizadores apenas de desenvolvimento. Procure os identificadores de teste na variante de lançamento em vez de confiar na memória; uma entrada perdida é uma falha silenciosa que só aparece como receita em falta.

Depois verifique a direção contrária: instale o build de lançamento num dispositivo de teste registado e confirme que o pedido já não é tratado como tráfego de teste. Se ainda mostrar a etiqueta, algo na configuração sobreviveu.

Mantenha depois um caminho de teste documentado para que a próxima pergunta de rede possa ser respondida sem tocar no inventário ativo. Os anúncios de teste nunca aparecem nos relatórios da conta, pelo que uma separação limpa não custa nada em exatidão dos relatórios e dá-lhe um diagnóstico repetível.