Subukan ang mga ad ng AdMob sa VPN nang hindi isinasapanganib ang iyong account

Gusto mong malaman kung nakakayanan ng iyong ad integration ang network na talagang mayroon ang iyong mga user. Ang VPN ang pinakamadaling paraan upang gayahin ang malayong exit. Ang pagkakamali ay ituring ang eksperimentong iyon bilang eksperimento sa kita.

Ang pagpapalit ng exit country ay hindi lumilikha ng bagong audience, at hindi nito ginagawang karapat-dapat na traffic ang iyong sariling mga tap. Binabago lamang nito ang landas ng isang kahilingan.

Kaya patakbuhin ito bilang test ng konektibidad na may dokumentadong pagkakasunod-sunod, at ilayo nang lubusan ang live na imbentaryo. Ang mga hakbang sa ibaba ay sulit na ulitin sa bawat build.

Magpasya kung para saan ang test

Dalawang tanong ang naghahalo. Ang una ay kung ang isang kahilingan ay pinaglilingkuran ba mula sa isang partikular na landas ng network, na isang usapin ng integration at konektibidad. Ang pangalawa ay kung magkano ang kikitain ng mga tunay na user sa bansang iyon, na isang usapin ng pag-uulat at negosyo na hindi masasagot ng SDK para sa iyo.

Ang una lamang ang masusubukan mula sa development device. Ang tinatayang kita ay maaari ring magbago bago matapos ang isang panahon ng pag-uulat, kaya ang bilang na naobserbahan sa eksperimentong ikaw mismo ang gumawa ay hindi ebidensya ng karapat-dapat na kita at hindi rin hula para sa iba.

Isulat ang tanong bago kumonekta: halimbawa, nagbabalik ba ng fill ang isang banner request kapag lumabas ang device sa Alemanya sa build na ito. Kung ang sagot na gusto mo ay isang pigura ng kita, huminto dito, dahil walang configuration ng VPN ang gumagawa niyon.

Bago lumipad: irehistro ang device, hindi ang address

Ang dokumentasyon ng Google sa mga test ad ay nag-aalok ng dalawang suportadong ruta. Gamitin ang mga demo na ad unit para sa format na iniintegrate mo, o ang sarili mong mga unit na may pisikal na device na nakarehistro bilang test device. Parehong dokumentado bawat platform at bawat henerasyon ng SDK, at ang mga gabay na Next-Gen at Legacy ay hindi mapapalitan.

Ang pagpaparehistro ay isang identifier ng device, at wala itong kinalaman sa network address. Ang pagbabago kung saan lumalabas ang traffic ng telepono ay walang naipaparehistro. Sa Android, ang identifier ay nila-log ng SDK, at inilalapat mo ito sa code:

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

Kumpirmahin ang pagpaparehistro bago magpalit ng network, kung hindi ay hindi mo matutukoy ang nabigong fill mula sa live na ad na inihain sa isang device na kailanman ay hindi nairehistro. Kung ang ad ay nagpapakita ng label na Test Ad, dumaan ang kahilingan sa test inventory; kung hindi, ibang bagay ang tinitingnan mo at hindi mo dapat itong galawin.

Patakbuhin ang pagkakasunod-sunod sa isang takdang ayos

Panatilihing pare-pareho ang lahat maliban sa network. Parehong build, parehong ad unit, parehong placement, parehong estado ng app. Baguhin ang dalawang variable at wala kang matututuhan.

Baseline muna. Habang disconnected ang VPN, i-load ang placement at kumpirmahin na lumalabas ang test ad. Kunin ang kahilingan sa logcat gamit ang adb logcat | grep -i ads at itala ang response code. Ang kawalan ng fill sa baseline ay hindi problema ng VPN.

Pagkatapos kumonekta at ulitin. Parehong build, parehong unit, parehong placement, bukas ang VPN. Kunin ang parehong mga linya ng log. Ang hinahanap mo ay isang pagkakaiba: isang fill na nagiging timeout, isang kahilingang hindi kailanman lumalabas, isang error code na nagbabago. Ang fill na nananatiling fill ay nagsasabi sa iyo na maayos ang integration sa landas na iyon at tapos na ang test.

Itala ang kapaligiran. Bersyon ng SDK, mga bersyon ng adapter, uri ng build, format ng ad, exit country, at ang naobserbahang resulta. Kung wala ang talaang iyon, inuulit ng susunod na tao ang eksperimento mula sa simula at nakarating sa ibang konklusyon mula sa parehong ebidensya.

Ang mediation ay hiwalay na test

Ang mga mediated na ad ay walang label na Test Ad ng Google, kaya sila ang pinakamadaling lugar upang i-click ang isang bagay na hindi mo dapat. Ang bawat network sa mediation stack ay may sariling test mode at sariling setup, at hindi umaabot sa kanila ang test configuration ng Google.

Suriin ang mga adapter isa-isa, na bukas ang sariling test mode ng adapter, at kumpirmahin mula sa log kung aling network ang naghain ng ad. Kung hindi mo masabi kung aling adapter ang nag-fill at kung test creative ito, ituring na live na imbentaryo ang impression at hayaan ito.

Dito rin mahalaga ang patakaran sa invalid na traffic. Ang mga self-click, paulit-ulit na impression, automated na interaksyon at mapanlinlang na traffic ay saklaw lahat, at ang isang hindi tiyak na click upang makita ang mangyayari ay eksaktong pattern na inilalarawan ng mga patakarang iyon.

Pag-rollback at ang gate ng release

Hindi dapat maipadala ang test configuration. Bago ang isang release build, palitan ang mga demo na ad unit ng production units, alisin ang listahan ng test device, at burahin ang lahat ng flag na para sa development lamang. I-grep ang release variant para sa mga test identifier sa halip na umasa sa memorya; ang naligaw na entry ay tahimik na pagpalya na lumalabas lamang bilang kulang na kita.

Pagkatapos i-verify ang kabaligtaran: i-install ang release build sa isang nakarehistrong test device at kumpirmahin na hindi na itinuturing na test traffic ang kahilingan. Kung nagpapakita pa rin ito ng label, may natira sa configuration.

Pagkatapos, panatilihin ang isang dokumentadong landas ng test upang ang susunod na tanong sa network ay masagot nang hindi hinahawakan ang live na imbentaryo. Ang mga test ad ay hindi kailanman lumalabas sa mga ulat ng account, kaya ang malinis na paghihiwalay ay walang gastos sa katumpakan ng pag-uulat at binibigyan ka ng maulit na diagnostic.