ユーザーに働きかけたり、新しいマーケティング キャンペーンを開始したりするときには、確実に効果が得られるように方策を練る必要があります。A/B テストでは、ユーザーベース内の選択した集合を対象にいくつかのメッセージ バリアントをテストすることにより、最適な表現や見せ方を見つけられます。リテンション(ユーザー維持率)の改善が目的の場合も、オファーに対するコンバージョンの改善が目的の場合も、A/B テストで統計的分析を実行することにより、選択した目的に照らしてメッセージの特定のバリアントがベースラインよりも効果的かどうかを判断できます。
ベースラインを使って機能バリアントの A/B テストを実施するには:
- テストを作成します。
- テストデバイスでテストを検証します。
- テストを管理します。
テストを作成する
Notifications Composer を使用したテストでは、単一の通知メッセージで複数のバリアントを評価できます。
Firebase コンソールにログインし、プロジェクトで Google Analytics が有効になっていることを確認します。これにより、テストで Analytics データにアクセスできるようになります。
プロジェクトの作成時に Google Analytics を有効にしていない場合は、[統合] タブで有効にすることができます。このタブには、Firebase コンソールで、 > [プロジェクトの設定] を選択してアクセスできます。
Firebase コンソールのナビゲーション バーの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
[テストを作成] をクリックし、テストするサービスの選択を求めるメッセージが表示されたら [通知] を選択します。
テストの [名前] とオプションの [説明] を入力し、[次へ] をクリックします。
[ターゲット設定] の各フィールドに入力します。最初に、そのテストを使用するアプリを選択します。また、次のようなオプションを選択することで、テストに参加するユーザーのサブセットをターゲットに設定することもできます。
- バージョン: アプリの 1 つ以上のバージョン。
- ユーザー オーディエンス: テストに含める可能性のあるユーザーをターゲットとして設定するための Analytics のユーザー オーディエンス
- ユーザー プロパティ: テスト対象とする可能性のあるユーザーを選択するための、1 つ以上の Analytics ユーザー プロパティ
- 国 / 地域: テスト対象とする可能性のあるユーザーを選択するための 1 つ以上の国またはリージョン。
- デバイスの言語: テストに含める可能性のあるユーザーを選択するための、1 つ以上の言語とロケール。
- 初回起動: アプリの初回起動に基づいてターゲットに設定するユーザー。
- 前回のアプリ エンゲージメント: 最後にアプリを利用した日時に基づいてターゲットに設定するユーザー。
[ターゲット ユーザーの割合] の設定: テストのベースラインと 1 つ以上のバリアントの間で均等に分散させる、[ターゲット ユーザー] で設定した条件に一致するアプリのユーザーベースの割合を選択します。これは 0.01%~100% の任意のパーセント値にすることができます。パーセント値は、重複したテストも含め、各テストでユーザーにランダムに再割り当てされます。
[バリアント] セクションの [メッセージのテキストを入力] フィールドに、ベースライン グループに送信するメッセージを入力します。ベースライン グループにメッセージを送信しない場合は、このフィールドは空白のままにしておきます。
(省略可)複数のバリアントをテストに追加するには、[バリアントを追加] をクリックします。デフォルトでは、テストには 1 つのベースラインと 1 つのバリアントがあります。
(省略可)テストの各バリアントの名前を入力して、[バリアント A]、[バリアント B] などの名前を置き換えます。
プルダウン リストから、テストのバリアントを評価する際に使用するテストの目標指標と追加の指標を選択して定義します。この指標には、組み込みの目標(エンゲージメント、購入、収益、維持率など)、Analytics コンバージョン イベント、その他の Analytics イベント。
メッセージのオプションを選択します。
- 配信日: 保存時にテストをすぐに開始する場合は [今すぐ送信] を選択し、後でテストを開始する場合は [スケジュール設定] を選択し、時間を指定します。
- 詳細オプション: テストに含まれるすべての通知に関する詳細オプションを選択するには、[詳細オプション] を展開し、リストされたオプションを変更します。
[レビュー] をクリックしてテストを保存します。
プロジェクトあたり最大 300 個のテストを使用できます。その内訳は、実行中のテストが最大 24 個まで、残りはドラフトまたは完了済みのテストになります。
テストデバイスでテストを検証する
Firebase のインストールごとに、関連付けられている FCM 登録トークンを取得できます。このトークンを使用して、アプリがインストールされているテストデバイス上の特定のテスト バリアントをテストできます。テストデバイスでテストを検証する方法を以下に示します。
- 次のように FCM 登録トークンを取得します。
Swift
Messaging.messaging().token { token, error in if let error = error { print("Error fetching FCM registration token: \(error)") } else if let token = token { print("FCM registration token: \(token)") self.fcmRegTokenMessage.text = "Remote FCM registration token: \(token)" } }
Objective-C
[[FIRMessaging messaging] tokenWithCompletion:^(NSString *token, NSError *error) { if (error != nil) { NSLog(@"Error getting FCM registration token: %@", error); } else { NSLog(@"FCM registration token: %@", token); self.fcmRegTokenMessage.text = token; } }];
Java
FirebaseMessaging.getInstance().getToken() .addOnCompleteListener(new OnCompleteListener<String>() { @Override public void onComplete(@NonNull Task<String> task) { if (!task.isSuccessful()) { Log.w(TAG, "Fetching FCM registration token failed", task.getException()); return; } // Get new FCM registration token String token = task.getResult(); // Log and toast String msg = getString(R.string.msg_token_fmt, token); Log.d(TAG, msg); Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show(); } });
Kotlin+KTX
FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { Log.w(TAG, "Fetching FCM registration token failed", task.exception) return@OnCompleteListener } // Get new FCM registration token val token = task.result // Log and toast val msg = getString(R.string.msg_token_fmt, token) Log.d(TAG, msg) Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show() })
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()); } });
Unity
Firebase.Messaging.FirebaseMessaging.DefaultInstance.GetTokenAsync().ContinueWith( task => { if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) { UnityEngine.Debug.Log(System.String.Format("FCM registration token {0}", task.Result)); } });
- Firebase コンソールのナビゲーション バーで、[A/B Testing] をクリックします。
- [下書き] をクリックし、テストにカーソルを合わせてコンテキスト メニュー(more_vert)をクリックしてから、[テストデバイスを管理] をクリックします。
- テストデバイスの FCM トークンを入力して、そのテストデバイスに送信するテスト バリアントを選択します。
- アプリを実行して、選択したバリアントがテストデバイスで受信されていることを確認します。
テストを管理する
テストの作成に Remote Config、Notifications Composer、Firebase In-App Messaging のいずれを使用しても、テストを検証して開始し、実行中のテストをモニタリングできます。また、実行中のテストの対象ユーザーを増やすこともできます。
テストが終わったら、最も有効なバリアントで使用された設定をメモして、その設定をすべてのユーザーに適用できます。または、別のテストを実行することもできます。
テストを開始する
- Firebase コンソールのナビゲーション メニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
- [ドラフト] をクリックしてから、テストのタイトルをクリックします。
- テストの対象とするユーザーがアプリに含まれていることを確認するには、下書きの詳細を展開して、[ターゲティングと配信] セクションで 0% を超える数値(たとえばユーザーの 1% が条件に一致しているなど)を確認します。
- テストを変更するには、[編集] をクリックします。
- テストを開始するには、[テストを開始] をクリックします。プロジェクトごとに一度に最大 24 個のテストを実行できます。
テストをモニタリングする
しばらくテストを実行したら進行状況をチェックして、これまでにテストに参加したユーザーに関する結果を確認できます。
- Firebase コンソールのナビゲーション メニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
[実行中] をクリックし、テストのタイトルをクリックまたは検索します。このページでは、以下のような、実行中のテストに関するさまざまな観測統計やモデル化された統計を表示できます。
- ベースラインとの差異(%): ベースラインと比較した場合の、特定のバリアントに関する指標の改善の測定結果。バリアントの値の範囲をベースラインの値の範囲と比較することで計算されます。
- ベースラインを上回る確率: 選択された指標のベースラインを特定のバリアントが上回る予想確率。
- ユーザーあたりの observed_metric: テスト結果に基づき、時間の経過とともに指標の値が収まることが予測される範囲。
- 合計 observed_metric: ベースラインまたはバリアントの観測累積値。この値は、各テスト バリアントがどれだけ適切に実行されているかの測定や、改善度、値の範囲、ベースラインを上回る確率、最善のバリアントである確率の計算に使用されます。測定される指標に応じて、この列には「ユーザーあたりの期間」、「ユーザーあたりの収益」、「維持率」、「コンバージョン率」と表示されます。
テストを一定期間(FCM と In-App Messaging の場合は少なくとも 7 日間、Remote Config の場合は少なくとも 14 日間)実行すると、このページのデータによって、どのバリアントが「リーダー」であるかが示されます(存在する場合)。一部の測定には、データを視覚的に表現する棒グラフも表示されます。
すべてのユーザーにテストを展開する
目標指標に対する「リーダー」、つまり最良のバリアントを見つけるのに十分な期間テストを実行したら、次は全ユーザーにテストをリリースします。これにより、すべてのユーザーを対象に公開するバリアントを選択できるようになります。実施したテストによって明確な候補が示されなかった場合でも、バリアントをすべてのユーザーにリリースできます。
- Firebase コンソールのナビゲーション メニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
- [完了] または [実行中] をクリックしてから、すべてのユーザーにリリースするテストをクリックし、コンテキスト メニュー( )の [バリアントを展開] をクリックします。
次のいずれかの手順に沿って、すべてのユーザーにテストを展開します。
- Notifications Composer を使用するテストの場合は、[メッセージ送信] ダイアログを使用して、テストに参加しなかった残りのターゲット ユーザーにメッセージを送信します。
- Remote Config テストの場合は、バリアントを選択し、更新する Remote Config パラメータ値を決定します。テストの作成時に定義するターゲティング条件は、新しい条件としてテンプレートに追加されます。これにより、展開の影響がテスト対象のユーザーにのみ及ぶようにすることができます。[Remote Config で確認] をクリックして変更を確認した後、[変更を公開] をクリックして展開を完了します。
- In-App Messaging テストの場合、ダイアログを使用して、スタンドアロンの In-App Messaging キャンペーンとしてロールアウトする必要があるバリアントを特定します。 選択すると、FIAM 作成画面にリダイレクトされます。必要であれば、公開前に変更を行うことができます。
テストを拡大する
A/B Testing でリーダーが明確にならない理由が被験者の不足であると思われる場合は、テストの対象範囲を拡大し、アプリのユーザーベースに対する割合を増やすことができます。
- Firebase コンソールのナビゲーション メニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
- 編集する実施中のテストを選択します。
- [テストの概要] でコンテキスト メニュー( )をクリックし、[実行中のテストを編集] をクリックします。
- [ターゲット設定] ダイアログに、実行中のテストに参加しているユーザーの割合を増やすためのオプションが表示されます。現在の割合より大きい数を選択し、[公開] をクリックします。指定したユーザーの割合まで、テストが拡大されます。
テストを複製または停止する
- Firebase コンソールのナビゲーション メニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
- [完了] または [実行中] をクリックし、テストの上にポインタを置いて、コンテキスト メニュー( )をクリックしてから [テストを複製] または [テストを停止] をクリックします。
ユーザー ターゲティング
次のユーザー ターゲティング条件を使用して、テストに含めるユーザーをターゲット設定します。
ターゲティング条件 | 演算子 | 値 | メモ |
---|---|---|---|
バージョン | 次を含む、
次を含まない、 完全に一致する、 正規表現を含む |
テストに含める 1 つ以上のアプリ バージョンの値を入力します。 |
[次を含む]、[次を含まない]、[完全に一致する] のいずれかの演算子を使用する場合は、カンマ区切りの値リストを指定できます。 [正規表現を含む] 演算子を使用する場合は、正規表現を RE2 形式で作成できます。正規表現は対象バージョン文字列の全部または一部に一致させることができます。また、対象文字列の先頭、末尾、または全体と一致させるために ^ と $ アンカーを使うこともできます。 |
ユーザー | 以下をすべて含む、
以下を 1 つ以上含む、 以下をすべて含まない、 以下の少なくとも 1 つを含まない |
1 名以上の Analytics オーディエンスを選択して、テスト対象とする可能性のあるユーザーをターゲット設定します。 | Google Analytics のオーディエンスをターゲットとするテストの中には、Analytics のデータ処理のレイテンシが発生するものがあるため、データの収集に数日かかることがあります。このレイテンシが発生する可能性が高いのは、対象オーディエンスを作成してから 24~48 時間以内に登録された新規ユーザー、または最近作成したオーディエンスです。 |
ユーザー プロパティ | テキスト:
次を含む、 次を含まない、 完全一致、 正規表現を含む 数字: <、≤、=、≥、> |
Analytics のユーザー プロパティは、テスト対象とする可能性のあるユーザーを選択するために使用します。ユーザー プロパティ値の選択についてはさまざまなオプションがあります。
クライアントでは、ユーザー プロパティに関する文字列値のみを設定できます。数値演算子を使用する条件の場合、Remote Config サービスは、対応するユーザー プロパティの値を整数または浮動小数点の数値に変換します。 |
[正規表現を含む] 演算子を使用する場合は、正規表現を RE2 形式で作成できます。正規表現は対象バージョン文字列の全部または一部に一致させることができます。また、対象文字列の先頭、末尾、または全体と一致させるために ^ と $ アンカーを使うこともできます。 |
国 / 地域 | なし | テスト対象とする可能性のあるユーザーを選択するための、1 つ以上の国またはリージョン。 | |
言語 | なし | テスト対象とする可能性のあるユーザーを選択するために使用する、1 つ以上の言語とロケール。 | |
初回起動 |
次より大きい
次より少ない 次の範囲 |
ユーザーの初回起動日に基づいてユーザーをターゲティングします(日数で指定します)。 | |
前回のアプリ エンゲージメント |
次より大きい
次より少ない 次の範囲 |
ユーザーが最後にアプリを利用した日時に基づいてユーザーをターゲティングします(日数で指定します)。 |
A/B Testing 個の指標
テストを作成する際には、最も効果的なバリアントの判別に使用されるメイン指標(目標指標)を選択します。また、各テスト バリアントのパフォーマンスを詳しく把握し、各パターンで異なる重要な傾向(ユーザー維持率、アプリの安定性、アプリ内購入による収益など)を追跡できるように、他の指標も追跡する必要があります。テストでは、目標以外の指標を最大で 5 つまで追跡できます。
たとえば、新しいアプリ内購入をアプリに追加し、ユーザーに働きかける 2 つのメッセージの効果を比較したいとします。この場合、アプリ内購入の収益が最も高かった通知を表す効果的なバリアントを特定したいため、購入による収益を目標指標として設定することをおすすめします。また、後にコンバージョンとユーザー維持率を改善したバリアントを追跡するため、追跡する他の指標に次のものを追加します。- 収益の推定総額: アプリ内購入と広告収益の総計が 2 つのバリアントでどのように異なるかを示します。
- 定着(1 日)、定着(2~3 日)、定着(4~7 日) 1 日または 1 週間のユーザー維持率を追跡します。
次の表に、目標指標と他の指標の計算方法の詳細を示します。
目標指標
指標 | 説明 |
---|---|
クラッシュの影響を受けていないユーザー | テスト中に 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 イベント。コンバージョン プロセスの一環として使用されます。 |
その他の指標
指標 | 説明 |
---|---|
notification_dismiss | Notifications Composer によって送信された通知が拒否されたときにトリガーされる Analytics イベント(Android のみ)。 |
notification_receive | アプリがバックグラウンドで動作している場合に、Notifications Composer によって送信された通知が受信されたときにトリガーされる Analytics イベント(Android のみ)。 |
os_update | デバイスのオペレーティング システムがいつ新しいバージョンに更新されるかを追跡する Analytics イベント。詳細については、自動収集イベントをご覧ください。 |
screen_view | アプリ内で表示されるスクリーンを追跡する Analytics イベント。詳細については、スクリーン ビューの追跡をご覧ください。 |
session_start | アプリ内のユーザー セッション数をカウントする Analytics イベント。詳細については、自動収集イベントをご覧ください。 |
BigQuery へのデータのエクスポート
Firebase コンソールで A/B Testing のテストデータを表示するだけでなく、BigQuery でテストデータを検査して分析することもできます。A/B Testing に個別の BigQuery テーブルは含まれませんが、テストとバリアントのメンバーシップは Analytics イベント テーブル内のすべての Google Analytics イベントに保存されます。
テスト情報を含むユーザー プロパティは、userProperty.key like "firebase_exp_%"
または userProperty.key =
"firebase_exp_01"
の形式です。01
はテスト ID であり、userProperty.value.string_value
にはテスト バリアントの(ゼロから始まる)インデックスが含まれます。
これらのテスト ユーザー プロパティを使用すると、テストデータを抽出できます。これにより、さまざまな方法でテスト結果を分割し、A/B Testing の結果を個別に検証できます。
開始するには、このガイドの説明に沿って次の操作を行います。
- Firebase コンソールで Google Analytics の BigQuery エクスポートを有効にする
- BigQuery を使用して A/B Testing データにアクセスする
- クエリの例を確認する
Firebase コンソールで Google Analytics の BigQuery エクスポートを有効にする
Spark プランをご利用の場合は、BigQuery サンドボックスを使用して、サンドボックスの制限内で BigQuery に無料でアクセスできます。 詳細については、料金と BigQuery サンドボックスをご覧ください。
まず、Analytics データを BigQuery にエクスポートできるようにします。
- [統合] タブを開きます。このタブには、Firebase コンソールで、 > [>] を選択してアクセスできます。
- 他の Firebase サービスですでに BigQuery を使用している場合は、[管理] をクリックします。それ以外の場合は、[リンク] をクリックします。
- [Firebase の BigQuery へのリンクについて] を確認し、[次へ] をクリックします。
- [統合を構成する] セクションで、[Google Analytics] の切り替えボタンをオンにします。
リージョンを選択し、エクスポートの設定を選択します。
[BigQuery へのリンク] をクリックします。
データのエクスポート方法によっては、テーブルが使用可能になるまでに 1 日かかることがあります。BigQuery に対するプロジェクト データのエクスポートの詳細については、プロジェクト データを BigQuery にエクスポートするをご覧ください。
BigQuery の A/B Testing データにアクセスする
特定のテストのデータをクエリする前に、クエリで使用する次の一部またはすべてを取得することをおすすめします。
- テスト ID: [テストの概要] ページの URL から取得できます。たとえば、URL が
https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25
のような場合、テスト ID は 25 です。 - Google Analytics プロパティ ID: これは、9 桁の Google Analytics プロパティ ID です。Google Analytics 内で確認できます。プロジェクト名を展開して Google Analytics イベント テーブル(
project_name.analytics_000000000.events
)の名前を表示すると、BigQuery にも表示されます。 - テスト日: クエリをより短時間で、効率的に作成するには、クエリの対象を、テストデータ(接尾辞
YYYYMMDD
で識別されるテーブル)を含む Google Analytics の日別イベント テーブル パーティションに限定することをおすすめします。たとえば、テストを 2024 年 2 月 2 日から 2024 年 5 月 2 日まで実施した場合は、_TABLE_SUFFIX between '20240202' AND '20240502'
を指定します。例については、特定のテストの値を選択するをご覧ください。 - イベント名: 通常は、テストで構成した目標指標に対応しています。たとえば、
in_app_purchase
イベント、ad_impression
イベント、user_retention
イベントなどです。
クエリの生成に必要な情報を収集したら、次の操作を行います。
- Google Cloud コンソールで BigQuery を開きます。
- プロジェクトを選択し、[SQL クエリを作成] を選択します。
- クエリを追加します。実行するクエリの例については、クエリの例を確認するをご覧ください。
- [実行] をクリックします。
Firebase コンソールの自動生成クエリを使用してテストデータをクエリする
Blaze プランを使用している場合は、[テストの概要] ページに、表示しているテストのテスト名、バリアント、イベント名、イベント数を返すサンプルクエリが表示されます。
自動生成クエリを取得して実行するには:
- Firebase コンソールで [A/B Testing] を開き、クエリする A/B Testing テストを選択して、[テストの概要] を開きます。
- [オプション] メニューの [BigQuery との統合] で、[テストデータをクエリ] を選択します。これにより、Google Cloud コンソール内に BigQuery のプロジェクトが開き、テストデータのクエリに使用できる基本的なクエリが表示されます。
次の例は、「Winter welcome experiment」という 3 つのバリアント(ベースラインを含む)を使用したテストで生成されるクエリを示しています。アクティブなテスト名、バリアント名、ユニーク イベント、各イベントのイベント数が返されます。クエリビルダーはプロジェクト内で直接開かれるため、テーブル名の中でプロジェクト名が指定されることはありません。
/*
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
その他のクエリの例については、クエリの例を確認するをご覧ください。
クエリの例を確認する
以下の各セクションでは、Google Analytics イベント テーブルから A/B Testing テストデータを抽出する際に使用できるクエリの例を示します。
すべてのテストから購入とテストの標準偏差値を抽出する
テスト結果のデータを使用して、Firebase A/B Testing の結果を個別に検証できます。次の BigQuery SQL ステートメントは、テスト バリアント、各バリアントのユニーク ユーザー数を抽出し、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