Сколько времени занимает проверка гипотезы для мобильного приложения? Давайте посчитаем:


  1. Разработка приложения, работающего в разных режимах для разных групп пользователей.
  2. Тестирование результата.
  3. Выкладывание приложения в магазины приложений и ожидание одобрения.
  4. Ожидание, пока пользователи обновят приложение. В 2019-ом у большинства включено автообновление, но далеко не у всех.
  5. Сбор и анализ статистики.
  6. Приведение приложения к состоянию победившей гипотезы, параллельно с разработкой следующей…

Если ваши разработчики работают по Scrum с двухнедельными итерациями, обычно это означает, что тестирование гипотезы занимает полный месяц. С другими методологиями этот срок можно ужать, но незначительно.


Такое положение дел делает невозможным достижение ритма “5 гипотез в неделю”, к которому стремятся многие продуктовые команды.


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


Поехали.


Включаем и выключаем


Прежде чем погружаться в детали, нужно ввести дополнительный термин — паттерн Feature flag (Feature toggle).


Для читателей без технического бэкграунда могут потребоваться пояснения:


При разработке какой-то новой возможности, программист внедряет в код приложения “переключатель”, активирующий эту возможность. Обычно такое решение используется, чтобы держать недоделанные возможности в выключенном состоянии в общем коде программы, но, разумеется, его можно использовать и для проверки гипотез.

Для использования паттерна Feature flag в проверке эксперимента понадобится:


  1. Полностью разработанная функциональность, над которой нужно провести эксперимент.
  2. Переключатель для неё, в состоянии по умолчанию “Выключено”.
  3. Удалённое управление переключателем с сервера.

Возникает вопрос, на чём экономится время, если функциональность всё равно нужно разработать перед тем, как проводить A/B тесты? Попробуем разобрать по этапам эксперимента:



Что мы здесь видим?


Во-первых, используя Feature flag мы можем выкладывать приложение в магазины приложений до полноценного тестирования на наличие ошибок. Нам только нужно убедиться, что при выключенной новой функциональности приложение ведёт себя как раньше — а это можно сделать ранее написанными автотестами. Остальное можно тестировать пока приложение распространяется среди пользователей.


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


Именно по такому принципу работает сервис Apptimize, предоставляющий готовую систему для A/B тестирования.


Анализируем


Чтобы провести эксперимент, нужно сделать несколько вещей:


  1. Выбрать сегмент пользователей, если эксперимент не для всех.
  2. Выбрать размер аудитории.
  3. Собрать данные, причём не только те, которые проверяются экспериментом. Остальные бизнес-метрики потребуются, чтобы убедиться, что эксперимент ничего не ломает в других показателях.
  4. Собрать и проанализировать результат.

Если не использовать готовое решение от Apptimize, самым простым подходом будет связка Google Analytics for Firebase для аналитики и Firebase Remote Config для задания индивидуальных конфигураций (сегментов и тестов). Эти инструменты приспособлены для совместной работы.


Соответственно нужно:


  1. Использовать Google Analytics for Firebase для отслеживания бизнес-метрик.
  2. Использовать Firebase Remote Config для управления Feature flag’ами.
  3. Использовать Firebase Remote Config для задания сегментов и параметров эксперимента.
  4. Анализировать данные из Google Analytics, используя в анализе ключи из Firebase Remote Config. Эта возможность предусмотрена данными инструментами “из коробки”.

Оптимизируем дальше


Мы разобрали, как сократить цикл проверки гипотез для мобильных приложений, сократив время на тестирование и распространение результатов эксперимента. Но данный подход не позволяет избавиться от времени на одобрение и распространение приложения. Цель “5 гипотез в неделю” с этим подходом по-прежнему мало реальна.


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


С одной стороны, существуют технические ограничения на построение интерфейса по настройкам, получаемым извне. Большинство фреймворков мобильной разработки используют декларативный подход, где это невозможно или очень сложно.


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


Ещё одно ограничение — количество данных, передаваемых из Firebase Remote Config. Он не может использоваться для передачи интерфейса целиком. Оптимально хранить в нём только “ключ” конкретной версии интерфейса, а при изменении этого кода — загружать интерфейс из стороннего сервиса. Само по себе оно не ограничивает выбор фреймворка мобильной разработки, но требует дополнительных усилий по реализации.


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


Технически такой подход проще всего реализуется во фреймворке, который обладает следующими характеристиками:


  1. Реактивный высокопроизводительный пользовательский интерфейс, не использующий по умолчанию декларативный подход.
  2. Поддержка Google Analytics for Firebase и Firebase Remote Config.
  3. Желательно кросс-платформенное решение, для общего ускорения разработки.

Оптимально этим критериям соответствует фреймворк Flutter. В качестве proof-of-concept такого подхода, для него существует библиотека, позволяющая создавать динамический интерфейс.


Используя динамический интерфейс, созданный во Flutter, Google Analytics for Firebase и Firebase Remote Config можно разрабатывать приложения, которые по лёгкости проверки гипотез будут сопоставимы с веб-сайтами.

Комментарии (4)


  1. Oz_Alex
    26.03.2019 07:23

    Когда приложение при обновлении внезапно запрашивает кучу новых разрешений, без которых раньше отлично обходилось, но при этом в функционале ничего не меняется — это оно?


    1. stealthnsk Автор
      26.03.2019 07:36

      Когда приложение запрашивает доступ к сети, если раньше не требовалось, то это может быть оно. А остальное — нет.

      Сейчас магазины приложений не позволяют приложениям собирать больше персональной информации, чем они могут разумно обосновать — из-за законов типа GDPR. Просто начать собирать дополнительные данные для аналитики приложение не может.


  1. SeoPitcher
    27.03.2019 05:44

    У нас пол года заняло внедрить и адекватно настроить функционал А/Б тестирования в андроид приложении. А сколько крашей было.
    Без стальных нервов и ящика виски, очень трудно будет такой функционал настроить.


    1. stealthnsk Автор
      27.03.2019 05:47

      ИМХО, это вопрос архитектуры кода, в первую очередь. Разработчики, с которыми я сейчас работаю, активно используют Feature Flag и вне проверки гипотез. Когда в этом месте нет проблем, дальше уже должно быть легко.