Как стать автором
Обновить

Особенности проверки гипотез для мобильных приложений

Время на прочтение4 мин
Количество просмотров6.4K


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


  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 можно разрабатывать приложения, которые по лёгкости проверки гипотез будут сопоставимы с веб-сайтами.

Теги:
Хабы:
Всего голосов 7: ↑7 и ↓0+7
Комментарии4

Публикации

Истории

Работа

Ближайшие события

15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань