RuStore Remote Config: основы, быстрый старт и руководство по управлению конфигурацией
RuStore Remote Config — инструмент для удаленного управления конфигурацией мобильных приложений. Он доступен на платформах Android и IOS. Для Android-платформы вам понадобится аккаунт в RuStore.
Для добавления IOS-приложения, аккаунт в RuStore не нужен. Читайте подробнее тут как подключить IOS-приложения и работать с ними.
Также доступны SDK под платформу Android для популярных игровых движков, таких как Unity, Unreal и других. Инструкции по интеграции SDK смотрите тут.
У Remote Config есть два основных сценария использования. В зависимости от того, какой вы хотите реализовать, для вас будут отличаться необходимые шаги по настройке системы.
-
Менеджмент фичей (feature toggle). Позволяет включать и выключать фичи вашего приложения для определенных групп пользователей. С помощью условий вы определяете, для кого включать, а для кого выключать функции. Например, это могут быть условия, связанные с моделью устройства, версией операционной системы или желанием развернуть функцию только для половины пользователей.
Нео бходимый минимум для менеджмента фичей:
Интеграция SDK > Создание/Подключение приложения > Создание параметра > Создание условия > Встраивание параметра в код приложения.
-
А/В-эксперименты в вашем приложении. Вы можете запустить тест нового дизайна или открыть новую фичу на определенный процент пользователей, а затем следить за изменениями метрик вашего приложения. Таким образом, вы сначала видите результат ваших изменений на небольшой группе пользователей и только после этого решаете, разворачивать ли эту функциональность на всех или это неудачная идея.
Необходимый минимум для А/В-экспериментов:
Интеграция SDK > Создание/Подключение приложения > Создание параметра > Встраивание параметра в код приложения > Подключение аккаунта MyTracker > Создание метрики > Создание и запуск эксперимента.
Как видите, для А/В-экспериментов требуется почти все действия по менеджменту фичей, кроме условий. Это связано с тем, что в эксперименте у вас будут отдельные условия, наложенные на параметры.
Вы можете использовать инструмент для А/В-экспериментов и для менеджмента фичей одновременно. Сценарии не исключают друг друга. Особенность заключается в том, что если вы используете параметр в эксперименте, то для указанной вами группы пользователей на время эксперимента параметр будет получать значения исходя из условий эксперимента, а не из условий, наложенных напрямую на параметр в сценарии менеджменте фичей.
Шаг 1. Подключение SDK
Подключение SDK зависит от вашей платформы и фреймворка. Все инструкции по SDK доступны тут.
Кроме инструкций по подключению SDK, у нас также есть библиотека с примерами приложений с интегрированным SDK. Она находится в нашем репозитории GitFlic.
Важно понимать, что аудиторию в Remote Config можно делить в процентах по Device Id
или Account
. После этого вы определяете дополнительные условия для таргетинга, например, версию Android, версию приложения и другие.
Device Id
— единственный параметр, который SDK Remote Config генерирует самостоятельно. Остальные параметры необходимо явно передавать в SDK, если вы хотите использовать их в приложении. Более подробно об этом читайте тут (пример для Kotlin).
Шаг 2. Настройка параметра
Параметр – это переменная, через которую вы будете управлять функциональностью приложения.
Вы создаете параметр внутри интерфейса Remote Config, а затем добавляете его в код своего приложения и завязываете на него логику.
При этом вы можете изначально завести параметр в коде вашего приложения, а потом добавить его в интерфейс Remote Config. Это не принципиальный момент.
Важно понимать, что если вы создали параметр в Remote Config и у вас уже подключено наше SDK, то на устройства ваших пользователей начнет передаваться конфиг с этим параметром. После создания задержки практически нет и раскатка параметра происходит в «реальном времени».
К примеру, вы можете создать параметр Button_12_Color
и он у вас будет отвечать за цвет кнопки.
После создания вы можете назначить параметру условия и определить возможные его значения. Таким образом создается логика раскатки параметра.
В нашем примере Button_12_Color = red
для пользователей с OS Android < 12, а для остальных пользователей Button_12_Color = pink
.
В сценарии, когда вы хотите провести А/В-эксперимент, вам не нужно сразу назначать условия на параметр. Вы сможете определить условия для раскатки параметра при запуске А/В-эксперимента.
Подробная инструкция по созданию параметра находится тут.
Для параметров можно настроить функцию обязательного подтверждения. При включённой настройке параметры будут создаваться со статусом «Pending» и не будут сразу раскатываться на устройства конечных пользователей. Для раскатки потребуется дополнительно подтвердить параметр в Remote Config. Это сможет сделать только пользователь с соответствующими правами. Таким образом, реализуется механизм подтверждения и контроля, когда один пользователь создает параметр, а другой проверяет и подтверждает его. Обычно такая функция нужна в крупных компаниях и по умолчанию он отключён для всех новых пользователей. Подробнее про него можно почитать тут.
Шаг 3. Настройка условий
Условия используются для настройки параметров под определённую аудиторию. Это может быть как простое раскрытие или сокрытие функциональности, так и проведение А/В-теста.
Если вы планируете провести А/В-тест с параметром, вы можете пропустить этот шаг и настроить логику изменения параметра непосредственно в А/В-эксперименте.
Если вы планируете выкатывать параметр и вам нужно настроить логику изменения параметра для разных аудиторий, вам потребуется создать условие и связать его с параметром. Подробнее об этом читайте на этой странице.
Для условий, как и для параметров, можно включить функцию обязательного подтверждения. Обычно эта функция нужна в крупных компаниях и по умолчанию отключена для всех новых пользователей. Подробнее о ней можно прочитать тут.
После создания параметров и настройки условий вы получите готовую систему для удалённого управления функциональностью вашего приложения. Но если вы хотите проводить А/В-тесты в вашем приложении, вам нужно также подключить MyTracker для сбора аналитических событий из вашего приложения и создать метрики для отслеживания прогресса ваших А/В-экспериментов. Об этом читайте в следующих шагах.
Архитектура системы позволяет связывать одно условие с несколькими параметрами. Эта функциональность может понадобиться, когда условий и параметров становится много. Важно помнить, что при таком подходе изменение одного условия может повлиять сразу на несколько параметров в системе.
Шаг 4. MyTracker
Чтобы не только внедрять новые функции по определённым правилам, но и понимать, как различные варианты функций влияют на вашу аудиторию, мы предлагаем провод ить A/B-тесты. Если опустить технические детали, то A/B-тест — это наиболее научный метод для демонстрации успешности новой версии функции по сравнению со старой.
Именно поэтому мы предлагаем вам попробовать эту функциональность для вашего приложения.
В первую очередь нам понадобятся аналитические данные, на основе которых мы затем сформируем метрики для вашего приложения. Для этого вам необходимо подключиться к системе MyTracker. Вы можете сделать это через сервис инструментов в консоли RuStore. Инструкция находится тут.
После регистрации нового аккаунта в MyTracker или подключения существующего, вам потребуется создать объект приложения в MyTracker и подключить SDK. Более подробную информацию читайте в гайде от MyTracker.
После этого вам нужно определить, какие события вы хотите собирать из своего приложения и отправлять в MyTracker. Здесь вы найдёте полезную статью о том, как подойти к этому с м етодологической точки зрения, а здесь (для Android) и здесь (для iOS) — как это сделать технически.
После настройки отправки событий в коде будет полезно в течение нескольких дней наблюдать за тем, как эти события поступают и отображаются в вашем личном кабинете в MyTracker. События в MyTracker приходят в течение нескольких часов после их срабатывания в вашем приложении.
Шаг 5. Метрика
После того как вы настроили отправку событий в MyTracker, можно создавать метрики и использовать их в экспериментах. Про работу с метриками в Remote Config читайте в отдельном разделе.
Метрики нужны для фиксации изменений, которые создаёт ваш эксперимент. Например, вы запустили эксперимент на неделю и видите, что у одной группы пользователей метрика упала, а у другой — нет. Это означает, что с ледует обратить внимание на падение и проанализировать результаты эксперимента.
Технически можно запустить эксперимент и без метрик, но тогда придётся разделить аудиторию на группы и раздать им разные значения. Вопрос о том, какое значение оказалось более успешным, остаётся открытым. Поэтому следует использовать метрики как понятную и удобную основу для анализа результатов экспериментов.
Шаг 6. Эксперименты
Когда у вас подключен SDK, параметры встроены в код приложения и собираются метрики, вы можете проводить A/B-тесты. Подробная информация о запуске тестов представлена на этой странице. После запуска вам необходимо проанализировать результаты и сделать выводы. Об этом читайте на этой странице.
В целом, это всё, о чём нужно знать в начале работы с RuStore Remote Config. Вы всегда можете обратиться к нам на support@rustore.ru, если возникнут трудности. Мы будем рады помочь.
Также предлагаем вам посмотреть запись митапа, где мы рассказываем о том, как запускать эксперименты и анализировать результаты.