Test AdMob-annonser på en VPN uten å risikere kontoen din

Du vil vite om annonseintegrasjonen din tåler nettverket brukerne dine faktisk har. En VPN er den enkleste måten å gjenskape en fjern utgang. Feilen er å behandle det forsøket som et inntektsforsøk.

Å bytte utgangsland skaper ikke et nytt publikum, og det gjør ikke dine egne trykk til kvalifisert trafikk. Det endrer bare ruten til en forespørsel.

Så kjør det som en tilkoblingstest med en dokumentert sekvens, og hold live-lageret helt utenfor. Trinnene nedenfor er verdt å gjenta i hver build.

Bestem hva testen er for

To spørsmål blandes sammen. Det første er om en forespørsel i det hele tatt betjenes fra en gitt nettverksrute, som er et integrasjons- og tilkoblingsspørsmål. Det andre er hva ekte brukere i det landet ville tjene, som er et rapporterings- og forretningsspørsmål SDK-et ikke kan svare på for deg.

Bare det første kan testes fra en utviklingsenhet. Anslått inntekt kan også endre seg før en rapporteringsperiode avsluttes, så et tall som observeres i et selvlaget forsøk er verken bevis på kvalifisert inntekt eller en prognose for noen andre.

Skriv ned spørsmålet før du kobler til: for eksempel, gir en bannerforespørsel en fylling når enheten går ut gjennom Tyskland i denne builden. Hvis svaret du vil ha er et inntektstall, stopp her, fordi ingen VPN-konfigurasjon produserer ett.

Før avgang: registrer enheten, ikke adressen

Googles dokumentasjon for testannonser tilbyr to støttede ruter. Bruk demo-annonseenhetene for formatet du integrerer, eller dine egne enheter med den fysiske enheten registrert som testenhet. Begge er dokumentert per plattform og per SDK-generasjon, og Next-Gen- og Legacy-veiledningene kan ikke byttes om.

Registrering er en enhetsidentifikator, og den har ingenting med nettverksadressen å gjøre. Å endre hvor telefonens trafikk går ut registrerer ingenting. På Android logges identifikatoren av SDK-et, og du bruker den i koden:

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

Bekreft registreringen før du bytter nettverk, ellers kan du ikke skille en mislykket fylling fra en liveannonse vist til en enhet som aldri ble registrert. Hvis annonsen viser Test Ad-etiketten, gikk forespørselen gjennom testlageret; hvis ikke, ser du på noe annet og bør ikke trykke på det.

Kjør sekvensen i en fast rekkefølge

Hold alt konstant unntatt nettverket. Samme build, samme annonseenhet, samme plassering, samme apptilstand. Endre to variabler, og du lærer ingenting.

Grunnlinje først. Med VPN-en frakoblet laster du plasseringen og bekrefter at en testannonse vises. Fang forespørselen i logcat med adb logcat | grep -i ads og noter responskoden. En manglende fylling på grunnlinjen er ikke et VPN-problem.

Koble deretter til og gjenta. Samme build, samme enhet, samme plassering, VPN på. Fang de samme logglinjene. Det du ser etter, er en forskjell: en fylling som blir en timeout, en forespørsel som aldri går ut, en feilkode som endres. En fylling som forblir en fylling forteller deg at integrasjonen er i orden på den ruten, og at testen er over.

Registrer miljøet. SDK-versjon, adapterversjoner, buildtype, annonseformat, utgangsland og det observerte resultatet. Uten den registreringen gjentar neste person forsøket fra bunnen og kommer til en annen konklusjon fra de samme bevisene.

Mediering er en egen test

Medierte annonser har ikke Googles Test Ad-etikett, noe som gjør dem til det enkleste stedet å klikke på noe du ikke bør. Hvert nettverk i medieringsstakken har sin egen testmodus og sitt eget oppsett, og Googles testkonfigurasjon gjelder ikke for dem.

Kontroller adapterne én om gangen, med adapterens egen testmodus slått på, og bekreft fra loggen hvilket nettverk som viste annonsen. Hvis du ikke kan si hvilken adapter som fylte, og om det var en testkreativ, skal du behandle visningen som live-lager og la den være.

Det er også her retningslinjene for ugyldig trafikk betyr noe. Selvklikk, gjentatte visninger, automatiserte interaksjoner og villedende trafikk er alle dekket, og et usikkert klikk for å se hva som skjer er nøyaktig mønsteret disse reglene beskriver.

Tilbakerulling og utgivelsesporten

Testkonfigurasjon må ikke sendes med. Før en utgivelsesbuild erstatter du demo-annonseenheter med produksjonsenheter, fjerner testenhetslisten og sletter alle flagg som bare er for utvikling. Grep utgivelsesvarianten for testidentifikatorene i stedet for å stole på hukommelsen; en villfaren oppføring er en stille feil som bare vises som manglende inntekt.

Bekreft deretter den andre retningen: installer utgivelsesbuilden på en registrert testenhet og bekreft at forespørselen ikke lenger behandles som testtrafikk. Hvis etiketten fortsatt vises, har noe i konfigurasjonen overlevd.

Behold etterpå én dokumentert testvei, slik at det neste nettverksspørsmålet kan besvares uten å røre live-lageret. Testannonser vises aldri i kontorapporter, så en ren separasjon koster ingenting i rapporteringsnøyaktighet og gir deg en repeterbar diagnose.