Особенности Проверки Гипотез Для Мобильных Приложений



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

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

  1. Разработка приложения, работающего в разных режимах для разных групп пользователей.

  2. Тестирование результата.

  3. Загружаем приложение в магазины приложений и ждем одобрения.

  4. Ожидание, пока пользователи обновят приложение.

    В 2019 году у большинства из них включено автоматическое обновление, но не у всех.

  5. Сбор и анализ статистики.

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

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

При использовании других методик этот период можно сократить, но незначительно.

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

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

Идти.



Включите и выключите его

Прежде чем углубиться в подробности, нам необходимо ввести дополнительный термин – Шаблон флага функции (переключение функции) .

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

При разработке новой функции программист реализует в коде приложения «переключатель», активирующий эту функцию.

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

Чтобы использовать шаблон флага функции при тестировании эксперимента, вам потребуется:
  1. Полностью разработанный функционал, с которым нужно экспериментировать.

  2. Переключатель для него находится в состоянии по умолчанию «Выкл.

    ».

  3. Удаленное управление коммутатором с сервера.

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

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

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

Нам просто нужно убедиться, что при отключении нового функционала приложение ведет себя как прежде — и это можно сделать заранее написанными автотестами.

Остальное можно протестировать, пока приложение распространяется среди пользователей.

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

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



Анализируя

Для проведения эксперимента необходимо сделать несколько вещей:
  1. Выберите сегмент пользователей, если эксперимент подойдет не всем.

  2. Выберите размер аудитории.

  3. Собирайте данные, и не только те, которые проверены экспериментом.

    Остальные бизнес-метрики понадобятся для того, чтобы эксперимент ничего не нарушил в других метриках.

  4. Соберите и проанализируйте результаты.

Если вы не используете готовое решение от Apptimize, проще всего будет связать Google Аналитика для Firebase для аналитики и Удаленная конфигурация Firebase задавать индивидуальные конфигурации (сегменты и тесты).

Эти инструменты созданы для совместной работы.

Соответственно вам необходимо:

  1. Используйте Google Analytics для Firebase для отслеживания бизнес-показателей.

  2. Используйте Firebase Remote Config для управления флагами функций.

  3. Используйте Firebase Remote Config, чтобы задать сегменты и параметры эксперимента.

  4. Анализируйте данные из Google Analytics, используя в анализе ключи из Firebase Remote Config. Такую возможность предоставляют данные инструменты «из коробки».



Давайте оптимизировать дальше

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

Но такой подход не устраняет время, необходимое для одобрения и распространения заявки.

Цель «5 гипотез в неделю» при таком подходе все еще не очень реалистична.

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

Этого можно достичь с помощью динамического пользовательского интерфейса.

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

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

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

Еще одним ограничением является объем данных, передаваемых из Firebase Remote Config. Его нельзя использовать для передачи всего интерфейса.

Оптимально хранить в нем только «ключ» конкретной версии интерфейса, а при изменении этого кода загружать интерфейс со стороннего сервиса.

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

Оптимальным решением представляется подход, при котором динамически строится только пользовательский интерфейс, а бизнес-логика остается неизменной.

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

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

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

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

Фреймворк Flutter лучше всего соответствует этим критериям.

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

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

Теги: #управление продуктом #A/B-тестирование #A/B-тестирование #ab-тестирование #мобильная аналитика #flutter #Firebase #firebase Analytics #apptimize #удаленная настройка Firebase #Управление продуктом #Управление продуктом #Веб-аналитика #Взлом роста # Аналитика мобильных приложений #Управление продуктом #futter

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.