Об A/B-тестах Firebase

Чтобы помочь вам максимально повысить релевантность и полезность результатов тестирования, на этой странице представлена ​​подробная информация о том, как работает Firebase A/B Testing .

Размер выборки

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

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

Вы можете редактировать выбранные параметры запуска экспериментов, в том числе:

  • Название эксперимента
  • Описание
  • Условия нацеливания
  • Варианты значений

Чтобы отредактировать эксперимент:

  1. Откройте страницу результатов эксперимента, который вы хотите изменить.
  2. В меню More_vert выберите «Редактировать запущенный эксперимент»
  3. Внесите изменения, затем нажмите «Опубликовать» .

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

Логика назначения вариантов удаленной конфигурации

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

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

  • При создании новой аудитории может потребоваться от 24 до 48 часов для привлечения новых пользователей.
  • Как правило, новых пользователей регистрируют в соответствующих группах через 24-48 часов после того, как они получают на это право.

Для таргетинга, привязанного ко времени, рассмотрите возможность использования свойств пользователя Google Analytics или встроенных параметров таргетинга, таких как страна или регион, язык и версия приложения.

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

События активации

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

Весовые коэффициенты вариантов

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

Интерпретация результатов теста

Firebase A/B Testing использует частотный вывод , чтобы помочь вам понять вероятность того, что результаты вашего эксперимента могли быть обусловлены исключительно случайностью. Эта вероятность представлена ​​значением вероятности , или p-значением . p-значение — это вероятность того, что разница в производительности такого или большего размера между двумя вариантами могла возникнуть из-за случайности, если на самом деле эффекта нет, измеряемая значением от 0 до 1. A/B Testing используется уровень значимости 0,05, так что:

  • Значение p < 0,05 указывает на то, что если истинная разница равна нулю, то вероятность того, что наблюдаемая разница такого масштаба может возникнуть случайным образом, составляет менее 5%. Поскольку 0,05 является пороговым значением, любое значение p < 0,05 указывает на статистически значимую разницу между вариантами.
  • Значение p, превышающее 0,05, указывает на то, что разница между вариантами статистически незначима.

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

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

Результаты разделены на наблюдаемые данные и данные для вывода . Наблюдаемые данные рассчитываются непосредственно на основе данных Google Analytics, а данные для вывода предоставляют p-значения и доверительные интервалы, которые помогут оценить статистическую значимость наблюдаемых данных.

Для каждого показателя отображаются следующие статистические данные:

Наблюдаемые данные

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

Данные для вывода

  • 95% доверительный интервал (разница средних значений) отображает интервал, содержащий «истинное» значение отслеживаемого показателя с 95% доверительной вероятностью. Например, если в результате вашего эксперимента 95% доверительный интервал для предполагаемой общей выручки находится в диапазоне от 5 до 10 долларов, то существует 95% вероятность того, что истинная разница средних значений находится в диапазоне от 5 до 10 долларов. Если диапазон доверительного интервала включает 0, статистически значимая разница между вариантом и базовым уровнем не была обнаружена.

    Значения доверительного интервала отображаются в формате, соответствующем отслеживаемому показателю. Например, время (в HH:MM:SS ) для удержания пользователей, доллары США для дохода от рекламы на одного пользователя и проценты для коэффициента конверсии.

  • P-значение , представляющее вероятность наблюдения данных, столь же экстремальных, как результаты, полученные в эксперименте, при условии отсутствия истинной разницы между вариантом и базовым вариантом. Чем ниже p-значение, тем выше уверенность в том, что наблюдаемые результаты останутся верными при повторении эксперимента. Значение 0,05 или ниже указывает на значительную разницу и низкую вероятность того, что результаты были случайными. P-значения основаны на одностороннем тесте , где значение варианта больше значения базового варианта. Firebase использует t-тест с неравными дисперсиями для непрерывных переменных (числовые значения, такие как доход) и z-тест пропорций для данных о конверсиях (бинарные значения, такие как удержание пользователей, пользователи без сбоев, пользователи, запускающие событие Google Analytics ).

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

  • Насколько выше или ниже каждый показатель эксперимента по сравнению с базовым уровнем, измеренным непосредственно (то есть, фактическими наблюдаемыми данными).
  • Вероятность того, что наблюдаемая разница между вариантом и базовым уровнем могла возникнуть в результате случайности (p-значение).
  • Диапазон, который, вероятно, содержит «истинную» разницу в производительности между вариантом и базовым вариантом для каждого показателя эксперимента — способ понять сценарии «наилучшего» и «наихудшего» развития событий.

Интерпретация результатов экспериментов, проведенных с помощью Google Optimize.

Результаты Firebase A/B Testing для экспериментов, начатых до 23 октября 2023 года, были получены с помощью Google Optimize. Google Optimize использовал байесовский вывод для генерации содержательной статистики на основе данных эксперимента.

Результаты разделены на «наблюдаемые данные» и «моделируемые данные». Наблюдаемые данные были рассчитаны непосредственно на основе аналитических данных, а моделируемые данные были получены путем применения нашей байесовской модели к наблюдаемым данным.

Для каждого показателя отображаются следующие статистические данные:

Наблюдаемые данные

  • Общая сумма (сумма показателей для всех пользователей в варианте)
  • Среднее значение (среднее значение метрики для пользователей в варианте)
  • % разница по сравнению с исходным уровнем

Моделированные данные

  • Вероятность превзойти базовый показатель: насколько вероятно, что для данного варианта показатель будет выше, чем для базового.
  • Процентное отклонение от базового уровня: на основе медианных оценок модели показателя для варианта и базового уровня.
  • Диапазоны значений метрики: диапазоны, в которых значение метрики с наибольшей вероятностью может быть найдено с вероятностью 50% и 95%.

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

  1. Насколько выше или ниже каждый показатель эксперимента по сравнению с базовым уровнем, измеренным непосредственно (т.е., фактическими наблюдаемыми данными).
  2. Насколько вероятно , что каждый показатель эксперимента окажется выше базового/лучшего общего показателя, исходя из байесовского вывода (вероятность быть лучше/лучше соответственно)?
  3. Допустимые диапазоны для каждой метрики эксперимента, основанные на байесовском выводе — сценарии «наилучшего случая» и «наихудшего случая» (достоверные интервалы).

Решительность лидера

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

В экспериментах с использованием Google Optimize компания Firebase объявляла вариант «явным лидером», если вероятность того, что он будет лучше базового варианта по основному показателю, превышала 95%. Если критериям «явного лидера» соответствовало несколько вариантов, то только вариант с наилучшими общими показателями получал статус «явного лидера».

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

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

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

Продолжительность эксперимента

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

  1. В ходе эксперимента было собрано достаточно данных для получения полезного результата. Данные об экспериментах и ​​результатах обновляются ежедневно. Вы можете воспользоваться онлайн-калькулятором размера выборки, чтобы оценить рекомендуемый размер выборки для вашего эксперимента.
  2. Эксперимент длился достаточно долго, чтобы обеспечить репрезентативную выборку ваших пользователей и оценить производительность в долгосрочной перспективе. Рекомендуемая минимальная продолжительность проведения типичного эксперимента по удаленной настройке составляет две недели.

Данные эксперимента обрабатываются максимум 90 дней после его начала. По истечении 90 дней эксперимент автоматически останавливается. Результаты эксперимента больше не обновляются в консоли Firebase , и эксперимент перестает отправлять значения параметров, специфичные для данного эксперимента. После этого клиенты начинают получать значения параметров на основе условий, заданных в шаблоне Remote Config . Исторические данные эксперимента сохраняются до тех пор, пока вы не удалите эксперимент.

Схема 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 .
  2. Если вы уже используете BigQuery с другими сервисами Firebase, нажмите «Управление» . В противном случае нажмите «Связать» .
  3. Ознакомьтесь с информацией о подключении Firebase к BigQuery , затем нажмите «Далее» .
  4. В разделе «Настройка интеграции» включите переключатель Google Analytics .

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

  6. Перейдите по ссылке на 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 ).
  • Дата эксперимента: Для более быстрого и эффективного составления запроса рекомендуется ограничивать запросы разделами таблицы ежедневных событий Google Analytics , содержащими данные вашего эксперимента — таблицами, обозначенными суффиксом YYYYMMDD . Таким образом, если ваш эксперимент проводился со 2 февраля 2024 года по 2 мая 2024 года, вам следует указать _TABLE_SUFFIX between '20240202' AND '20240502' . Пример см. в разделе « Выбор значений конкретного эксперимента» .
  • Названия событий: Как правило, они соответствуют целевым показателям , которые вы настроили в эксперименте. Например, события in_app_purchase , ad_impression или события user_retention .

После того, как вы соберете необходимую информацию для формирования запроса:

  1. Откройте BigQuery в консоли Google Cloud .
  2. Выберите свой проект, затем выберите «Создать SQL-запрос» .
  3. Добавьте свой запрос. Примеры запросов для выполнения см. в разделе «Изучить примеры запросов» .
  4. Нажмите «Выполнить» .

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

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

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

  1. В консоли Firebase откройте A/B Testing и выберите эксперимент A/B Testing , для которого хотите выполнить запрос, чтобы открыть обзор эксперимента .
  2. В меню «Параметры», под пунктом «Интеграция BigQuery , выберите «Запросить данные эксперимента ». Это откроет ваш проект в BigQuery в консоли Google Cloud и предоставит базовый запрос, который вы можете использовать для запроса данных эксперимента.

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

  /*
    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

Для получения дополнительных примеров запросов перейдите в раздел «Изучить примеры запросов» .

Изучите примеры запросов.

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

Извлеките значения стандартного отклонения для покупок и экспериментов из всех проведенных экспериментов.

Вы можете использовать данные результатов экспериментов для независимой проверки результатов Firebase A/B Testing . Следующий SQL-запрос BigQuery извлекает варианты экспериментов, количество уникальных пользователей в каждом варианте, суммирует общий доход от событий in_app_purchase и ecommerce_purchase , а также стандартные отклонения для всех экспериментов в диапазоне времени, указанном в качестве начальной и конечной дат _TABLE_SUFFIX . Вы можете использовать данные, полученные из этого запроса, с генератором статистической значимости для односторонних t-тестов, чтобы убедиться, что результаты, предоставляемые Firebase, соответствуют вашему собственному анализу.

Для получения более подробной информации о том, как A/B Testing рассчитывает выводы, см. раздел «Интерпретация результатов тестирования» .

  /*
    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;

Выберите значения конкретного эксперимента.

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

  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

Пределы

A/B Testing ограничено 300 экспериментами в общей сложности, 24 запущенными экспериментами и 24 черновыми экспериментами. Эти ограничения распространяются и на развертывания Remote Config . Например, если у вас два запущенных развертывания и три запущенных эксперимента, вы можете добавить до 19 дополнительных развертываний или экспериментов.

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

  • Если вы достигли лимита в 24 запущенных эксперимента или цикла, вы должны остановить текущий эксперимент или цикл перед началом нового.

В эксперименте может быть максимум 8 вариантов (включая базовый) и до 25 параметров для каждого варианта. Размер эксперимента может составлять около 200 КиБ. Это включает в себя названия вариантов, параметры вариантов и другие метаданные конфигурации.