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

Когда вы используете Firebase Remote Config для развертывания настроек приложения с активной пользовательской базой, вы хотите убедиться, что все сделано правильно. Вы можете использовать эксперименты A/B-тестирования, чтобы лучше определить следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open
  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)")
    }
    

    Цель-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+KTX

    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")
            }
        }

    С++

    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future& 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, композитора уведомлений или обмена сообщениями в приложениях Firebase, вы можете затем проверить и запустить эксперимент, отслеживать его во время его выполнения и увеличивать количество пользователей, включенных в текущий эксперимент.

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

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

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

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

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

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

    • % разницы от базового уровня : мера улучшения показателя для данного варианта по сравнению с базовым уровнем. Рассчитывается путем сравнения диапазона значений варианта с диапазоном значений базового плана.
    • Вероятность превышения базового уровня : расчетная вероятность того, что данный вариант превысит базовый уровень для выбранного показателя.
    • observed_metric для каждого пользователя : на основе результатов эксперимента это прогнозируемый диапазон, в который значение метрики попадет с течением времени.
    • Общая observed_metric : наблюдаемое совокупное значение для базового уровня или варианта. Значение используется для измерения эффективности каждого варианта эксперимента и расчета улучшения , диапазона значений , вероятности достижения базового уровня и вероятности стать лучшим вариантом . В зависимости от измеряемого показателя этот столбец может быть помечен как «Продолжительность на пользователя», «Доход на пользователя», «Коэффициент удержания» или «Коэффициент конверсии».
  3. После того, как ваш эксперимент продлится некоторое время (не менее 7 дней для FCM и обмена сообщениями в приложении или 14 дней для удаленной настройки), данные на этой странице покажут, какой вариант, если таковой имеется, является «лидером». Некоторые измерения сопровождаются гистограммой, представляющей данные в визуальном формате.

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

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

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

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

Развернуть эксперимент

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

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

Дублировать или остановить эксперимент

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

Таргетинг на пользователей

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

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

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

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

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

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

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

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

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

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

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

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

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

Метрики A/B-тестирования

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

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

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

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

Показатели цели

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

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

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

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

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

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

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

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

  1. Включите экспорт BigQuery для Google Analytics в консоли Firebase.
  2. Доступ к данным A/B-тестирования с помощью 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-тестирования в 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-тестирование и выберите эксперимент A/B-тестирования, который вы хотите запросить, чтобы открыть обзор эксперимента .
  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-тестирования из таблиц событий Google Analytics.

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

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

Дополнительные сведения о том, как A/B-тестирование вычисляет логические выводы, см. в разделе Интерпретация результатов теста .

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