Testez les annonces AdMob sur un VPN sans risquer votre compte

Vous voulez savoir si votre intégration publicitaire survit au réseau que vos utilisateurs ont réellement. Un VPN est le moyen le plus simple de reproduire une sortie distante. L’erreur est de traiter cette expérience comme une expérience de revenus.

Changer le pays de sortie ne crée pas une nouvelle audience et ne transforme pas vos propres appuis en trafic éligible. Cela ne change que le chemin d’une requête.

Exécutez-la donc comme un test de connectivité avec une séquence documentée, et gardez l’inventaire en direct entièrement à l’écart. Les étapes ci-dessous valent la peine d’être répétées à chaque build.

Décidez à quoi sert le test

Deux questions se confondent. La première est de savoir si une requête est servie du tout depuis un chemin réseau donné, ce qui est une question d’intégration et de connectivité. La seconde est ce que les vrais utilisateurs de ce pays gagneraient, ce qui est une question de reporting et de business à laquelle le SDK ne peut pas répondre à votre place.

Seule la première est testable depuis un appareil de développement. Les revenus estimés peuvent aussi changer avant la clôture d’une période de reporting, si bien qu’un chiffre observé pendant une expérience que vous avez vous-même générée n’est ni une preuve de revenus éligibles ni une prévision pour qui que ce soit d’autre.

Écrivez la question avant de vous connecter : par exemple, une requête de bannière renvoie-t-elle un remplissage lorsque l’appareil sort par l’Allemagne sur ce build. Si la réponse que vous voulez est un chiffre de revenus, arrêtez-vous ici, car aucune configuration VPN n’en produit.

Avant le décollage : enregistrez l’appareil, pas l’adresse

La documentation de Google sur les annonces de test propose deux voies prises en charge. Utilisez les unités d’annonce de démonstration pour le format que vous intégrez, ou vos propres unités avec l’appareil physique enregistré comme appareil de test. Les deux sont documentées par plateforme et par génération de SDK, et les guides Next-Gen et Legacy ne sont pas interchangeables.

L’enregistrement est un identifiant d’appareil, et il n’a rien à voir avec l’adresse réseau. Changer l’endroit d’où sort le trafic du téléphone n’enregistre rien. Sur Android, l’identifiant est journalisé par le SDK, et vous l’appliquez dans le code :

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

Confirmez l’enregistrement avant de changer de réseau, sinon vous ne pourrez pas distinguer un remplissage manqué d’une annonce en direct servie à un appareil qui n’a jamais été enregistré. Si l’annonce affiche le libellé Test Ad, la requête est passée par l’inventaire de test ; sinon, vous regardez autre chose et ne devriez pas y toucher.

Exécutez la séquence dans un ordre fixe

Gardez tout constant sauf le réseau. Même build, même unité d’annonce, même emplacement, même état de l’application. Changez deux variables et vous n’apprendrez rien.

D’abord la ligne de base. Avec le VPN déconnecté, chargez l’emplacement et confirmez qu’une annonce de test apparaît. Capturez la requête dans logcat avec adb logcat | grep -i ads et notez le code de réponse. Une absence de remplissage sur la ligne de base n’est pas un problème de VPN.

Puis connectez-vous et répétez. Même build, même unité, même emplacement, VPN activé. Capturez les mêmes lignes de journal. Ce que vous cherchez, c’est une différence : un remplissage qui devient un délai d’attente, une requête qui ne part jamais, un code d’erreur qui change. Un remplissage qui reste un remplissage vous dit que l’intégration est correcte sur ce chemin et que le test est terminé.

Consignez l’environnement. Version du SDK, versions des adaptateurs, type de build, format d’annonce, pays de sortie et résultat observé. Sans cette consignation, la personne suivante refait l’expérience de zéro et aboutit à une conclusion différente à partir des mêmes preuves.

La médiation est un test à part

Les annonces médiées ne portent pas le libellé Test Ad de Google, ce qui en fait l’endroit le plus facile pour cliquer sur quelque chose que vous ne devriez pas. Chaque réseau de la pile de médiation a son propre mode de test et sa propre configuration, et la configuration de test de Google ne s’étend pas à eux.

Vérifiez les adaptateurs un par un, avec le mode de test propre à l’adaptateur activé, et confirmez d’après le journal quel réseau a servi l’annonce. Si vous ne pouvez pas dire quel adaptateur a rempli ni s’il s’agissait d’une création de test, traitez l’impression comme de l’inventaire en direct et laissez-la tranquille.

C’est aussi là que la politique sur le trafic invalide compte. Les auto-clics, les impressions répétées, les interactions automatisées et le trafic trompeur sont tous couverts, et un clic incertain pour voir ce qui se passe est exactement le schéma que ces règles décrivent.

Retour arrière et la porte de publication

La configuration de test ne doit pas être livrée. Avant un build de publication, remplacez les unités d’annonce de démonstration par des unités de production, supprimez la liste des appareils de test et effacez tout indicateur réservé au développement. Recherchez les identifiants de test dans la variante de publication plutôt que de faire confiance à votre mémoire ; une entrée égarée est un échec silencieux qui n’apparaît que comme des revenus manquants.

Vérifiez ensuite la direction inverse : installez le build de publication sur un appareil de test enregistré et confirmez que la requête n’est plus traitée comme du trafic de test. Si le libellé s’affiche encore, quelque chose dans la configuration a survécu.

Conservez ensuite un chemin de test documenté pour que la prochaine question réseau puisse être tranchée sans toucher à l’inventaire en direct. Les annonces de test n’apparaissent jamais dans les rapports de compte, donc une séparation propre ne coûte rien en précision de reporting et vous offre un diagnostic reproductible.