Test AdMob-annoncer på en VPN uden at risikere din konto

Du vil vide, om din annonceintegration overlever det netværk, dine brugere faktisk har. En VPN er den nemmeste måde at genskabe en fjern udgang. Fejlen er at behandle det forsøg som et indtægtsforsøg.

At skifte udgangsland skaber ikke et nyt publikum, og det gør ikke dine egne tryk til kvalificeret trafik. Det ændrer kun ruten for en anmodning.

Så kør det som en forbindelsestest med en dokumenteret sekvens, og hold live-lageret helt udenfor. Trinene nedenfor er værd at gentage ved hver build.

Beslut, hvad testen skal bruges til

To spørgsmål bliver blandet sammen. Det første er, om en anmodning overhovedet bliver betjent fra en given netværksrute, hvilket er et integrations- og forbindelsesspørgsmål. Det andet er, hvad rigtige brugere i det land ville tjene, hvilket er et rapporterings- og forretningsspørgsmål, som SDK’et ikke kan besvare for dig.

Kun det første kan testes fra en udviklingsenhed. Anslået indtjening kan også ændre sig, før en rapporteringsperiode afsluttes, så et tal observeret under et selvfremstillet forsøg er hverken bevis på kvalificeret indtægt eller en prognose for nogen andre.

Skriv spørgsmålet ned, før du opretter forbindelse: for eksempel, returnerer en banneranmodning en filling, når enheden forlader gennem Tyskland i denne build. Hvis det svar, du vil have, er et indtægtstal, så stop her, fordi ingen VPN-konfiguration frembringer et.

Før afgang: registrér enheden, ikke adressen

Googles dokumentation for testannoncer tilbyder to understøttede veje. Brug demo-annonceenhederne til det format, du integrerer, eller brug dine egne enheder med den fysiske enhed registreret som testenhed. Begge er dokumenteret for hver platform og hver SDK-generation, og Next-Gen- og Legacy-guiderne kan ikke udskiftes.

Registrering er en enhedsidentifikator, og den har intet at gøre med netværksadressen. At ændre, hvor telefonens trafik går ud, registrerer ingenting. På Android logges identifikatoren af SDK’et, og du anvender den i kode:

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

Bekræft registreringen, før du skifter netværk, ellers kan du ikke skelne en mislykket filling fra en liveannonce vist til en enhed, der aldrig blev registreret. Hvis annoncen viser Test Ad-etiketten, gik anmodningen gennem testlageret; hvis ikke, kigger du på noget andet og bør ikke trykke på det.

Kør sekvensen i en fast rækkefølge

Hold alt konstant undtagen netværket. Samme build, samme annonceenhed, samme placering, samme apptilstand. Ændr to variabler, og du lærer intet.

Baseline først. Med VPN’en afbrudt indlæses placeringen, og du bekræfter, at en testannonce vises. Fang anmodningen i logcat med adb logcat | grep -i ads og notér svarkoden. En manglende filling på baseline er ikke et VPN-problem.

Forbind derefter og gentag. Samme build, samme enhed, samme placering, VPN til. Fang de samme loglinjer. Det, du leder efter, er en forskel: en filling, der bliver til en timeout, en anmodning, der aldrig forlader enheden, en fejlkode, der ændrer sig. En filling, der forbliver en filling, fortæller dig, at integrationen er fin på den rute, og at testen er slut.

Registrér miljøet. SDK-version, adapterversioner, buildtype, annonceformat, udgangsland og det observerede resultat. Uden den registrering gentager den næste person forsøget fra bunden og når en anden konklusion ud fra de samme beviser.

Mediering er en separat test

Medierede annoncer bærer ikke Googles Test Ad-etiket, hvilket gør dem til det nemmeste sted at klikke på noget, du ikke bør. Hvert netværk i medieringsstakken har sin egen testtilstand og sin egen opsætning, og Googles testkonfiguration gælder ikke for dem.

Kontrollér adapterne én ad gangen med adapterens egen testtilstand slået til, og bekræft ud fra loggen, hvilket netværk der viste annoncen. Hvis du ikke kan afgøre, hvilken adapter der fyldte, og om det var en testkreativ, skal du behandle impressionen som live-lager og lade den være.

Det er også her, politikken for ugyldig trafik er vigtig. Selvklik, gentagne impressions, automatiserede interaktioner og vildledende trafik er alle omfattet, og et usikkert klik for at se, hvad der sker, er præcis det mønster, som disse regler beskriver.

Tilbagerulning og udgivelsesporten

Testkonfiguration må ikke komme med i udgivelsen. Før en udgivelsesbuild skal du erstatte demo-annonceenheder med produktionsenheder, fjerne testenhedslisten og slette alle flag, der kun er til udvikling. Grep udgivelsesvarianten for testidentifikatorerne i stedet for at stole på hukommelsen; en vildfaren post er en tavs fejl, der kun viser sig som manglende indtægt.

Bekræft derefter den anden retning: installér udgivelsesbuilden på en registreret testenhed, og bekræft, at anmodningen ikke længere behandles som testtrafik. Hvis etiketten stadig vises, har noget i konfigurationen overlevet.

Behold bagefter én dokumenteret testvej, så det næste netværksspørgsmål kan besvares uden at røre live-lageret. Testannoncer vises aldrig i kontorapporter, så en ren adskillelse koster intet i rapporteringsnøjagtighed og giver dig en gentagelig diagnose.