[продолжение. cмотри начало в предыдущем посте]

В прошлом посте мы писали, что не нашли на рынке хорошей платформы для проведения А/В-тестов и решили написать свою. В этом посте мы расскажем, из чего состоит её техническая часть.

Давайте рассмотрим пример. На прошлой неделе мы перешли с медиации MoPub на Applovin Max. В рамках теста мы хотим узнать, как это изменение повлияло на основные метрики игры.

Remote Config
Настройка любого теста идет через удаленный конфиг, который хранится на облаке. Каждый раз, когда игрок первый раз открывает игру, игра запрашивает конфиг следующего формата:
Пример
ABTestV2ApplovinAndNewTowers28April02 = {"version":301,"variant":"Variant","parameters":{ }}
ABTestV2ApplovinAndNewTowers28April01 = {"version":300,"variant":"Control","parameters":{ }}

В этом примере мы просто говорим платформе: “Пометь всех игроков контрольной версии 300 как Control, а версию 301 как Variant в рамках теста V2ApplovinAndNewTowers28”.

Разделение игроков на группы
Сейчас мы умеем делить игроков на группы двумя способами:
1. Разбиение в рамках версии. Допустим, у нас на Google Play выложена на 100% аудитории версия 301. Мы запускаем тест на этой аудитории.
2. В рамках разных версий. Как в примере с Applovin. Мы выкладываем новый билд и хотим знать, как у него отличаются метрики по сравнению с контрольным.

Процесс сбора данных
Цель нашего эксперимента - заработать больше денег. Деньги мы получаем из двух источников:
1. Продажа In-App’ов. В нашем случае это золото, новые герои, новые башни и топливо. Для каждого игрока мы собираем всю информацию о его покупках.
2. Показ рекламы (impressions). Чем больше рекламы мы показали, тем больше денег заработали.

ВАЖНО в рамках эксперимента рассматривать не отдельные платежи и показы impressions, а сумму которую игроки тратят. На эту тему будет отдельный пост.

Кроме этого, мы собираем еще много всего, но все решения всегда принимаются только на основе данных о рекламе и in-app’ов. Нам абсолютно неважно, что стало с retention, стали ли игроки отваливаться на 5-ом уровне или нет. Эти метрики мы тоже собираем и обрабатываем, но они никогда не имеют веса в принятии решения, а скорее позволяют нам лучше понять, что произошло. Решение же принимается всегда на основе ответа на вопрос: “Стали мы зарабатывать больше или нет?”. Если стали зарабатывать больше, фича идет в продакшн. Если не стали, мы ее откатываем. Откатываем мы примерно 70% от всех фич. Почему так - это тоже тема отдельного поста.

Антифрод
На данный момент существенный процент игроков получает платный игровой контент, не заплатив. Для нашего эксперимента это проблема, потому что мы получаем кривые данные в рамках эксперимента и можем сделать неправильный вывод. Существует несколько способов (и это тоже тема отдельного поста) обмана разработчиков. Если кратко, то суть нашего антифрода - это проведение транзакций через облако.

1. Код на облаке запрашивает подтверждение о каждой транзакции у Google и отдает нашей игре заключение “Этот игрок не читер” или “Это читер”.
2. Игра помечает все in-app’ы как валидные или невалидные
3. В процессе обработки данных мы смотрим только на валидные in-app’ы.

Хранилище данных
Все данные об игроках хранятся в Google Analytics, и несколько раз в сутки мы выгружаем их в Big Query.

Обработка данных
Ядро нашей платформы написано на R. Мы отправляем запросы в Big Query и на стороне сервера обрабатываем их.