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

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

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

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

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

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

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

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

  1. Откройте страницу результатов эксперимента, который вы хотите изменить.
  2. В меню More выберите Изменить запущенный эксперимент .
  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. Эксперимент длился достаточно долго, чтобы обеспечить репрезентативную выборку ваших пользователей и оценить долгосрочную эффективность. Рекомендуемая минимальная продолжительность типичного эксперимента с Remote Config составляет две недели.

Данные эксперимента обрабатываются не более 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 КБ. Сюда входят названия вариантов, параметры вариантов и другие метаданные конфигурации.