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

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

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

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

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

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

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

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

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

  2. В разделе Engage навигационного меню консоли Firebase нажмите A/B Testing .

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

  4. Введите название и, при желании, описание для вашего эксперимента и нажмите «Далее» .

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

    • Версия: Одна или несколько версий вашего приложения
    • Номер сборки: код версии приложения
    • Языки: Один или несколько языков и региональных настроек, используемых для отбора пользователей, которые могут быть включены в эксперимент.
    • Страна/Регион: Одна или несколько стран или регионов для отбора пользователей, которых следует включить в эксперимент.
    • Целевая аудитория пользователей: Analytics аудитории, используемые для таргетирования пользователей, которые могут быть включены в эксперимент.
    • Свойство пользователя: Одно или несколько свойств пользователя Analytics для выбора пользователей, которые могут быть включены в эксперимент.
    • Первое открытие: Нацеливайте таргетинг на пользователей в зависимости от того, когда они впервые открыли ваше приложение.

      Функция таргетирования пользователей по времени первого открытия доступна после выбора приложения для Android или iOS. Она поддерживается следующими версиями SDK Remote Config : Apple Platforms SDK v9.0.0+ и Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

      Analytics также должна быть включена на стороне клиента во время первого открытого события.

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

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

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

    • app_install
    • app_remove
    • app_update

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

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

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

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

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

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

  13. Нажмите «Просмотреть» , чтобы сохранить эксперимент.

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

Проверьте результаты эксперимента на тестовом устройстве.

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

  1. Получите токен авторизации установки следующим образом:

    Быстрый

    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }

    Objective-C

    [[FIRInstallations installations] authTokenForcingRefresh:true
                                                   completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) {
      if (error != nil) {
        NSLog(@"Error fetching Installation token %@", error);
        return;
      }
      NSLog(@"Installation auth token: %@", [result authToken]);
    }];

    Java

    FirebaseInstallations.getInstance().getToken(/* forceRefresh */true)
            .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() {
        @Override
        public void onComplete(@NonNull Task<InstallationTokenResult> task) {
            if (task.isSuccessful() && task.getResult() != null) {
                Log.d("Installations", "Installation auth token: " + task.getResult().getToken());
            } else {
                Log.e("Installations", "Unable to get Installation auth token");
            }
        }
    });

    Kotlin

    val forceRefresh = true
    FirebaseInstallations.getInstance().getToken(forceRefresh)
        .addOnCompleteListener { task ->
            if (task.isSuccessful) {
                Log.d("Installations", "Installation auth token: " + task.result?.token)
            } else {
                Log.e("Installations", "Unable to get Installation auth token")
            }
        }

    C++

    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });

    Единство

    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
        }
      });
  2. На панели навигации консоли Firebase нажмите «A/B-тестирование» .
  3. Нажмите «Черновик» (и/или «Запуск» для экспериментов с удаленной конфигурацией), наведите курсор на свой эксперимент, щелкните контекстное меню ( ), а затем нажмите «Управление тестовыми устройствами» .
  4. Введите токен авторизации установки для тестового устройства и выберите вариант эксперимента, который будет отправлен на это тестовое устройство.
  5. Запустите приложение и убедитесь, что выбранный вариант принимается на тестовом устройстве.

Чтобы узнать больше об установках Firebase , см. раздел «Управление установками Firebase» .

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

Независимо от того, создаете ли вы эксперимент с помощью Remote Config , Notifications Composer или Firebase In-App Messaging , вы можете проверить и запустить свой эксперимент, отслеживать его выполнение и увеличивать количество пользователей, участвующих в нем.

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

Начните эксперимент

  1. В разделе Engage навигационного меню консоли Firebase нажмите A/B Testing .
  2. Нажмите «Черновик» , а затем выберите название вашего эксперимента.
  3. Чтобы убедиться, что в вашем приложении есть пользователи, которые подойдут для вашего эксперимента, разверните черновик и проверьте, не превышает ли число 0% в разделе «Таргетинг и распространение» (например, 1% пользователей, соответствующих критериям ).
  4. Чтобы изменить параметры эксперимента, нажмите «Редактировать» .
  5. Чтобы начать эксперимент, нажмите « Начать эксперимент» . В рамках одного проекта можно одновременно проводить до 24 экспериментов.

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

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

  1. В разделе Engage навигационного меню консоли Firebase нажмите A/B Testing .
  2. Нажмите «Бег» , а затем выберите или найдите название вашего эксперимента. На этой странице вы можете просмотреть различные наблюдаемые и смоделированные статистические данные о вашем эксперименте по бегу, включая следующие:

    • Процентное отклонение от базового уровня : Показатель улучшения метрики для данного варианта по сравнению с базовым уровнем. Рассчитывается путем сравнения диапазона значений для варианта с диапазоном значений для базового уровня.
    • Вероятность превзойти базовый показатель : оценочная вероятность того, что данный вариант превзойдет базовый показатель по выбранной метрике.
    • observed_metric per user : На основе результатов эксперимента это прогнозируемый диапазон, в который будет попадать значение метрики с течением времени.
    • Total observed_metric : Накопленное значение для базового варианта или варианта. Это значение используется для оценки эффективности каждого варианта эксперимента и применяется для расчета показателей улучшения , диапазона значений , вероятности превзойти базовый вариант и вероятности стать лучшим вариантом . В зависимости от измеряемого показателя, этот столбец может быть обозначен как «Длительность на пользователя», «Доход на пользователя», «Коэффициент удержания» или «Коэффициент конверсии».
  3. После того, как ваш эксперимент продлится некоторое время (не менее 7 дней для FCM и In-App Messaging или 14 дней для Remote Config ), данные на этой странице укажут, какой вариант, если таковой имеется, является «лидером». Некоторые измерения сопровождаются гистограммой, которая представляет данные в визуальном формате.

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

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

  1. В разделе Engage навигационного меню консоли Firebase нажмите A/B Testing .
  2. Нажмите «Завершено» или «Выполняется» , выберите эксперимент, который хотите запустить для всех пользователей, затем нажмите контекстное меню ( ) и выберите «Развернуть вариант» .
  3. Для запуска эксперимента на всех пользователях выполните одно из следующих действий:

    • Для эксперимента, использующего редактор уведомлений , воспользуйтесь диалоговым окном «Отправить сообщение» , чтобы отправить сообщение оставшимся целевым пользователям, которые не участвовали в эксперименте.
    • Для эксперимента Remote Config выберите вариант, чтобы определить, какие значения параметров Remote Config следует обновить. Критерии таргетинга, определенные при создании эксперимента, добавляются в качестве нового условия в ваш шаблон, чтобы гарантировать, что развертывание затронет только пользователей, на которых направлен эксперимент. После нажатия кнопки «Просмотреть» в разделе «Удаленная конфигурация» для проверки изменений, нажмите кнопку «Опубликовать изменения» , чтобы завершить развертывание.
    • Для эксперимента In-App Messaging используйте диалоговое окно, чтобы определить, какой вариант необходимо запустить в качестве отдельной кампании In-App Messaging . После выбора вы будете перенаправлены на экран создания сообщения в FIAM, где сможете внести необходимые изменения перед публикацией.

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

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

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

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

  1. В разделе Engage навигационного меню консоли Firebase нажмите A/B Testing .
  2. Нажмите «Завершено» или «Выполняется» , наведите указатель мыши на свой эксперимент, щелкните контекстное меню ( ), а затем выберите «Дублировать эксперимент» или «Остановить эксперимент» .

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

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

Критерий целевого назначения Оператор(ы) Ценности) Примечание
Версия содержит,
не содержит
точно совпадает,
содержит регулярное выражение
Введите значение для одной или нескольких версий приложения, которые вы хотите включить в эксперимент.

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

При использовании оператора `contains` можно создавать регулярные выражения в формате RE2 . Ваше регулярное выражение может соответствовать всей целевой строке версии или её части. Также можно использовать якоря `^` и `$` для сопоставления начала, конца или всей целевой строки.

Целевая аудитория пользователей включает в себя все,
включает как минимум один из следующих пунктов:
не включает все,
не включает как минимум один из
Выберите одну или несколько целевых аудиторий Analytics , чтобы нацелить их на пользователей, которые могут быть включены в ваш эксперимент. Для некоторых экспериментов, ориентированных на аудитории Google Analytics может потребоваться несколько дней для сбора данных, поскольку они подвержены задержкам обработки данных Analytics . Чаще всего эта задержка встречается у новых пользователей, которые обычно добавляются в соответствующие аудитории через 24-48 часов после создания, или у недавно созданных аудиторий .

В случае Remote Config это означает, что даже если пользователь технически соответствует критериям для включения в аудиторию, если Analytics еще не добавил пользователя в аудиторию к моменту выполнения `fetchAndActivate()`, пользователь не будет включен в эксперимент.

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

Для чисел:
<, ≤, =, ≥, >
Свойство пользователя Analytics используется для выбора пользователей, которые могут быть включены в эксперимент, при этом предлагается ряд вариантов выбора значений этого свойства.

На стороне клиента для пользовательских свойств можно задавать только строковые значения. Для условий, использующих числовые операторы, служба Remote Config преобразует значение соответствующего пользовательского свойства в целое число или число с плавающей запятой.
При использовании оператора `contains` можно создавать регулярные выражения в формате RE2 . Ваше регулярное выражение может соответствовать всей целевой строке версии или её части. Также можно использовать якоря `^` и `$` для сопоставления начала, конца или всей целевой строки.
Страна/Регион Н/Д Для отбора пользователей, которые могли бы быть включены в эксперимент, использовалась одна или несколько стран или регионов.
Языки Н/Д Для отбора пользователей, которые могут быть включены в эксперимент, использовались один или несколько языков и языковых настроек.
Первый открытый До
После

Нацеливайте таргетинг на пользователей в зависимости от того, когда они впервые открывают ваше приложение:

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

Функция таргетирования пользователей по первому открытию доступна после выбора приложения для Android или iOS. В настоящее время она поддерживается следующими версиями SDK Remote Config : Apple Platforms SDK v9.0.0+ и Android SDK v21.1.1+ ( Firebase BoM v30.3.0+).

Analytics также должна быть включена на стороне клиента во время первого открытого события.

Метрики A/B Testing

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

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

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

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

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

Метрика Описание
Пользователи без сбоев Процент пользователей, которые не столкнулись с ошибками в вашем приложении, обнаруженными SDK Firebase Crashlytics во время эксперимента.
Предполагаемый доход от рекламы Предполагаемый доход от рекламы.
Предполагаемый общий доход Совокупная стоимость покупки и предполагаемые доходы от рекламы.
Доход от покупки Суммарное значение для всех событий, связанных purchase и in_app_purchase .
Срок хранения (1 день) Количество пользователей, которые ежедневно возвращаются в ваше приложение.
Сохранение эффекта (2-3 дня) Количество пользователей, которые возвращаются в ваше приложение в течение 2-3 дней.
Срок хранения (4-7 дней) Количество пользователей, которые возвращаются в ваше приложение в течение 4-7 дней.
Срок хранения (8-14 дней) Количество пользователей, которые возвращаются в ваше приложение в течение 8-14 дней.
Сохранение данных (более 15 дней) Количество пользователей, которые возвращаются в ваше приложение через 15 или более дней после последнего использования.
первый_открытый Analytics событие, которое срабатывает при первом открытии пользователем приложения после его установки или переустановки. Используется как часть воронки конверсии.

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

Метрика Описание
уведомление_отклонить Событие Analytics , которое срабатывает при отклонении уведомления, отправленного редактором уведомлений (только для Android).
notification_receive Событие Analytics , которое срабатывает при получении уведомления, отправленного редактором уведомлений, когда приложение находится в фоновом режиме (только для Android).
os_update Analytics событие, отслеживающее обновление операционной системы устройства до новой версии. Для получения дополнительной информации см. раздел «Автоматически собираемые события» .
screen_view Событие Analytics , отслеживающее просмотренные экраны в вашем приложении. Подробнее см. раздел «Отслеживание просмотров экранов» .
session_start Analytics событие, которое подсчитывает количество пользовательских сессий в вашем приложении. Подробнее см. в разделе «Автоматически собираемые события» .

экспорт данных 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