Tudni szeretné, hogy hirdetési integrációja kibírja-e azt a hálózatot, amely az Ön felhasználóinál valóban van. A VPN a legegyszerűbb módja egy távoli kimenet újraalkotásának. A hiba az, hogy ezt a kísérletet bevételi kísérletként kezeljük.

A kilépési ország megváltoztatása nem hoz létre új közönséget, és nem alakítja a saját koppintásait jogosult forgalommá. Csak a kérés útvonalát változtatja meg.

Futtassa tehát dokumentált sorrendű kapcsolódási tesztként, és tartsa a valós készletet teljesen azon kívül. Az alábbi lépéseket érdemes minden buildben megismételni.

Döntse el, mire való a teszt

Két kérdés keveredik. Az első az, hogy egy kérés egyáltalán kiszolgálható-e egy adott hálózati útvonalról, ami integrációs és kapcsolódási kérdés. A második az, hogy az adott ország valódi felhasználói mennyit keresnének, ami jelentési és üzleti kérdés, amelyre az SDK nem tud Ön helyett válaszolni.

Csak az első tesztelhető fejlesztői eszközről. A becsült bevétel a jelentési időszak lezárása előtt is változhat, ezért egy saját maga által létrehozott kísérlet során megfigyelt szám sem a jogosult bevétel bizonyítéka, sem előrejelzés bárki más számára.

Írja le a kérdést, mielőtt csatlakozik: például kap-e kitöltést egy bannerkérés, amikor az eszköz ebben a buildben Németországon keresztül lép ki. Ha a kívánt válasz egy bevételi szám, álljon meg itt, mert egyetlen VPN-konfiguráció sem állít elő ilyet.

Indulás előtt: regisztrálja az eszközt, ne a címet

A Google teszt-hirdetési dokumentációja két támogatott útvonalat kínál. Használja a demó hirdetési egységeket az integrált formátumhoz, vagy saját egységeit, a fizikai eszközt teszt eszközként regisztrálva. Mindkettő platformonként és SDK-generációnként dokumentált, a Next-Gen és Legacy útmutatók pedig nem cserélhetők fel.

A regisztráció eszközazonosító, és semmi köze a hálózati címhez. Annak megváltoztatása, hogy honnan lép ki a telefon forgalma, semmit nem regisztrál. Androidon az SDK naplózza az azonosítót, és Ön a kódban alkalmazza:

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

Erősítse meg a regisztrációt, mielőtt hálózatot vált, különben nem tudja megkülönböztetni a sikertelen kitöltést egy olyan eszköznek kiszolgált élő hirdetéstől, amelyet soha nem regisztráltak. Ha a hirdetés a Test Ad címkét mutatja, a kérés a tesztkészleten ment keresztül; ha nem, valami mást néz, és nem kellene megérintenie.

Rögzített sorrendben hajtsa végre a folyamatot

Tartson mindent állandóan a hálózat kivételével. Ugyanaz a build, ugyanaz a hirdetési egység, ugyanaz az elhelyezés, ugyanaz az alkalmazásállapot. Változtasson meg két változót, és semmit nem tanul.

Először az alapvonal. Kikapcsolt VPN-nel töltse be az elhelyezést, és erősítse meg, hogy megjelenik egy teszt-hirdetés. Rögzítse a kérést a logcatben ezzel: adb logcat | grep -i ads és jegyezze fel a válaszkódot. Az alapvonalon tapasztalt kitöltés hiánya nem VPN-probléma.

Ezután csatlakozzon és ismételje meg. Ugyanaz a build, ugyanaz az egység, ugyanaz az elhelyezés, VPN bekapcsolva. Rögzítse ugyanazokat a naplósorokat. Amit keres, az egy különbség: egy kitöltés, amely időtúllépéssé válik, egy kérés, amely soha nem indul el, egy hibakód, amely megváltozik. A kitöltés maradó kitöltés azt mondja, hogy az integráció azon az útvonalon rendben van, és a teszt véget ért.

Rögzítse a környezetet. SDK-verzió, adapterverziók, buildtípus, hirdetési formátum, kilépési ország és a megfigyelt eredmény. E feljegyzés nélkül a következő ember elölről ismétli meg a kísérletet, és ugyanazokból a bizonyítékokból más következtetésre jut.

A közvetítés külön teszt

A közvetített hirdetések nem viselik a Google Test Ad címkéjét, ami a legkönnyebb hellyé teszi őket arra, hogy olyasmire kattintson, amire nem kellene. A közvetítési verem minden hálózatának saját tesztmódja és saját beállítása van, és a Google tesztkonfigurációja nem terjed ki rájuk.

Ellenőrizze az adaptereket egyenként, az adapter saját tesztmódjával bekapcsolva, és a naplóból erősítse meg, melyik hálózat szolgálta ki a hirdetést. Ha nem tudja megmondani, melyik adapter töltött ki, és hogy tesz kreatív volt-e, kezelje a megjelenítést valós készletként, és hagyja békén.

Itt számít az érvénytelen forgalomra vonatkozó szabályzat is. Az önkattintások, az ismételt megjelenítések, az automatizált interakciók és a megtévesztő forgalom mind le vannak fedve, és egy bizonytalan kattintás, hogy lássuk, mi történik, pontosan az a minta, amelyet ezek a szabályok leírnak.

Visszaállítás és a kiadási kapu

A tesztkonfiguráció nem kerülhet kiadásra. Kiadási build előtt cserélje le a demó hirdetési egységeket gyártási egységekre, távolítsa el a teszteszközök listáját, és töröljön minden csak fejlesztésre szánt jelzőt. A memóriára hagyatkozás helyett keresse meg a tesztazonosítókat a kiadási változatban grep-pel; egy elkóborolt bejegyzés csendes hiba, amely csak hiányzó bevételként jelenik meg.

Ezután ellenőrizze az ellenkező irányt: telepítse a kiadási buildet egy regisztrált teszt eszközre, és erősítse meg, hogy a kérést már nem kezeli tesztforgalomként. Ha még mindig mutatja a címkét, valami megmaradt a konfigurációban.

Ezután tartson meg egy dokumentált tesztútvonalat, hogy a következő hálózati kérdésre a valós készlet érintése nélkül lehessen válaszolni. A teszt hirdetések soha nem jelennek meg a fiókjelentésekben, így a tiszta elkülönítés semmibe sem kerül a jelentések pontosságában, és ismételhető diagnosztikát ad.

Kapcsolódó cikkek