Vi volas scii, ĉu via reklama integriĝo postvivas la reton, kiun viaj uzantoj efektive havas. VPN estas la plej facila maniero reprodukti malproksiman eliron. La eraro estas trakti tiun eksperimenton kiel enspezan eksperimenton.

Ŝanĝi la elirlandon ne kreas novan publikon, kaj ĝi ne transformas viajn proprajn frapojn en taŭgan trafikon. Ĝi nur ŝanĝas la vojon de peto.

Do plenumu ĝin kiel konektecan teston kun dokumentita sinsekvo, kaj tenu la vivan provizon tute ekster ĝi. La subaj paŝoj indas ripeti ĉe ĉiu konstruo.

Decidu, por kio utilas la testo

Du demandoj miksiĝas. La unua estas, ĉu peto entute estas servata el donita reta vojo, kio estas demando pri integriĝo kaj konekteco. La dua estas, kion realaj uzantoj en tiu lando gajnus, kio estas demando pri raportado kaj komerco, kiun la SDK ne povas respondi por vi.

Nur la unua estas testebla el evolua aparato. Taksiitaj enspezoj ankaŭ povas ŝanĝiĝi antaŭ ol raporta periodo finiĝos, do nombro observita dum memfarita eksperimento nek estas pruvo de taŭga enspezo nek prognozo por iu ajn alia.

Skribu la demandon antaŭ ol konekti: ekzemple, ĉu afiŝa peto redonas plenigaĵon, kiam la aparato eliras tra Germanio en ĉi tiu konstruo. Se la respondo, kiun vi volas, estas enspeza cifero, haltu ĉi tie, ĉar neniu VPN-agordo produktas tian.

Antaŭfluge: registru la aparaton, ne la adreson

La dokumentaro de Google pri testaj reklamoj proponas du subtenatajn vojojn. Uzu la demonstrajn reklamunuojn por la formato, kiun vi integras, aŭ uzu viajn proprajn unuojn kun la fizika aparato registrita kiel testa aparato. Ambaŭ estas dokumentitaj por ĉiu platformo kaj por ĉiu SDK-generacio, kaj la gvidiloj Next-Gen kaj Legacy ne estas interŝanĝeblaj.

Registrado estas aparata identigilo, kaj ĝi havas nenion komunan kun la reta adreso. Ŝanĝi, de kie eliras la trafiko de la telefono, registras nenion. Sur Android la identigilon protokolas la SDK, kaj vi aplikas ĝin en kodo:

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

Konfirmu la registradon antaŭ ol ŝanĝi retojn, alie vi ne povas distingi malsukcesan plenigaĵon de viva reklamo servita al aparato, kiu neniam estis registrita. Se la reklamo montras la etikedon Test Ad, la peto iris tra testa provizo; se ne, vi rigardas ion alian kaj ne devus frapi ĝin.

Plenumu la sinsekvon en fiksa ordo

Tenu ĉion konstantan krom la reto. Sama konstruo, sama reklamunuo, sama lokigo, sama aplika stato. Ŝanĝu du variablojn kaj vi lernos nenion.

Unue la bazlinio. Kun la VPN malkonektita, ŝargu la lokigon kaj konfirmu, ke testa reklamo aperas. Kaptu la peton en logcat per adb logcat | grep -i ads kaj notu la respondan kodon. Manko de plenigaĵo ĉe la bazlinio ne estas VPN-problemo.

Poste konektu kaj ripetu. Sama konstruo, sama unuo, sama lokigo, VPN ŝaltita. Kaptu la samajn protokolajn liniojn. Tion, kion vi serĉas, estas diferenco: plenigaĵo, kiu fariĝas tempolimo, peto, kiu neniam foriras, erarkodo, kiu ŝanĝiĝas. Plenigaĵo, kiu restas plenigaĵo, diras al vi, ke la integriĝo estas en ordo sur tiu vojo kaj la testo finiĝis.

Registru la medion. SDK-versio, adaptilaj versioj, konstrua tipo, reklama formato, elirlando kaj la observita rezulto. Sen tiu registro la sekva persono ripetas la eksperimenton de nulo kaj venas al malsama konkludo el la samaj pruvoj.

Perado estas aparta testo

Perataj reklamoj ne portas la etikedon Test Ad de Google, kio igas ilin la plej facila loko por klaki ion, kion vi ne devus. Ĉiu reto en la perada stako havas sian propran testan reĝimon kaj sian propran agordon, kaj la testa agordo de Google ne etendiĝas al ili.

Kontrolu la adaptilojn unu post unu, kun la propra testa reĝimo de la adaptilo ŝaltita, kaj konfirmu el la protokolo, kiu reto servis la reklamon. Se vi ne povas diri, kiu adaptilo plenigis kaj ĉu ĝi estis testa kreaĵo, traktu la impreson kiel vivan provizon kaj lasu ĝin.

Ĉi tie ankaŭ gravas la politiko pri nevalida trafiko. Memklakoj, ripetitaj impresoj, aŭtomatigitaj interagoj kaj trompa trafiko estas ĉiuj kovritaj, kaj necerta klako por vidi, kio okazos, estas ĝuste la ŝablono, kiun tiuj reguloj priskribas.

Retroigo kaj la eldona pordego

Testa agordo ne rajtas elsendiĝi. Antaŭ eldona konstruo anstataŭigu demonstrajn reklamunuojn per produktaj unuoj, forigu la liston de testaj aparatoj kaj viŝu ĉiajn flagojn nur por evoluo. Serĉu en la eldona varianto la testajn identigilojn anstataŭ fidi al memoro; erarvaganta rikordo estas silenta fiasko, kiu aperas nur kiel mankanta enspezo.

Poste kontrolu la kontraŭan direkton: instaligu la eldonan konstruon sur registrita testa aparato kaj konfirmu, ke la peto ne plu estas traktata kiel testa trafiko. Se ĝi ankoraŭ montras la etikedon, io en la agordo postvivis.

Poste konservu unu dokumentitan testan vojon, por ke la sekva reta demando povu esti respondita sen tuŝi la vivan provizon. Testaj reklamoj neniam aperas en kontaj raportoj, do pura apartigo kostas nenion en raporta precizeco kaj donas al vi ripeteblan diagnozon.

Rilataj artikoloj