Алоха, Хабр! Тестирование рекламных интеграций — довольно трудоёмкий процесс, который сложно автоматизировать, так как мы работаем со сторонними SDK и практически не можем их контролировать. Но для сокращения времени мы разработали и внедрили рекламную дебаг-панель, о плюсах и минусах которой расскажу в этой статье.
В FunCorp все фичи и эксперименты релизятся с механизмом фича-тогглов — флагов, контролирующих включение и выключение частей кода. Это делает релизы надёжнее и безопаснее. Такую практику мы используем не только в продуктовых и платформенных командах, но и в команде монетизации — так как возможность изменения конфига фичи/эксперимента без релиза приложения напрямую влияет на безопасность, отказоустойчивость, а, значит, и на уровень доходов.
Как получаем рекламу
У нас существует две модели получения рекламы — водопад и аукцион. С их более детальным описанием можно ознакомиться в статье моего коллеги @maiscourt.
Рассмотрим получение рекламы на примере водопада.
Чтобы отобразить на экране баннер или нативную рекламу, приложение для начала запрашивает настройки у медиатора, после получения которых идёт к конкретной рекламной сети. В случае положительного ответа происходит попытка загрузить предложенный креатив. В конце итерации медиатору отправляется сообщение о результате. В случае неудачи на любом из вышеописанных этапов — всё повторяется. В результате для загрузки одного баннера или нативной рекламы могут быть выполнены сотни, а то и тысячи запросов.
Таким образом, учитывая, что в iFunny интегрировано порядка 10 рекламных SDK, а поведение рекламы с продакшн-параметрами является непредсказуемым, тестировать на продакшне нецелесообразно. Именно поэтому в 99% задач используется тестовая реклама.
Тестовую рекламу предоставляют рекламные сети. Преимущество тестирования на ней заключается в том, что она всегда приходит с одним и тем же набором параметров и характеристик. Используя её, можно быть уверенным, что новый функционал или фикс бага не затронул основные параметры и работу рекламного креатива.
Получение тестовой рекламы с технической стороны, пожалуй, ещё более сложная задача, чем получение продакшн-рекламы. Этапы водопада остаются неизменными. Но теперь нам понадобится работать с трафиком, медиатором, нашими фичами, тест-модами и VPN.
Руками
Чтобы получать тестовую рекламу «руками», нам понадобится инструмент для работы с трафиком. В нашей команде это Charles. Используя Charles, нужно рерайтить продакшн-параметры на тестовые в следующих запросах:
к своим настройкам с фичами и экспериментами;
к медиатору (отдельно для баннера и нативной рекламы);
к рекламной сети (отдельно для баннера и нативной рекламы).
В некоторых случаях будут необходимы тест-моды (параметры, сообщающие рекламной сети о запросе на тестовую рекламу), а также модификация плейсмента (параметр, сообщающий рекламной сети про запрос на определённый тип рекламы, например, на видео). Кроме того, некоторые рекламные сети требуют VPN.
Как видим, модифицировать трафик приходится довольно активно, что сопровождается минусами:
Изменения в админке медиатора не применяются одномоментно. Чтобы получить рекламу от конкретной рекламной сети, в админке медиатора необходимо её выбрать. Такие изменения требуют времени, так как настройки кешируются. Ожидание изменений может занимать 15-20 минут.
Рерайты устаревают. С некоторой периодичностью придётся сталкиваться с тем, что меняются параметры продакшн-рекламы.
Не все рекламные сети можно сниффать. Если проксировать трафик, некоторые рекламные сети просто не работают.
Ситуации, когда необходимо тестировать без прокси. Иногда необходимо исключить влияние сниффера на работу рекламы.
Ситуации, когда тест-мод невозможно зарерайтить. У некоторых рекламных сетей тест-мод захардкожен, или передаётся в таком формате, что зарерайтить его достаточно сложно, либо необходимо собирать для тестирования отдельный билд.
С помощью дебаг-панели
Для удобства тестирования и оптимизации трудозатрат мы разработали рекламную дебаг-панель. Это отдельный интерфейс, который позволяет локально на клиенте настроить необходимые параметры, заменяя собой все вышеописанные рерайты параметров и настройки.
Рассмотрим, что получилось, а также плюсы и минусы такого решения.
1. Стабильность. Как и любое тестовое окружение, дебаг-панель может быть нестабильной. Мы предусмотрели этот риск. При необходимости дебаг-панель, а также любой заложенный в неё функционал можно выключить и рерайтить через Charles параметры руками.
2. Время. Определённо, дебаг-панель требует временных затрат на разработку и поддержку. Но апдейты дебаг-панели случаются достаточно редко, а ускорение мануального тестирования и релизов сильно перевешивает этот минус.
Например, в дебаг-панели можно выбрать или продакшн-баннер и нативную рекламу, или же тестовый креатив конкретной рекламной сети (в том числе и с плейсментом). Все внешние изменения сделаны заранее и дополнительных не потребуется. Также решается проблема с кешированием настроек в админке медиатора.
Кроме того, можно включить тест-мод прямо из дебаг-панели и сэкономить время на дополнительной сборке билда.
3. Безопасность. Тут только плюс. Используя дебаг-панель нет необходимости изменять параметры фичей и экспериментов на продакшне, так как все изменения будут локальными. Фичу или эксперимент в дебаг-панели можно не просто включить/выключить, даже когда их ещё нет на продакшне, но и выбрать продакшн/тестовые/дефолтные параметры или изменить их вручную.
Заключение
Да, разработка и поддержка дебаг-панели стоит бизнесу времени. Но, по нашим подсчётам, решение сократило время тестирования регрессов на 50%. Поэтому не бойтесь создавать собственные решения, если они потенциально могут помочь оптимизировать ваши ресурсы.
