Тестируйте рекламу 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, а не полагайтесь на память; затесавшаяся запись — это тихий сбой, который проявляется только как недостающий доход.

Затем проверьте обратное направление: установите релизную сборку на зарегистрированное тестовое устройство и убедитесь, что запрос больше не считается тестовым трафиком. Если метка всё ещё отображается, что-то в конфигурации уцелело.

После этого сохраните один задокументированный тестовый путь, чтобы на следующий вопрос о сети можно было ответить, не трогая живой инвентарь. Тестовые объявления никогда не появляются в отчётах аккаунта, поэтому чистое разделение ничего не стоит для точности отчётности и даёт вам воспроизводимую диагностику.