Полина Опарина из DocDoc про A/B тестирование в мобильных приложениях на Product Camp Minsk 2018

Ниже приведён текст самой презентации, опубликованный докладчиком на странице в Facebook.

- - -

Этот доклад будет вам интересен, если

- У вас есть мобильное приложение.
- Вы не делаете A/B тесты, но хотели бы начать.
- Вы выбираете решение для A/B тестирования в приложении.
- Вы уже используете какой-то инструмент, но он вас не устраивает.

Этой зимой у нас появилась задача внедрить инструмент для A/B тестирования в приложении DocDoc.

Первым делом мы проанализировали готовые решения и обнаружили ряд проблем.
Об этом есть отдельный слайд в презентации. Но самым критичным для нас была невозможность выгрузить сырые данные и гибко управлять сплитами.
Инструменты развиваются. И, возможно, сейчас уже нет такой проблемы в Firebase и ему подобных, но на тот момент ни одно готовое решение нас не устроило.

Зато мы поняли, что сделать инструмент для A/B тестирования самим это не rocket science.

Нужно всего лишь сделать:
- Механизм сплитования
- Апишку
- Админку для настройки фич
- Немного магии на стороне мобильной разработки
- Отчётность

Наши сплиты построены на основе случайной части GA Client ID.
Это случайное число от 0 до 255.
В админке для каждой фича задаются правила сплитов. Например, (0; 127) - фича выключена, (128; 255) - фича включена.

Split ID и правила определяют набор фичей, доступных клиенту.

Этот набор закодирован в Feature_status. Вместо конфига мы используем двоичное число. Каждой фича соответствует свой разряд, который может принимать значения 0 (фича выключена) или 1 (фича включена).

Feature_status пробрасывается в GA в Custom dimension. Число пользовательских параметров в GA ограничено (не больше 20). Но мы не упираемся в этой ограничений, тк занимаем всего один кастомный параметр.

Подробнее о техническом решении расскал великолепный Aleksander Krasnov на AppsConf 🖤

Каждый тест проходит такой цикл:
- Заводим новое правило в админке
- Реализуем логику в коде
- Релизим приложение
- Запускаем тест
- Ждём
- Анализируем результаты
- Принимаем решение, какой вариант остаётся
- Включаем в админке победителя на 100%
- Вычищаем из кода проигравший вариант

По сути мы получили инструмент для A/B тестирования + remote config.

Это позволяет нам проверять гипотезы, отслеживать фактическое влияние запущенных фич на метрики, делать постепенную выкатку функционала.

Для любителей цифр:
- На разработку решения мы потратили суммарно около 280 человеко-часов.
- Примерно на 30% увеличивается стоимость разработки и тестирования, если фича делается через A/B.
- Максимальный ROI дают тесты заголовков, конверсионных подписей, текстов пушей.

Презентация: https://goo.gl/qMi7nZ