Doni të dini nëse integrimi juaj i reklamave i reziston rrjetit që përdoruesit tuaj kanë në të vërtetë. Një VPN është mënyra më e lehtë për të riprodhuar një dalje të largët. Gabimi është ta trajtoni atë eksperiment si eksperiment të ardhurash.

Ndryshimi i vendit të daljes nuk krijon audiencë të re dhe nuk i kthen prekjet tuaja në trafik të kualifikuar. Ndryshon vetëm rrugën e një kërkese.

Prandaj kryejeni si test lidhshmërie me një sekuencë të dokumentuar dhe mbani inventarin e drejtpërdrejtë plotësisht jashtë tij. Hapat më poshtë ia vlen të përsëriten në çdo build.

Vendosni për çfarë është testi

Dy pyetje ngatërrohen. E para është nëse një kërkesë shërbehet fare nga një rrugë e caktuar rrjeti, që është çështje integrimi dhe lidhshmërie. E dyta është sa do të fitonin përdoruesit e vërtetë në atë vend, që është çështje raportimi dhe biznesi të cilës SDK nuk mund t'i përgjigjet në vendin tuaj.

Vetëm e para është e testueshme nga një pajisje zhvillimi. Të ardhurat e vlerësuara mund të ndryshojnë edhe përpara se të mbyllet një periudhë raportimi, kështu që një numër i vëzhguar gjatë një eksperimenti që e keni krijuar vetë nuk është as provë e të ardhurave të kualifikuara as parashikim për askënd tjetër.

Shkruajeni pyetjen përpara se të lidheni: për shembull, a kthen një kërkesë banner një mbushje kur pajisja del përmes Gjermanisë në këtë build. Nëse përgjigjja që doni është një shifër të ardhurash, ndaloni këtu, sepse asnjë konfigurim VPN nuk prodhon një të tillë.

Para ngritjes: regjistroni pajisjen, jo adresën

Dokumentacioni i Google për reklamat e provës ofron dy rrugë të mbështetura. Përdorni njësitë demo të reklamave për formatin që po integroni, ose njësitë tuaja me pajisjen fizike të regjistruar si pajisje prove. Të dyja janë të dokumentuara për çdo platformë dhe çdo gjeneratë SDK, dhe udhëzuesit Next-Gen dhe Legacy nuk janë të këmbyeshëm.

Regjistrimi është një identifikues pajisjeje dhe nuk ka lidhje me adresën e rrjetit. Ndryshimi i vendit nga ku del trafiku i telefonit nuk regjistron asgjë. Në Android identifikuesin e regjistron SDK dhe ju e zbatoni në kod:

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

Konfirmoni regjistrimin përpara se të ndryshoni rrjetin, përndryshe nuk mund të dalloni një mbushje të dështuar nga një reklamë e drejtpërdrejtë e shërbyer një pajisjeje që nuk u regjistrua kurrë. Nëse reklama shfaq etiketën Test Ad, kërkesa kaloi përmes inventarit të provës; nëse jo, po shikoni diçka tjetër dhe nuk duhet ta prekni.

Kryejeni sekuencën në një rend fiks

Mbani gjithçka konstante përveç rrjetit. I njëjti build, e njëjta njësi reklame, i njëjti vendosje, i njëjti gjendje aplikacioni. Ndryshoni dy variabla dhe nuk mësoni asgjë.

Së pari vija bazë. Me VPN të shkëputur, ngarkoni vendosjen dhe konfirmoni që shfaqet një reklamë prove. Kapni kërkesën në logcat me adb logcat | grep -i ads dhe shënoni kodin e përgjigjes. Mungesa e mbushjes në vijën bazë nuk është problem i VPN.

Pastaj lidhuni dhe përsëritni. I njëjti build, e njëjta njësi, i njëjti vendosje, VPN i ndezur. Kapni të njëjtat rreshta log. Ajo që kërkoni është një ndryshim: një mbushje që bëhet skadim kohe, një kërkesë që nuk del kurrë, një kod gabimi që ndryshon. Një mbushje që mbetet mbushje ju thotë se integrimi është në rregull në atë rrugë dhe testi ka mbaruar.

Shënoni mjedisin. Versioni SDK, versionet e përshtatësve, lloji i build-it, formati i reklamës, vendi i daljes dhe rezultati i vëzhguar. Pa atë shënim, personi tjetër e përsërit eksperimentin nga zero dhe arrin në një përfundim tjetër nga të njëjtat prova.

Ndërmjetësimi është test i veçantë

Reklamat e ndërmjetësuara nuk mbajnë etiketën Test Ad të Google, gjë që i bën vendin më të lehtë për të klikuar diçka që nuk duhet. Çdo rrjet në pirgjet e ndërmjetësimit ka mënyrën e vet të provës dhe konfigurimin e vet, dhe konfigurimi i provës i Google nuk shtrihet mbi to.

Kontrolloni përshtatësit një nga një, me mënyrën e provës të vetë përshtatësit të aktivizuar, dhe konfirmoni nga log-u cili rrjet e shërbeu reklamën. Nëse nuk mund të thoni cili përshtatës e mbushi dhe nëse ishte një krijim prove, trajtojeni shfaqjen si inventar të drejtpërdrejtë dhe lëreni.

Këtu ka rëndësi edhe politika për trafikun e pavlefshëm. Vetëklikimet, shfaqjet e përsëritura, ndërveprimet e automatizuara dhe trafiku mashtrues janë të gjitha të mbuluara, dhe një klik i pasigurt për të parë çfarë ndodh është pikërisht modeli që përshkruajnë ato rregulla.

Kthimi dhe porta e publikimit

Konfigurimi i provës nuk duhet të dërgohet. Përpara një build publikimi, zëvendësoni njësitë demo të reklamave me njësi prodhimi, hiqni listën e pajisjeve të provës dhe fshini çdo flamur vetëm për zhvillim. Kërkoni në variantin e publikimit identifikuesit e provës me grep në vend që të mbështeteni në kujtesë; një hyrje e humbur është një dështim i heshtur që shfaqet vetëm si të ardhura që mungojnë.

Pastaj verifikoni drejtimin e kundërt: instaloni build-in e publikimit në një pajisje prove të regjistruar dhe konfirmoni që kërkesa nuk trajtohet më si trafik prove. Nëse etiketa shfaqet ende, diçka në konfigurim ka mbijetuar.

Më pas mbani një rrugë prove të dokumentuar, që pyetja e radhës për rrjetin të mund të përgjigjet pa prekur inventarin e drejtpërdrejtë. Reklamat e provës nuk shfaqen kurrë në raportet e llogarisë, prandaj një ndarje e pastër nuk kushton asgjë në saktësinë e raportimit dhe ju jep një diagnostikim të përsëritshëm.

Artikuj të ngjashëm