Создание экспериментов с удаленной конфигурацией Firebase с помощью A/B-тестирования

При использовании Firebase Remote Config для развертывания настроек приложения с активной базой пользователей важно убедиться в правильности настроек. Для определения следующих параметров можно использовать A/B Testing :

• Лучший способ внедрить функцию — оптимизировать пользовательский опыт. Слишком часто разработчики приложений узнают о том, что пользователям не нравится новая функция или обновленный пользовательский интерфейс, только когда рейтинг их приложения в App Store падает. A/B Testing может помочь определить, нравятся ли пользователям новые варианты функций или они предпочитают приложение в его текущем виде. Кроме того, сохранение большинства пользователей в базовой группе гарантирует, что большая часть вашей пользовательской базы сможет продолжать использовать ваше приложение без каких-либо изменений в его поведении или внешнем виде до завершения эксперимента.
• Лучший способ оптимизировать пользовательский опыт для достижения бизнес-цели. Иногда вы вносите изменения в продукт, чтобы максимизировать такие показатели, как доход или удержание клиентов. С помощью A/B Testing вы устанавливаете свою бизнес-цель, а Firebase выполняет статистический анализ, чтобы определить, превосходит ли вариант базовый показатель по выбранной вами цели.

Для A/B-тестирования вариантов функций с использованием базового варианта выполните следующие действия:

1. Создайте свой эксперимент.
2. Управляйте своим экспериментом.

Создайте эксперимент

Эксперимент Remote Config позволяет оценить несколько вариантов одного или нескольких параметров Remote Config .

1. Убедитесь, что Google Analytics включен в вашем проекте, чтобы эксперимент имел доступ к данным Analytics .

   Если вы не включили Google Analytics при создании проекта, вы можете включить его в настройках проекта. settings > Вкладка «Интеграции» в консоли Firebase .

2. В консоли Firebase перейдите в раздел DevOps & Engagement > A/B Testing

3. Нажмите «Создать эксперимент» , а затем, когда появится запрос на выбор службы, с которой вы хотите поэкспериментировать, выберите Remote Config .

4. В разделе «Варианты» выберите базовый вариант и как минимум один вариант для эксперимента. Вы можете добавить один или несколько параметров для эксперимента. Вы можете повторить этот шаг, чтобы добавить несколько параметров в свой эксперимент.

5. (Необязательно) Чтобы добавить в эксперимент более одного варианта, нажмите « Добавить еще один вариант» .

6. Измените один или несколько параметров для конкретных вариантов. Все неизмененные параметры останутся неизменными для пользователей, не участвовавших в эксперименте.

7. Разверните раздел «Вес вариантов» , чтобы просмотреть или изменить вес вариантов для эксперимента. По умолчанию каждый вариант имеет одинаковый вес. Обратите внимание, что неравные веса могут увеличить время сбора данных, и изменить их после начала эксперимента будет невозможно .

8. Определите критерии таргетинга для вашего эксперимента, используя условия Remote Config :

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

   • Проверьте порядок оценки условий: убедитесь, что условия на странице «Условия» расположены в правильном порядке приоритета. Поскольку Remote Config оценивает условия последовательно сверху вниз, другие условия с более высоким приоритетом могут помешать достаточному количеству пользователей достичь условия, связанного с вашим экспериментом.

   • Создайте новое условие: если ни одно из существующих условий не удовлетворяет вашим требованиям к таргетингу, или если вы предпочитаете продублировать существующее условие (например, чтобы избежать блокировки условия, используемого другими параметрами), создайте новое условие, сначала выбрав приложение, использующее ваш эксперимент. Если тестируемый параметр также использует существующее (или другое совпадающее) условие, убедитесь, что новое условие эксперимента размещено выше существующего условия на вкладке «Условия» (присвоив ему более высокий приоритет оценки); в противном случае пользователи будут соответствовать существующему условию в первую очередь и не попадут в эксперимент.

     Затем вы можете выбрать определенную подгруппу пользователей, нажав кнопку и выбрав один или несколько вариантов из следующего списка:

     • Версия: Одна или несколько версий вашего приложения
     • Номер сборки: номер сборки (Apple) или код версии (Android) вашего приложения.
     • Платформа: Одна или несколько платформ (iOS, Android или Web) для таргетирования.
     • Операционная система: Нацеливание на пользователей веб-приложения на основе их операционной системы и версии.
     • Браузер: Нацеливание на пользователей веб-приложения на основе их веб-браузера и версии браузера.
     • Категория устройства: Нацеливайте рекламу на пользователей веб-приложения в зависимости от того, мобильное у них устройство или нет.
     • Языки: Один или несколько языков и региональных настроек, используемых для отбора пользователей, которые могут быть включены в эксперимент.
     • Страна/Регион: Одна или несколько стран или регионов для отбора пользователей, которых следует включить в эксперимент.
     • Целевая аудитория пользователей: Analytics аудитории, используемые для таргетирования пользователей, которые могут быть включены в эксперимент.
     • Свойство пользователя: Одно или несколько свойств пользователя Analytics для выбора пользователей, которые могут быть включены в эксперимент.
     • Пользователь в случайном процентном соотношении: Нацелить случайный процент пользователей в заданном процентильном диапазоне.
     • Импортированный сегмент: Целевые пользователи, принадлежащие к пользовательским импортированным сегментам, загруженным в ваш проект.
     • Дата/время: Нацеливание на пользователей на основе указанного временного интервала и даты.
     • Первое открытие: Нацеливайте таргетинг на пользователей в зависимости от того, когда они впервые открыли ваше приложение.
     • Идентификатор установки: Укажите целевые тестовые устройства или экземпляры клиентов, используя их идентификаторы установки Firebase (FID).
     • Пользователь существует: Нацелить на всех пользователей во всех приложениях проекта.
     • Пользовательский сигнал: Нацеливание на пользователей на основе пользовательских сигналов ключ-значение на стороне клиента, передаваемых во время выполнения.

9. Установите охват: введите процент пользователей вашего приложения, соответствующих критериям, заданным в разделе «Целевые пользователи» , который вы хотите равномерно распределить между базовой группой и одним или несколькими вариантами в вашем эксперименте. Это может быть любой процент от 0% до 100%. Пользователи случайным образом назначаются каждому эксперименту, включая дублирующиеся эксперименты.

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

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

    • app_install
    • app_remove
    • app_update

    Выбранное вами событие Analytics в качестве события активации не должно также использоваться в качестве основной метрики (или в качестве дополнительной метрики) в том же эксперименте. В противном случае в консоли Firebase возникнет ошибка проверки, и запуск эксперимента будет невозможен.

11. В разделе «Цели» эксперимента выберите основной показатель для отслеживания и добавьте из списка любые дополнительные показатели, которые вы хотите отслеживать. К ним относятся встроенные цели (покупки, доход, удержание пользователей, у которых не было сбоев и т. д.), события конверсии Analytics и другие события Analytics . После завершения нажмите «Далее» .

12. Нажмите «Сохранить» , чтобы сохранить эксперимент. Для начала проведения эксперимента необходимо опубликовать шаблон.

В рамках одного проекта разрешается проводить до 300 экспериментов (включая этапы внедрения), из которых до 24 могут быть текущими экспериментами и этапами внедрения, а остальные — завершенными.

Управляйте своим экспериментом

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

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

Редактировать эксперимент

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .
3. Нажмите «Запуск» , затем выберите эксперимент, который хотите отредактировать.
4. Щелкните контекстное меню ( more_vert ) и выберите «Редактировать запущенный эксперимент» .
5. Чтобы убедиться, что в вашем приложении есть пользователи, которые подойдут для вашего эксперимента, разверните подробную информацию и проверьте, не превышает ли число 0% в разделе «Таргетинг и распределение» (например, 1% пользователей, соответствующих критериям ).

Мониторинг эксперимента

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

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .

3. Нажмите «Бег» , а затем выберите или найдите название вашего эксперимента. На этой странице вы можете просмотреть различные наблюдаемые и смоделированные статистические данные о вашем эксперименте по бегу, включая следующие:

   • Процентное отклонение от базового уровня : Показатель улучшения метрики для данного варианта по сравнению с базовым уровнем. Рассчитывается путем сравнения диапазона значений для варианта с диапазоном значений для базового уровня.
   • Вероятность превзойти базовый показатель : оценочная вероятность того, что данный вариант превзойдет базовый показатель по выбранной метрике.
   • observed_metric per user : На основе результатов эксперимента это прогнозируемый диапазон, в который будет попадать значение метрики с течением времени.
   • Total observed_metric : Накопленное значение для базового варианта или варианта. Это значение используется для оценки эффективности каждого варианта эксперимента и применяется для расчета показателей улучшения , диапазона значений , вероятности превзойти базовый вариант и вероятности стать лучшим вариантом . В зависимости от измеряемого показателя, этот столбец может быть обозначен как «Длительность на пользователя», «Доход на пользователя», «Коэффициент удержания» или «Коэффициент конверсии».

4. После того, как ваш эксперимент продлится некоторое время (14 дней для Remote Config ), данные на этой странице укажут, какой вариант, если таковой имеется, является «лидером». Некоторые измерения сопровождаются гистограммой, которая представляет данные в визуальном формате.

Провести эксперимент для всех пользователей.

После того, как эксперимент продлится достаточно долго и выявите «лидера», или выигрышный вариант, для целевого показателя, вы можете запустить эксперимент для 100% пользователей. Это позволит вам выбрать вариант, который будет доступен всем пользователям в дальнейшем. Даже если ваш эксперимент не выявил явного победителя, вы все равно можете выбрать вариант, доступный всем пользователям.

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .
3. Нажмите «Завершено» или «Выполняется» , выберите эксперимент, который хотите запустить для всех пользователей, затем нажмите контекстное меню ( more_vert ) и выберите «Развернуть вариант» .
4. Для запуска эксперимента на всех пользователях выполните следующие действия:
   • Для эксперимента Remote Config выберите вариант, чтобы определить, какие значения параметров Remote Config следует обновить. Критерии таргетинга, определенные при создании эксперимента, добавляются в качестве нового условия в ваш шаблон, чтобы гарантировать, что развертывание затронет только пользователей, на которых направлен эксперимент. После нажатия кнопки «Просмотреть» в разделе «Удаленная конфигурация» для проверки изменений, нажмите кнопку «Опубликовать изменения» , чтобы завершить развертывание.

Расширить эксперимент

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

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .
3. Выберите запущенный эксперимент, который хотите отредактировать.
4. В разделе «Обзор эксперимента» щелкните контекстное меню ( more_vert ), а затем выберите «Редактировать запущенный эксперимент» .
5. В диалоговом окне «Таргетинг» отображается возможность увеличить процент пользователей, участвующих в текущем эксперименте. Выберите число, превышающее текущий процент, и нажмите «Опубликовать» . Эксперимент будет запущен для указанного вами процента пользователей.

Повторите эксперимент

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .
3. Выберите текущий или завершенный эксперимент, который вы хотите остановить.
4. Нажмите «Завершено» или «Выполняется» , наведите указатель мыши на свой эксперимент, щелкните контекстное меню ( more_vert ), а затем выберите «Дублировать эксперимент» или «Остановить эксперимент» .

Прекратите эксперимент

1. В разделе DevOps & Engagement навигационного меню консоли Firebase нажмите Remote Config .
2. Перейдите во вкладку «A/B-тесты» .
3. Выберите текущий или завершенный эксперимент, который вы хотите остановить.
4. Нажмите «Завершено» или «Выполняется» , наведите указатель мыши на эксперимент, щелкните контекстное меню ( more_vert ), а затем нажмите «Остановить эксперимент» .

Идентификация веб-клиента и сохранение результатов экспериментов

Когда пользователь впервые запускает веб-приложение с использованием Firebase A/B Testing в браузере, генерируется уникальный идентификатор установки Firebase (FID). Этот FID постоянно хранится в IndexedDB браузера для идентификации экземпляра приложения в разных сессиях.

Firebase A/B Testing идентификатор FID используется для распределения пользователей по вариантам эксперимента, а Google Analytics — для агрегации событий с целью измерения и анализа поведения пользователей в каждом варианте.

Поскольку идентификатор приложения (FID) хранится в IndexedDB, Firebase A/B Testing рассматривает пользователя как нового, если он заходит в ваше приложение из другого браузера или в режиме инкогнито, или если он очищает IndexedDB своего браузера. Это означает, что пользователь может быть включен в разные варианты эксперимента при использовании разных браузеров или сеансов просмотра.

Целевой пользователь

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

В консоли Firebase поддерживаются следующие типы правил. Аналогичные функции доступны в REST API Remote Config , как подробно описано в справочнике по условным выражениям .

Метрики A/B Testing

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

Например, предположим, вы используете Remote Config для запуска двух разных игровых сценариев в вашем приложении и хотите оптимизировать их для внутриигровых покупок и дохода от рекламы, но также хотите отслеживать стабильность и удержание пользователей каждого варианта. В этом случае вы можете выбрать «Предполагаемый общий доход» в качестве целевого показателя, поскольку он включает доход от внутриигровых покупок и доход от рекламы, а затем в поле «Другие показатели для отслеживания » вы можете добавить следующее:

• Для отслеживания ежедневного и еженедельного удержания пользователей добавьте показатели «Удержание (2-3 дня)» и «Удержание (4-7 дней)» .
• Для сравнения стабильности работы двух игровых процессов добавьте пользователей, у которых не было сбоев .
• Для получения более подробной информации о каждом типе дохода добавьте доходы от покупок и предполагаемые доходы от рекламы .

В приведенных ниже таблицах подробно описано, как рассчитываются целевые показатели и другие метрики.

Целевые показатели

Другие показатели

экспорт данных BigQuery

Помимо просмотра данных экспериментов A/B Testing в консоли Firebase , вы можете проверять и анализировать данные экспериментов в BigQuery . Хотя для A/B Testing нет отдельной таблицы BigQuery , информация о принадлежности к экспериментам и вариантам хранится в таблицах событий Google Analytics Analytics .

Свойства пользователя, содержащие информацию об эксперименте, имеют вид userProperty.key like "firebase_exp_%" или userProperty.key = "firebase_exp_01" где 01 — идентификатор эксперимента, а userProperty.value.string_value содержит (начиная с нуля) индекс варианта эксперимента.

Вы можете использовать эти пользовательские свойства эксперимента для извлечения данных эксперимента. Это дает вам возможность анализировать результаты эксперимента различными способами и независимо проверять результаты A/B Testing .

Для начала выполните следующие действия, как описано в этом руководстве:

1. Включите экспорт BigQuery для Google Analytics в консоли Firebase.
2. Получите доступ к данным A/B Testing с помощью BigQuery
3. Изучите примеры запросов.

Включите экспорт BigQuery для Google Analytics в консоли Firebase.

Если вы используете тарифный план Spark, вы можете бесплатно использовать песочницу BigQuery для доступа к BigQuery , с учетом ограничений песочницы . Дополнительную информацию см. в разделах «Цены» и «Песочница BigQuery .

Во-первых, убедитесь, что вы экспортируете данные Analytics в BigQuery :

1. В консоли Firebase перейдите в... settings > Вкладка «Интеграции» .

2. В карточке BigQuery нажмите «Управление» и убедитесь, что ваш проект экспортирует данные Analytics в BigQuery .

   Если на карточке написано «Ссылка» , значит, вам нужно настроить экспорт (перейдите к следующему шагу).

3. Если вам необходимо настроить экспорт:

   1. Ознакомьтесь с информацией о подключении Firebase к BigQuery , затем нажмите «Далее» .

   2. В разделе «Настройка интеграции» включите Google Analytics .

   3. Выберите регион и укажите параметры экспорта.

   4. Перейдите по ссылке на BigQuery .

В зависимости от выбранного вами способа экспорта данных, доступность таблиц может занять до суток. Для получения дополнительной информации об экспорте проектных данных в BigQuery см. раздел «Экспорт проектных данных в BigQuery .

Доступ к данным A/B Testing в BigQuery

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

• Идентификатор эксперимента: его можно получить из URL-адреса страницы обзора эксперимента . Например, если ваш URL-адрес выглядит так: https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 , то идентификатор эксперимента равен 25 .
• Идентификатор ресурса Google Analytics : это ваш 9-значный идентификатор ресурса Google Analytics . Вы можете найти его в Google Analytics ; он также отображается в BigQuery когда вы разворачиваете название своего проекта, чтобы показать название вашей таблицы событий Google Analytics ( project_name.analytics_000000000.events ).
• Experiment date: To compose a faster and more efficient query, it's good practice to limit your queries to the Google Analytics daily event table partitions that contain your experiment data—tables identified with a YYYYMMDD suffix. So, if your experiment ran from February 2, 2024 through May 2, 2024, you'd specify a _TABLE_SUFFIX between '20240202' AND '20240502' . For an example, see Select a specific experiment's values .
• Event names: Typically, these correspond with your goal metrics that you configured in the experiment. For example, in_app_purchase events, ad_impression , or user_retention events.

After you gather the information you need to generate your query:

1. In the Google Cloud console, go to BigQuery .
2. Select your project, then select Create SQL query .
3. Add your query. For example queries to run, see Explore example queries .
4. Click Run .

Query experiment data using the Firebase console's auto-generated query

If you're using the Blaze plan, the Experiment overview page provides a sample query that returns the experiment name, variants, event names, and the number of events for the experiment you're viewing.

To obtain and run the auto-generated query:

1. In the Firebase console, go to DevOps & Engagement > A/B Testing .
2. Select the A/B Testing experiment you want to query to open the Experiment overview .
3. From the Options menu, beneath BigQuery integration , select Query experiment data . This opens your project in BigQuery within the Google Cloud console console and provides a basic query you can use to query your experiment data.

The following example shows a generated query for an experiment with three variants (including the baseline) named "Winter welcome experiment." It returns the active experiment name, variant name, unique event, and event count for each event. Note that the query builder doesn't specify your project name in the table name, as it opens directly within your project.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName

1. Verify that Google Analytics is enabled in your project so that the experiment has access to Analytics data.

   If you didn't enable Google Analytics when creating your project, you can enable it in the settings Settings > Integrations tab of the Firebase console.

2. In the Firebase console, go to DevOps & Engagement > A/B Testing

3. Click Create experiment , and then select Remote Config when prompted for the service you want to experiment with.

4. In the Variants section, choose a baseline and at least one variant for the experiment. You can add one or more parameters to experiment with. You can repeat this step to add multiple parameters to your experiment.

5. (optional) To add more than one variant to your experiment, click Add another variant .

6. Change one or more parameters for specific variants. Any unchanged parameters are the same for users not included in the experiment.

7. Expand Variant Weights to view or change variant weight for the experiment. By default, each variant is weighted equally. Note that uneven weights may increase data collection time and weights cannot be changed after the experiment begins .

8. Define the Targeting criteria for your experiment using Remote Config conditions:

   • Reuse an existing condition: If an existing condition in your Remote Config template already matches your target audience, select it from the list.

   • Verify condition evaluation order: Make sure your conditions on the Conditions page are organized in the correct priority order. Because Remote Config evaluates conditions sequentially from top to bottom, other higher-priority condition(s) can prevent sufficient users from reaching the condition associated with your experiment.

   • Create a new condition: If no existing condition satisfies your targeting requirements, or if you prefer to duplicate an existing condition (for example, to avoid locking a condition that is shared by other parameters), create a new condition by first choosing the app that uses your experiment. If the parameter you are testing also uses the existing (or another overlapping) condition, make sure the new experiment condition is placed above the existing condition on the Conditions tab (giving it higher evaluation priority); otherwise, users will match the existing condition first and won't flow into the experiment.

     You can then target a specific subset of users by clicking and and selecting one or more options from the following list:

     • Version: One or more versions of your app
     • Build number: The build number (Apple) or version code (Android) of your app
     • Platform: One or more platforms (iOS, Android, or Web) to target
     • Operating system: Target web app users based on their operating system and version
     • Browser: Target web app users based on their web browser and browser version
     • Device category: Target web app users based on whether their device is mobile or non-mobile
     • Languages: One or more languages and locales used to select users who might be included in the experiment
     • Country/Region: One or more countries or regions for selecting users who should be included in the experiment
     • User audience: Analytics audiences used to target users who might be included in the experiment
     • User property: One or more Analytics user properties for selecting users who might be included in the experiment
     • User in random percentage: Target a randomly selected percentage of users within a defined percentile range
     • Imported segment: Target users who belong to custom imported segments uploaded to your project
     • Date/Time: Target users based on a specified date and time window
     • First open: Target users based on the first time they ever opened your app
     • Installation ID: Target specific test devices or client instances using their Firebase Installation IDs (FIDs)
     • User exists: Target all users across all apps in the project
     • Custom signal: Target users based on custom client-side key-value signals passed at runtime

9. Set the Exposure: Enter the percentage of your app's user base matching the criteria set under Target users that you want to evenly divide between the baseline and one or more variants in your experiment. This can be any percentage between 0% and 100%. Users are randomly assigned to each experiment, including duplicated experiments.

10. Optionally, set an activation event to ensure that only the data from users who have first triggered some Analytics event are counted in your experiment. Note that all users matching your targeting parameters will receive Remote Config experimental values, but only those who trigger an activation event will be included in your experiment results.

    To ensure a valid experiment, make sure that the event you choose occurs after your app activates fetched configuration values. In addition, the following events cannot be used because they always occur before fetched values are activated:

    • app_install
    • app_remove
    • app_update

    The Analytics event you select as the activation event must not also be used as the primary metric (or as an additional metric) in the same experiment. Doing so will trigger a validation error in the Firebase console and prevent your experiment from launching.

11. For the experiment's Goals , select the primary metric to track, and add any additional metrics you want to track from the list. These include built-in objectives (purchases, revenue, retention, crash-free users, etc.), Analytics conversion events, and other Analytics events. When finished, click Next .

12. Click Save to save your experiment. You must publish the template to start running your experiment.

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments.

Manage your experiment

When you create an experiment with Remote Config , you can start your experiment, monitor your experiment while it is running, and increase the number of users included in your running experiment.

When your experiment is done, you can take note of the settings used by the winning variant, and then roll out those settings to all users. Or, you can run another experiment.

Edit an experiment

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.
3. Click Running , click an experiment that you want to edit.
4. Click the context menu ( more_vert ) and click Edit running experiment .
5. To validate that your app has users who would be included in your experiment, expand the details and check for a number greater than 0% in the Targeting and distribution section (for example, 1% of users matching the criteria ).

Monitor an experiment

Once an experiment has been running for a while, you can check in on its progress and see what your results look like for the users who have participated in your experiment so far.

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.

3. Click Running , and then click, or search for, the title of your experiment. On this page, you can view various observed and modeled statistics about your running experiment, including the following:

   • % difference from baseline : A measure of the improvement of a metric for a given variant as compared to the baseline. Calculated by comparing the value range for the variant to the value range for the baseline.
   • Probability to beat baseline : The estimated probability that a given variant beats the baseline for the selected metric.
   • observed_metric per user : Based on experiment results, this is the predicted range that the metric value will fall into over time.
   • Total observed_metric : The observed cumulative value for the baseline or variant. The value is used to measure how well each experiment variant performs, and is used to calculate Improvement , Value range , Probability to beat baseline , and Probability to be the best variant . Depending on the metric being measured, this column may be labeled "Duration per user," "Revenue per user," "Retention rate," or "Conversion rate."

4. After your experiment has run for a while (14 days for Remote Config ), data on this page indicates which variant, if any, is the "leader." Some measurements are accompanied by a bar chart that presents the data in a visual format.

Roll out an experiment to all users

After an experiment has run long enough that you have a "leader," or winning variant, for your goal metric, you can release the experiment to 100% of users. This lets you select a variant to publish to all users moving forward. Even if your experiment has not created a clear winner, you can still choose to release a variant to all of your users.

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.
3. Click Completed or Running , click an experiment that you want to release to all users, click the context menu ( more_vert ) Roll out variant .
4. Roll out your experiment to all users by doing the following:
   • For a Remote Config experiment, select a variant to determine which Remote Config parameter values to update. The targeting criteria defined when creating the experiment is added as a new condition in your template, to ensure the rollout only affects users targeted by the experiment. After clicking Review in Remote Config to review the changes, click Publish changes to complete the rollout.

Expand an experiment

If you find that an experiment isn't bringing in enough users for A/B Testing to declare a leader, you can increase distribution of your experiment to reach a larger percentage of the app's user base.

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.
3. Select the running experiment that you want to edit.
4. In the Experiment overview , click the context menu ( more_vert ), and then click Edit running experiment .
5. The Targeting dialog displays an option to increase the percentage of users who are in the running experiment. Select a number greater than the current percentage and click Publish . The experiment will be pushed out to the percentage of users you have specified.

Duplicate an experiment

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.
3. Select the running or completed experiment that you want to stop.
4. Click Completed or Running , hold the pointer over your experiment, click the context menu ( more_vert ), and then click Duplicate experiment or Stop experiment .

Stop an experiment

1. In the DevOps & Engagement section of the Firebase console navigation menu, click Remote Config .
2. Click the A/B Tests tab.
3. Select the running or completed experiment that you want to stop.
4. Click Completed or Running , hold the pointer over your experiment, click the context menu ( more_vert ), and then click Stop experiment .

Web client identification and experiment persistence

When a user launches a web application using Firebase A/B Testing in a browser for the first time, a unique Firebase installation ID ( FID) is generated. This FID is persistently stored in the browser's IndexedDB to identify the app instance across sessions.

Firebase A/B Testing uses the FID to assign users to experiment variants, and Google Analytics uses it for event aggregation to measure and analyze user behavior within each variant.

Because the FID is stored in IndexedDB, Firebase A/B Testing treats a user as a new user if they access your app from a different browser or in an incognito window, or if they clear their browser's IndexedDB. This means that a user might be included in different experiment variants when using different browsers or browsing sessions.

User targeting

You can target the users to include in your experiment using the following user-targeting criteria.

The following rule types are supported in the Firebase console. Equivalent features are available in the Remote Config REST API, as detailed in the conditional expression reference .

A/B Testing metrics

When you create your experiment, you choose a primary, or goal metric, that is used to determine the winning variant. You should also track other metrics to help you better understand each experiment variant's performance and track important trends that may differ for each variant, like user retention, app stability and in-app purchase revenue. You can track up to five non-goal metrics in your experiment.

For example, say you're using Remote Config to launch two different game flows in your app and want to optimize for in-app purchases and ad revenue, but you also want to track the stability and user retention of each variant. In this case, you might consider choosing Estimated total revenue as your goal metric because it includes in-app purchase revenue and ad revenue, and then, for Other metrics to track , you might add the following:

• To track your daily and weekly user retention, add Retention (2-3 days) and Retention (4-7 days) .
• To compare stability between the two game flows, add Crash-free users .
• To see more detailed views of each revenue type, add Purchase revenue and Estimated ad revenue .

The following tables provide details on how goal metrics and other metrics are calculated.

Goal metrics

Other metrics

BigQuery data export

In addition to viewing A/B Testing experiment data in the Firebase console, you can inspect and analyze experiment data in BigQuery . While A/B Testing does not have a separate BigQuery table, experiment and variant memberships are stored on every Google Analytics event within the Analytics event tables.

The user properties that contain experiment information are of the form userProperty.key like "firebase_exp_%" or userProperty.key = "firebase_exp_01" where 01 is the experiment ID, and userProperty.value.string_value contains the (zero-based) index of the experiment variant.

You can use these experiment user properties to extract experiment data. This gives you the power to slice your experiment results in many different ways and independently verify the results of A/B Testing .

To get started, complete the following as described in this guide:

1. Enable BigQuery export for Google Analytics in the Firebase console
2. Access A/B Testing data using BigQuery
3. Explore example queries

Enable BigQuery export for Google Analytics in the Firebase console

If you're on the Spark plan, you can use the BigQuery sandbox to access BigQuery at no cost, subject to Sandbox limits . See Pricing and the BigQuery sandbox for more information.

First, make sure that you're exporting your Analytics data to BigQuery :

1. In the Firebase console, go to the settings Settings > Integrations tab .

2. In the BigQuery card, click Manage and verify that your project is exporting Analytics data to BigQuery .

   If the card says Link , then you need to set up the export (continue to the next step).

3. If you need to set up export:

   1. Review About Linking Firebase to BigQuery , then click Next .

   2. In the Configure integration section, enable Google Analytics .

   3. Select a region and choose export settings.

   4. Click Link to BigQuery .

Depending on how you chose to export data, it may take up to a day for the tables to become available. For more information about exporting project data to BigQuery , see Export project data to BigQuery .

Access A/B Testing data in BigQuery

Before querying for data for a specific experiment, you'll want to obtain some or all of the following to use in your query:

• Experiment ID: You can obtain this from the URL of the Experiment overview page. For example, if your URL looks like https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 , the experiment ID is 25 .
• Google Analytics property ID : This is your 9-digit Google Analytics property ID. You can find this within Google Analytics ; it also appears in BigQuery when you expand your project name to show the name of your Google Analytics event table ( project_name.analytics_000000000.events ).
• Experiment date: To compose a faster and more efficient query, it's good practice to limit your queries to the Google Analytics daily event table partitions that contain your experiment data—tables identified with a YYYYMMDD suffix. So, if your experiment ran from February 2, 2024 through May 2, 2024, you'd specify a _TABLE_SUFFIX between '20240202' AND '20240502' . For an example, see Select a specific experiment's values .
• Event names: Typically, these correspond with your goal metrics that you configured in the experiment. For example, in_app_purchase events, ad_impression , or user_retention events.

After you gather the information you need to generate your query:

1. In the Google Cloud console, go to BigQuery .
2. Select your project, then select Create SQL query .
3. Add your query. For example queries to run, see Explore example queries .
4. Click Run .

Query experiment data using the Firebase console's auto-generated query

If you're using the Blaze plan, the Experiment overview page provides a sample query that returns the experiment name, variants, event names, and the number of events for the experiment you're viewing.

To obtain and run the auto-generated query:

1. In the Firebase console, go to DevOps & Engagement > A/B Testing .
2. Select the A/B Testing experiment you want to query to open the Experiment overview .
3. From the Options menu, beneath BigQuery integration , select Query experiment data . This opens your project in BigQuery within the Google Cloud console console and provides a basic query you can use to query your experiment data.

The following example shows a generated query for an experiment with three variants (including the baseline) named "Winter welcome experiment." It returns the active experiment name, variant name, unique event, and event count for each event. Note that the query builder doesn't specify your project name in the table name, as it opens directly within your project.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName