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


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


    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
      Когда приложение при обновлении внезапно запрашивает кучу новых разрешений, без которых раньше отлично обходилось, но при этом в функционале ничего не меняется — это оно?
        +2
        Когда приложение запрашивает доступ к сети, если раньше не требовалось, то это может быть оно. А остальное — нет.

        Сейчас магазины приложений не позволяют приложениям собирать больше персональной информации, чем они могут разумно обосновать — из-за законов типа GDPR. Просто начать собирать дополнительные данные для аналитики приложение не может.
        0
        У нас пол года заняло внедрить и адекватно настроить функционал А/Б тестирования в андроид приложении. А сколько крашей было.
        Без стальных нервов и ящика виски, очень трудно будет такой функционал настроить.
          0
          ИМХО, это вопрос архитектуры кода, в первую очередь. Разработчики, с которыми я сейчас работаю, активно используют Feature Flag и вне проверки гипотез. Когда в этом месте нет проблем, дальше уже должно быть легко.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое