Testuj reklamy AdMob przez VPN bez ryzyka dla konta

Chcesz wiedzieć, czy Twoja integracja reklam przetrwa sieć, którą Twoi użytkownicy naprawdę mają. VPN to najłatwiejszy sposób odtworzenia odległego wyjścia. Błąd polega na traktowaniu tego eksperymentu jako eksperymentu przychodowego.

Zmiana kraju wyjścia nie tworzy nowej publiczności ani nie zamienia Twoich własnych dotknięć w ruch kwalifikowany. Zmienia tylko ścieżkę żądania.

Więc przeprowadź to jako test łączności z udokumentowaną sekwencją i trzymaj żywy inwentarz całkowicie z dala. Poniższe kroki warto powtarzać przy każdym buildzie.

Zdecyduj, czemu służy test

Dwa pytania się mieszają. Pierwsze to, czy żądanie jest w ogóle obsługiwane z danej ścieżki sieciowej, co jest kwestią integracji i łączności. Drugie to, ile zarobiliby prawdziwi użytkownicy w tym kraju, co jest kwestią raportowania i biznesu, na którą SDK nie odpowie za Ciebie.

Z urządzenia deweloperskiego da się przetestować tylko pierwsze. Szacowane zarobki mogą się też zmienić przed zamknięciem okresu raportowego, więc liczba zaobserwowana w samodzielnie wygenerowanym eksperymencie nie jest ani dowodem kwalifikowanych przychodów, ani prognozą dla kogokolwiek innego.

Zapisz pytanie, zanim się połączysz: na przykład, czy żądanie banera zwraca wypełnienie, gdy urządzenie wychodzi przez Niemcy w tym buildzie. Jeśli odpowiedzią, której chcesz, jest liczba przychodów, zatrzymaj się tutaj, bo żadna konfiguracja VPN jej nie wytwarza.

Przed startem: zarejestruj urządzenie, nie adres

Dokumentacja Google dotycząca reklam testowych oferuje dwie obsługiwane drogi. Użyj demonstracyjnych jednostek reklamowych dla formatu, który integrujesz, albo własnych jednostek z fizycznym urządzeniem zarejestrowanym jako urządzenie testowe. Oba są udokumentowane dla każdej platformy i generacji SDK, a przewodniki Next-Gen i Legacy nie są wymienne.

Rejestracja to identyfikator urządzenia i nie ma nic wspólnego z adresem sieciowym. Zmiana tego, skąd wychodzi ruch telefonu, niczego nie rejestruje. W Androidzie identyfikator jest logowany przez SDK, a Ty stosujesz go w kodzie:

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

Potwierdź rejestrację, zanim zmienisz sieć, inaczej nie odróżnisz nieudanego wypełnienia od reklamy na żywo wyświetlonej urządzeniu, które nigdy nie zostało zarejestrowane. Jeśli reklama pokazuje etykietę Test Ad, żądanie przeszło przez inwentarz testowy; jeśli nie, patrzysz na coś innego i nie powinieneś tego dotykać.

Wykonaj sekwencję w stałej kolejności

Utrzymuj wszystko stałe poza siecią. Ten sam build, ta sama jednostka reklamowa, ta sama lokalizacja, ten sam stan aplikacji. Zmień dwie zmienne i niczego się nie dowiesz.

Najpierw linia bazowa. Z wyłączonym VPN wczytaj lokalizację i potwierdź, że pojawia się reklama testowa. Przechwyć żądanie w logcat za pomocą adb logcat | grep -i ads i zanotuj kod odpowiedzi. Brak wypełnienia w linii bazowej nie jest problemem VPN.

Potem połącz się i powtórz. Ten sam build, ta sama jednostka, ta sama lokalizacja, VPN włączony. Przechwyć te same linie logu. Czego szukasz, to różnica: wypełnienie, które staje się przekroczeniem czasu, żądanie, które nigdy nie wychodzi, kod błędu, który się zmienia. Wypełnienie, które pozostaje wypełnieniem, mówi, że integracja na tej ścieżce jest w porządku i test się skończył.

Zapisz środowisko. Wersja SDK, wersje adapterów, typ builda, format reklamy, kraj wyjścia i zaobserwowany wynik. Bez tego zapisu następna osoba powtarza eksperyment od zera i dochodzi do innego wniosku z tych samych dowodów.

Mediacja to osobny test

Reklamy mediowane nie noszą etykiety Test Ad Google, co czyni je najłatwiejszym miejscem do kliknięcia w coś, czego nie powinieneś. Każda sieć w stosie mediacji ma własny tryb testowy i własną konfigurację, a konfiguracja testowa Google ich nie obejmuje.

Sprawdzaj adaptery pojedynczo, z włączonym własnym trybem testowym adaptera, i potwierdź z logu, która sieć obsłużyła reklamę. Jeśli nie potrafisz powiedzieć, który adapter wypełnił i czy to była kreacja testowa, traktuj wyświetlenie jako żywy inwentarz i zostaw je w spokoju.

Tutaj liczy się też polityka nieprawidłowego ruchu. Samokliki, powtarzane wyświetlenia, zautomatyzowane interakcje i ruch wprowadzający w błąd są wszystkie objęte, a niepewne kliknięcie, żeby zobaczyć, co się stanie, jest dokładnie tym wzorcem, który opisują te reguły.

Wycofanie i brama wydania

Konfiguracja testowa nie może trafić do wydania. Przed buildem wydania zastąp demonstracyjne jednostki reklamowe jednostkami produkcyjnymi, usuń listę urządzeń testowych i usuń wszystkie flagi tylko dla deweloperów. Przeszukaj wariant wydania pod kątem identyfikatorów testowych grepem, zamiast ufać pamięci; zabłąkany wpis to cicha awaria, która objawia się tylko jako brakujące przychody.

Następnie zweryfikuj przeciwny kierunek: zainstaluj build wydania na zarejestrowanym urządzeniu testowym i potwierdź, że żądanie nie jest już traktowane jako ruch testowy. Jeśli etykieta nadal się pojawia, coś w konfiguracji przetrwało.

Potem zachowaj jedną udokumentowaną ścieżkę testową, aby na kolejne pytanie o sieć można było odpowiedzieć bez dotykania żywego inwentarza. Reklamy testowe nigdy nie pojawiają się w raportach konta, więc czyste rozdzielenie nic nie kosztuje w dokładności raportowania i daje powtarzalną diagnostykę.