Праверце рэкламу AdMob праз VPN, не рызыкуючы ўліковым запісам
Працоўная інструкцыя для праверкі AdMob, пакуль прылада знаходзіцца ў VPN: зарэгіструйце тэставую прыладу, захапіце адзін запыт, праверце пазнаку і прыбярыце налады перад выпускам.
Вы хочаце ведаць, ці вытрымае вашая інтэграцыя рэкламы тую сетку, якая ёсць у вашых карыстальнікаў. VPN — самы просты спосаб узнавіць далёкі выхад. Памылка ў тым, каб лічыць гэты эксперымент эксперыментам з даходам.
Змена краіны выхаду не стварае новую аўдыторыю і не ператварае вашыя ўласныя націскі ў дапушчальны трафік. Яна змяняе шлях запыту.
Таму праводзьце яго як тэст злучэння з дакументаванай паслядоўнасцю і трымайце жывы інвентар цалкам убаку. Прыведзеныя ніжэй крокі варта паўтараць у кожнай зборцы.
Вызначце, для чаго патрэбны тэст
Два пытанні змешваюцца. Першае — ці абслугоўваецца запыт наогул з дадзенага сеткавага шляху, і гэта пытанне інтэграцыі і злучэння. Другое — колькі зарабілі б рэальныя карыстальнікі ў гэтай краіне, а гэта пытанне справаздачнасці і бізнесу, на якое SDK не адкажа за вас.
Толькі першае можна праверыць з прылады распрацоўкі. Ацэначныя заробкі таксама могуць змяніцца да закрыцця справаздачнага перыяду, таму лік, заўважаны падчас самастойна створанага эксперыменту, не з'яўляецца ні доказам дапушчальнага даходу, ні прагнозам для кагосьці іншага.
Запішыце пытанне перад падключэннем: напрыклад, ці вяртае запыт банэра запоўненне, калі прылада выходзіць праз Германію ў гэтай зборцы. Калі адказ, які вам патрэбны, — гэта лічба даходу, спыніцеся тут, бо ніводная канфігурацыя VPN такой лічбы не дае.
Перад палётам: рэгіструйце прыладу, а не адрас
Дакументацыя Google пра тэставую рэкламу прапануе два падтрыманыя шляхі. Выкарыстоўвайце дэма-рэкламныя блокі для фармату, які вы інтэгруеце, або свае ўласныя блокі, зарэгістраваўшы фізічную прыладу як тэставую. Абодва апісаны для кожнай платформы і кожнага пакалення SDK, і кіраўніцтвы Next-Gen і Legacy не ўзаемазаменныя.
Рэгістрацыя — гэта ідэнтыфікатар прылады, і яна не мае нічога агульнага з сеткавым адрасам. Змена таго, адкуль выходзіць трафік тэлефона, нічога не рэгіструе. На Android ідэнтыфікатар запісваецца ў журнал SDK, і вы ўжываеце яго ў кодзе:
RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))
Пацвердзіце рэгістрацыю перад зменай сетак, інакш вы не адрозніце няўдалае запоўненне ад жывой рэкламы, паказанай прыладзе, якая ніколі не рэгістравалася. Калі рэклама паказвае пазнаку Test Ad, запыт прайшоў праз тэставы інвентар; калі не, вы бачыце нешта іншае і не павінны на гэта націскаць.
Выконвайце паслядоўнасць у фіксаваным парадку
Трымайце ўсё нязменным, акрамя сеткі. Тая ж зборка, той жа рэкламны блок, тое ж размяшчэнне, той жа стан праграмы. Зменіце дзве зменныя — і вы нічога не даведаецеся.
Спачатку базавая лінія. Пры адключаным VPN загрузіце размяшчэнне і пераканайцеся, што тэставая рэклама з'явілася. Перахапіце запыт у logcat з дапамогай adb logcat | grep -i ads і запішыце код адказу. Адсутнасць запоўнення на базавай лініі — не праблема VPN.
Затым падключыцеся і паўтарыце. Тая ж зборка, той жа блок, тое ж размяшчэнне, VPN уключаны. Перахапіце тыя ж радкі журналу. Вы шукаеце розніцу: запоўненне, якое ператвараецца ў тайм-аўт, запыт, які не выходзіць, код памылкі, які змяняецца. Запоўненне, якое застаецца запоўненнем, кажа, што інтэграцыя ў парадку на гэтым шляху, і тэст скончаны.
Запішыце асяроддзе. Версія SDK, версіі адаптараў, тып зборкі, фармат рэкламы, краіна выхаду і назіраны вынік. Без гэтага запісу наступны чалавек паўторыць эксперымент з нуля і прыйдзе да іншай высновы з тых жа доказаў.
Медыяцыя — асобны тэст
Медыяваная рэклама не нясе пазнакі Test Ad ад Google, што робіць яе самым простым месцам, дзе можна націснуць на тое, на што не варта. Кожная сетка ў стэку медыяцыі мае свой тэставы рэжым і сваю наладку, і тэставая канфігурацыя Google на іх не пашыраецца.
Правярайце адаптары па чарзе, уключыўшы ўласны тэставы рэжым адаптара, і пацвердзіце па журнале, якая сетка паказала рэкламу. Калі вы не можаце вызначыць, які адаптар запоўніў і ці быў гэта тэставы крэатыў, лічыце паказ жывым інвентаром і не чапайце яго.
Менавіта тут мае значэнне палітыка несапраўднага трафіку. Уласныя націскі, паўторныя паказы, аўтаматызаваныя ўзаемадзеянні і падманны трафік — усё гэта ахоплена, і няўпэўнены націск, каб паглядзець, што будзе, — гэта менавіта той узор, які апісваюць гэтыя правілы.
Адкат і выпускны шлюз
Тэставая канфігурацыя не павінна патрапіць у выпуск. Перад выпускной зборкай заменіце дэма-рэкламныя блокі вытворчымі, выдаліце спіс тэставых прылад і прыбярыце ўсе сцягі, прызначаныя толькі для распрацоўкі. Праглядзіце выпускны варыянт на тэставыя ідэнтыфікатары замест таго, каб спадзявацца на памяць; выпадковы запіс — гэта ціхая памылка, якая выяўляецца толькі як страчаны даход.
Затым праверце ў адваротным кірунку: усталюйце выпускную зборку на зарэгістраваную тэставую прыладу і пераканайцеся, што запыт больш не лічыцца тэставым трафікам. Калі пазнака ўсё яшчэ паказваецца, нешта ў канфігурацыі засталося.
Пасля гэтага захавайце адзін дакументаваны тэставы шлях, каб на наступнае пытанне пра сетку можна было адказаць, не чапаючы жывога інвентару. Тэставая рэклама ніколі не з'яўляецца ў справаздачах акаўнта, таму чыстае раздзяленне нічога не каштуе для дакладнасці справаздач і дае вам узнавільную дыягностыку.