Testaa AdMob-mainoksia VPN:ssä vaarantamatta tiliäsi
Ohje AdMobin testaamiseen, kun laite on VPN:ssä: rekisteröi testilaite, kaappaa yksi pyyntö, varmista tunniste ja siivoa ennen julkaisua.
Haluat tietää, kestääkö mainosintegraatiosi verkon, joka käyttäjilläsi todella on. VPN on helpoin tapa toistaa etäinen uloskäynti. Virhe on kohdella tuota koetta tulokokeena.
Uloskäyntimaan vaihtaminen ei luo uutta yleisöä eikä muuta omia napautuksiasi kelvolliseksi liikenteeksi. Se muuttaa vain pyynnön reittiä.
Suorita se siis dokumentoidulla järjestyksellä yhteystestinä ja pidä live-varasto kokonaan sen ulkopuolella. Alla olevat vaiheet kannattaa toistaa jokaisessa buildissa.
Päätä, mihin testi on tarkoitettu
Kaksi kysymystä sekoittuvat. Ensimmäinen on, palvellaanko pyyntöä ylipäätään tietystä verkkoreitistä, mikä on integraatio- ja yhteyskysymys. Toinen on, mitä kyseisen maan todelliset käyttäjät ansaitsisivat, mikä on raportointi- ja liiketoimintakysymys, johon SDK ei voi vastata puolestasi.
Vain ensimmäinen on testattavissa kehityslaitteesta. Arvioidut ansiot voivat myös muuttua ennen raportointikauden päättymistä, joten itse tuotetussa kokeessa havaittu luku ei ole todiste kelvollisista tuloista eikä ennuste kenellekään muulle.
Kirjoita kysymys muistiin ennen yhdistämistä: esimerkiksi palauttaako banneripyyntö täyttöä, kun laite poistuu Saksan kautta tässä buildissa. Jos haluamasi vastaus on tuloluku, pysähdy tähän, koska mikään VPN-kokoonpano ei tuota sellaista.
Ennen lentoa: rekisteröi laite, älä osoitetta
Googlen testimainosdokumentaatio tarjoaa kaksi tuettua reittiä. Käytä demo-mainosyksiköitä integroitavalle formaatille tai omia yksiköitäsi, kun fyysinen laite on rekisteröity testilaitteeksi. Molemmat on dokumentoitu alustakohtaisesti ja SDK-sukupolvittain, eivätkä Next-Gen- ja Legacy-oppaat ole keskenään vaihdettavissa.
Rekisteröinti on laitetunniste, eikä sillä ole mitään tekemistä verkko-osoitteen kanssa. Sen muuttaminen, mistä puhelimen liikenne lähtee, ei rekisteröi mitään. Androidissa SDK kirjaa tunnisteen, ja sinä käytät sitä koodissa:
RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))
Vahvista rekisteröinti ennen verkon vaihtamista, muuten et voi erottaa epäonnistunutta täyttöä live-mainoksesta, joka näytettiin laitteelle, jota ei koskaan rekisteröity. Jos mainos näyttää Test Ad -tunnisteen, pyyntö kulki testivaraston kautta; jos ei, katsot jotain muuta eikä sinun pitäisi napauttaa sitä.
Suorita järjestys kiinteässä järjestyksessä
Pidä kaikki vakiona paitsi verkko. Sama build, sama mainosyksikkö, sama sijoittelu, sama sovelluksen tila. Vaihda kaksi muuttujaa, etkä opi mitään.
Ensin perustaso. Kun VPN on irrotettu, lataa sijoittelu ja varmista, että testimainos ilmestyy. Kaappaa pyyntö logcatissa komennolla adb logcat | grep -i ads ja kirjaa vastauskoodi. Täytön puuttuminen perustasolla ei ole VPN-ongelma.
Yhdistä sitten ja toista. Sama build, sama yksikkö, sama sijoittelu, VPN päällä. Kaappaa samat lokirivit. Etsit eroa: täyttö, joka muuttuu aikakatkaisuksi, pyyntö, joka ei koskaan lähde, virhekoodi, joka muuttuu. Täyttönä pysyvä täyttö kertoo, että integraatio on kunnossa tuolla reitillä ja testi on ohi.
Kirjaa ympäristö. SDK-versio, adapterien versiot, build-tyyppi, mainosformaatti, uloskäyntimaa ja havaittu tulos. Ilman tätä kirjausta seuraava henkilö toistaa kokeen alusta ja päätyy eri johtopäätökseen samoista todisteista.
Mediaatio on erillinen testi
Medioidut mainokset eivät kanna Googlen Test Ad -tunnistetta, mikä tekee niistä helpoimman paikan klikata jotain, mitä ei pitäisi. Jokaisella mediaatiopinon verkolla on oma testitilansa ja oma asetuksensa, eikä Googlen testikokoonpano ulotu niihin.
Tarkista adapterit yksi kerrallaan adapterin omalla testitilalla ja varmista lokista, mikä verkko mainoksen toimitti. Jos et pysty sanomaan, mikä adapteri täytti ja oliko kyseessä testimateriaali, kohtele näyttökertaa live-varastona ja jätä se rauhaan.
Tässä merkitsee myös virheellisen liikenteen käytäntö. Itseklikkaukset, toistuvat näyttökerrat, automatisoidut vuorovaikutukset ja harhaanjohtava liikenne ovat kaikki katettuja, ja epävarma klikkaus nähdäksesi mitä tapahtuu on täsmälleen se kuvio, jonka nuo säännöt kuvaavat.
Palautus ja julkaisuportti
Testikokoonpanoa ei saa toimittaa. Ennen julkaisubuildia korvaa demo-mainosyksiköt tuotantoyksiköillä, poista testilaiteluettelo ja poista kaikki vain kehitykseen tarkoitetut liput. Hae julkaisuvariantista testitunnisteet sen sijaan, että luottaisit muistiin; harhaan joutunut merkintä on hiljainen virhe, joka näkyy vain puuttuvana tulona.
Tarkista sitten vastakkainen suunta: asenna julkaisubuildi rekisteröityyn testilaitteeseen ja varmista, ettei pyyntöä enää kohdella testiliikenteenä. Jos tunniste näkyy yhä, jotain kokoonpanosta on jäänyt jäljelle.
Säilytä sen jälkeen yksi dokumentoitu testipolku, jotta seuraava verkkoa koskeva kysymys voidaan vastata koskematta live-varastoon. Testimainokset eivät koskaan näy tiliraporteissa, joten puhdas erottelu ei maksa mitään raportoinnin tarkkuudessa ja antaa sinulle toistettavan diagnostiikan.