Proba anuncios de AdMob nunha VPN sen arriscar a túa conta

Queres saber se a túa integración de anuncios sobrevive á rede que os teus usuarios teñen de verdade. Unha VPN é o xeito máis sinxelo de reproducir unha saída afastada. O erro é tratar ese experimento como un experimento de ingresos.

Cambiar o país de saída non crea unha audiencia nova nin converte os teus propios toques en tráfico elixible. Só cambia o camiño dunha solicitude.

Así que execútao como unha proba de conectividade cunha secuencia documentada e mantén o inventario en vivo completamente á marxe. Os pasos seguintes paga a pena repetilos en cada compilación.

Decide para que serve a proba

Dúas preguntas confúndense. A primeira é se unha solicitude se atende sequera desde un camiño de rede concreto, o que é unha cuestión de integración e conectividade. A segunda é canto gañarían os usuarios reais dese país, que é unha cuestión de informes e de negocio que o SDK non pode responder por ti.

Só a primeira é comprobable desde un dispositivo de desenvolvemento. As ganancias estimadas tamén poden cambiar antes de que se peche un período de informes, así que unha cifra observada durante un experimento que xeras ti mesmo non é proba de ingresos elixibles nin unha previsión para ninguén máis.

Escribe a pregunta antes de conectarte: por exemplo, devolve un recheo unha solicitude de banner cando o dispositivo sae por Alemaña nesta compilación. Se a resposta que queres é unha cifra de ingresos, detente aquí, porque ningunha configuración de VPN produce unha.

Antes de engalar: rexistra o dispositivo, non o enderezo

A documentación de Google sobre anuncios de proba ofrece dúas rutas admitidas. Usa as unidades de anuncio de demostración para o formato que integras, ou usa as túas propias unidades co dispositivo físico rexistrado como dispositivo de proba. Ambas están documentadas por plataforma e por xeración de SDK, e as guías Next-Gen e Legacy non son intercambiables.

O rexistro é un identificador de dispositivo e non ten nada que ver co enderezo de rede. Cambiar por onde sae o tráfico do teléfono non rexistra nada. En Android o identificador rexístrao o SDK e ti aplícalo no código:

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

Confirma o rexistro antes de cambiar de rede, porque se non non poderás distinguir un recheo fallido dun anuncio en vivo servido a un dispositivo que nunca se rexistrou. Se o anuncio mostra a etiqueta Test Ad, a solicitude pasou polo inventario de proba; se non a mostra, estás vendo outra cousa e non deberías tocala.

Executa a secuencia nunha orde fixa

Mantén todo constante agás a rede. A mesma compilación, a mesma unidade de anuncio, a mesma ubicación, o mesmo estado da app. Cambia dúas variables e non aprenderás nada.

Primeiro a liña base. Coa VPN desconectada, carga a ubicación e confirma que aparece un anuncio de proba. Captura a solicitude en logcat con adb logcat | grep -i ads e anota o código de resposta. Unha falta de recheo na liña base non é un problema de VPN.

Despois conecta e repite. A mesma compilación, a mesma unidade, a mesma ubicación, VPN activada. Captura as mesmas liñas de rexistro. O que buscas é unha diferenza: un recheo que se converte nun tempo de espera, unha solicitude que nunca sae, un código de erro que cambia. Un recheo que segue sendo recheo dinos que a integración está ben nese camiño e que a proba rematou.

Anota a contorna. Versión do SDK, versións dos adaptadores, tipo de compilación, formato do anuncio, país de saída e o resultado observado. Sen ese rexistro, a seguinte persoa repite o experimento desde cero e chega a unha conclusión distinta coas mesmas probas.

A mediación é unha proba aparte

Os anuncios mediados non levan a etiqueta Test Ad de Google, o que os converte no lugar máis doado para facer clic en algo que non deberías. Cada rede da pila de mediación ten o seu propio modo de proba e a súa propia configuración, e a configuración de proba de Google non se estende a elas.

Revisa os adaptadores un a un, co modo de proba propio do adaptador activado, e confirma polo rexistro que rede serviu o anuncio. Se non podes dicir que adaptador encheu nin se era un creativo de proba, trata a impresión como inventario en vivo e déixaa estar.

Aquí tamén importa a política de tráfico non válido. Os autoclics, as impresións repetidas, as interaccións automatizadas e o tráfico enganoso están todos cubertos, e un clic dubidoso para ver que pasa é exactamente o patrón que describen esas regras.

Reversión e a porta do lanzamento

A configuración de proba non debe chegar ao lanzamento. Antes dunha compilación de lanzamento, substitúe as unidades de anuncio de demostración por unidades de produción, elimina a lista de dispositivos de proba e borra calquera indicador só de desenvolvemento. Busca os identificadores de proba na variante de lanzamento en lugar de confiar na memoria; unha entrada perdida é un fallo silencioso que só se ve como ingresos que faltan.

Despois verifica a dirección contraria: instala a compilación de lanzamento nun dispositivo de proba rexistrado e confirma que a solicitude xa non se trata como tráfico de proba. Se aínda mostra a etiqueta, algo da configuración sobreviviu.

Conserva despois un camiño de proba documentado para que a seguinte pregunta de rede se poida responder sen tocar o inventario en vivo. Os anuncios de proba nunca aparecen nos informes da conta, así que unha separación limpa non custa nada en precisión de informes e dache un diagnóstico repetible.