Test AdMob-advertenties op een VPN zonder je account te riskeren

Je wilt weten of je advertentie-integratie het netwerk overleeft dat je gebruikers echt hebben. Een VPN is de makkelijkste manier om een verre exit na te bootsen. De fout is dat experiment als een inkomstenexperiment te behandelen.

Het exitland wijzigen creëert geen nieuw publiek en maakt je eigen tikken niet tot in aanmerking komend verkeer. Het verandert alleen het pad van een verzoek.

Voer het dus uit als een connectiviteitstest met een gedocumenteerde volgorde, en houd live-inventaris er volledig buiten. De stappen hieronder zijn het waard om bij elke build te herhalen.

Bepaal waar de test voor dient

Twee vragen raken verward. De eerste is of een verzoek überhaupt wordt bediend vanaf een bepaald netwerkpad, wat een integratie- en connectiviteitsvraag is. De tweede is wat echte gebruikers in dat land zouden verdienen, wat een rapportage- en bedrijfsvraag is die de SDK niet voor je kan beantwoorden.

Alleen de eerste is testbaar vanaf een ontwikkelapparaat. Geschatte inkomsten kunnen ook veranderen voordat een rapportageperiode wordt afgesloten, dus een getal dat tijdens een zelfgemaakt experiment wordt waargenomen is noch bewijs van in aanmerking komende inkomsten noch een voorspelling voor iemand anders.

Schrijf de vraag op voordat je verbindt: bijvoorbeeld, levert een bannerverzoek een vulling op wanneer het apparaat in deze build via Duitsland naar buiten gaat. Als het antwoord dat je wilt een inkomenscijfer is, stop dan hier, want geen enkele VPN-configuratie produceert er een.

Voor vertrek: registreer het apparaat, niet het adres

De documentatie van Google over testadvertenties biedt twee ondersteunde routes. Gebruik de demo-advertentie-eenheden voor het formaat dat je integreert, of je eigen eenheden met het fysieke apparaat geregistreerd als testapparaat. Beide zijn gedocumenteerd per platform en per SDK-generatie, en de Next-Gen- en Legacy-handleidingen zijn niet uitwisselbaar.

Registratie is een apparaatidentificatie en heeft niets met het netwerkadres te maken. Wijzigen waar het verkeer van de telefoon naar buiten gaat, registreert niets. Op Android wordt de identificatie door de SDK gelogd, en pas je die toe in code:

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

Bevestig de registratie voordat je van netwerk wisselt, anders kun je een mislukte vulling niet onderscheiden van een live advertentie die aan een apparaat is geleverd dat nooit was geregistreerd. Als de advertentie het Test Ad-label toont, ging het verzoek via testinventaris; zo niet, dan kijk je naar iets anders en moet je het niet aanraken.

Voer de volgorde in een vaste orde uit

Houd alles constant behalve het netwerk. Dezelfde build, dezelfde advertentie-eenheid, dezelfde plaatsing, dezelfde appstatus. Verander twee variabelen en je leert niets.

Eerst de basislijn. Laad met de VPN losgekoppeld de plaatsing en bevestig dat een testadvertentie verschijnt. Leg het verzoek vast in logcat met adb logcat | grep -i ads en noteer de responscode. Een ontbrekende vulling op de basislijn is geen VPN-probleem.

Verbind daarna en herhaal. Dezelfde build, dezelfde eenheid, dezelfde plaatsing, VPN aan. Leg dezelfde logregels vast. Waar je naar zoekt is een verschil: een vulling die een time-out wordt, een verzoek dat nooit vertrekt, een foutcode die verandert. Een vulling die een vulling blijft vertelt je dat de integratie op dat pad in orde is en de test voorbij is.

Leg de omgeving vast. SDK-versie, adapterversies, buildtype, advertentieformaat, exitland en het waargenomen resultaat. Zonder die vastlegging herhaalt de volgende persoon het experiment vanaf nul en komt tot een andere conclusie uit hetzelfde bewijs.

Mediation is een aparte test

Gemedieerde advertenties dragen niet het Test Ad-label van Google, waardoor ze de makkelijkste plek zijn om op iets te klikken dat je niet zou moeten. Elk netwerk in de mediation-stack heeft zijn eigen testmodus en zijn eigen configuratie, en de testconfiguratie van Google strekt zich niet tot hen uit.

Controleer de adapters één voor één, met de eigen testmodus van de adapter ingeschakeld, en bevestig uit de log welk netwerk de advertentie heeft geserveerd. Als je niet kunt zeggen welke adapter vulde en of het een testcreatief was, behandel de vertoning dan als live-inventaris en laat hem met rust.

Hier telt ook het beleid voor ongeldig verkeer. Zelfklikken, herhaalde vertoningen, geautomatiseerde interacties en misleidend verkeer vallen er allemaal onder, en een onzekere klik om te zien wat er gebeurt is precies het patroon dat die regels beschrijven.

Rollback en de release-poort

Testconfiguratie mag niet meegaan in de release. Vervang vóór een release-build de demo-advertentie-eenheden door productie-eenheden, verwijder de lijst met testapparaten en schrap alle vlaggen die alleen voor ontwikkeling zijn. Grep de release-variant op de testidentificaties in plaats van op je geheugen te vertrouwen; een verdwaalde vermelding is een stille fout die alleen zichtbaar wordt als ontbrekende inkomsten.

Controleer daarna de andere richting: installeer de release-build op een geregistreerd testapparaat en bevestig dat het verzoek niet langer als testverkeer wordt behandeld. Als het label nog steeds verschijnt, heeft iets in de configuratie het overleefd.

Houd daarna één gedocumenteerd testpad aan, zodat de volgende netwerkvraag kan worden beantwoord zonder live-inventaris aan te raken. Testadvertenties verschijnen nooit in accountrapporten, dus een schone scheiding kost niets aan rapportagenauwkeurigheid en levert je een herhaalbare diagnose op.