Du vil vite om annonseintegreringa di toler nettverket brukarane dine faktisk har. Eit VPN er den enklaste måten å gjenskape ein fjern utgang. Feilen er å handsame det forsøket som eit inntektsforsøk.

Å byte utgangsland skaper ikkje eit nytt publikum, og det gjer ikkje dine eigne trykk til kvalifisert trafikk. Det endrar berre ruta til ein førespurnad.

Så køyr det som ein tilkoplingsstest med ein dokumentert sekvens, og hald live-lageret heilt utanfor. Stega nedanfor er verd å gjenta i kvar build.

Bestem kva testen er for

To spørsmål blir blanda saman. Det første er om ein førespurnad i det heile blir betent frå ei gjeven nettverksrute, som er eit integrerings- og tilkoplingstema. Det andre er kva ekte brukarar i det landet ville tene, som er eit rapporterings- og forretningsspørsmål SDK-et ikkje kan svare på for deg.

Berre det første kan testast frå ei utviklingseining. Anslått inntekt kan òg endre seg før ein rapporteringsperiode blir avslutta, så eit tal som blir observert i eit sjølvlagd forsøk er korkje prov på kvalifisert inntekt eller ein prognose for nokon andre.

Skriv ned spørsmålet før du koplar til: til dømes, gir ein bannerførespurnad ei fylling når eininga går ut gjennom Tyskland i denne builden. Viss svaret du vil ha er eit inntektstal, stopp her, fordi ingen VPN-konfigurasjon produserer eitt.

Før avgang: registrer eininga, ikkje adressa

Dokumentasjonen til Google om testannonsar tilbyr to støtta ruter. Bruk demo-annonseiningane for formatet du integrerer, eller dine eigne einingar med den fysiske eininga registrert som testeing. Begge er dokumenterte per plattform og per SDK-generasjon, og Next-Gen- og Legacy-rettleiingane kan ikkje bytast om.

Registrering er ein einingidentifikator, og han har ingenting med nettverksadressa å gjere. Å endre kvar trafikken til telefonen går ut registrerer ingenting. På Android blir identifikatoren logga av SDK-et, og du brukar han i koden:

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

Stadfest registreringa før du byter nettverk, elles kan du ikkje skilje ei mislukka fylling frå ein liveannonse vist til ei eining som aldri blei registrert. Viss annonsen viser Test Ad-etiketten, gjekk førespurnaden gjennom testlageret; viss ikkje, ser du på noko anna og bør ikkje trykkje på det.

Køyr sekvensen i ein fast rekkjefølgje

Hald alt konstant unntatt nettverket. Same build, same annonseining, same plassering, same apptilstand. Endre to variablar, og du lærer ingenting.

Grunnlinje først. Med VPN-et fråkopla lastar du plasseringa og stadfestar at ein testannonse viser seg. Fang førespurnaden i logcat med adb logcat | grep -i ads og noter responskoden. Ei manglande fylling på grunnlinja er ikkje eit VPN-problem.

Kopla så til og gjenta. Same build, same eining, same plassering, VPN på. Fang dei same logglinjene. Det du ser etter, er ein skilnad: ei fylling som blir ein timeout, ein førespurnad som aldri går ut, ein feilkode som endrar seg. Ei fylling som blir verande fylling fortel deg at integreringa er i orden på den ruta, og at testen er over.

Registrer miljøet. SDK-versjon, adapterversjonar, buildtype, annonseformat, utgangsland og det observerte resultatet. Utan den registreringa gjer neste person forsøket på nytt frå botnen og kjem til ei anna konklusjon ut frå dei same prova.

Mediering er ein eigen test

Medierte annonsar har ikkje Test Ad-etiketten til Google, noko som gjer dei til den enklaste staden å klikke på noko du ikkje bør. Kvart nettverk i medieringsstakken har sin eigen testmodus og sitt eige oppsett, og testkonfigurasjonen til Google gjeld ikkje for dei.

Kontroller adapterane éin om gongen, med eigen testmodus for adapteren slått på, og stadfest frå loggen kva nettverk som viste annonsen. Viss du ikkje kan seie kva adapter som fylte, og om det var ein testkreativ, skal du handsame visninga som live-lager og la ho vere.

Det er òg her retningslinjene for ugyldig trafikk tel. Sjølvklikk, gjentekne visningar, automatiserte interaksjonar og villedande trafikk er alle dekte, og ein usikker klikk for å sjå kva som skjer er nøyaktig mønsteret desse reglane skildrar.

Tilbakerulling og utgivingsporten

Testkonfigurasjon må ikkje sendast med. Før ein utgivingsbuild byter du ut demo-annonseiningar med produksjonseiningar, fjernar testeiningslista og slettar alle flagg som berre er for utvikling. Grep utgivingsvarianten for testidentifikatorane i staden for å stole på minnet; ein villfaren oppføring er ein stille feil som berre viser seg som manglande inntekt.

Stadfest deretter den andre retninga: installer utgivingsbuilden på ei registrert testeing og stadfest at førespurnaden ikkje lenger blir handsama som testtrafikk. Viss etiketten framleis blir vist, har noko i konfigurasjonen overlevd.

Hald etterpå éin dokumentert testveg, slik at det neste nettverksspørsmålet kan svarast på utan å røre live-lageret. Testannonsar viser seg aldri i kontorapportar, så ein rein separasjon kostar ingenting i rapporteringsnøyaktigheit og gir deg ein repeterbar diagnose.

Relaterte artiklar