Перевіряйте рекламу 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 на них не поширюється.

Перевіряйте адаптери по одному, з увімкненим власним тестовим режимом адаптера, і за журналом підтверджуйте, яка мережа показала оголошення. Якщо ви не можете сказати, який адаптер заповнив і чи це був тестовий креатив, вважайте показ живим інвентарем і залиште його.

Тут також важлива політика щодо недійсного трафіку. Самокліки, повторні покази, автоматизовані взаємодії та оманливий трафік — усе це охоплено, а непевний клік, щоб подивитися, що буде, — це саме той шаблон, який описують ці правила.

Відкат і шлюз випуску

Тестова конфігурація не повинна потрапляти у випуск. Перед релізною збіркою замініть демонстраційні рекламні блоки виробничими, видаліть список тестових пристроїв і приберіть усі прапорці, призначені лише для розробки. Шукайте тестові ідентифікатори в релізному варіанті за допомогою grep, а не покладайтеся на пам'ять; зайвий запис — це тихий збій, який проявляється лише як відсутній дохід.

Потім перевірте зворотний напрям: встановіть релізну збірку на зареєстрований тестовий пристрій і підтвердьте, що запит більше не вважається тестовим трафіком. Якщо позначка все ще відображається, щось у конфігурації вціліло.

Після цього збережіть один задокументований тестовий шлях, щоб на наступне питання про мережу можна було відповісти, не торкаючись живого інвентарю. Тестові оголошення ніколи не з'являються у звітах облікового запису, тож чисте розділення нічого не коштує для точності звітності й дає вам відтворювану діагностику.