Firebase A/B テストについて

テスト結果の関連性と有用性を最大化できるように、このページでは Firebase A/B Testing の仕組みについて詳しく説明します。

サンプルサイズ

Firebase A/B Testing の推論では、テストを開始する前に最小サンプルサイズを特定する必要はありません。一般的には、妥当と感じられる最大のテスト露出レベルを選択する必要があります。サンプルサイズを大きくすると、特にバリアント間のパフォーマンスの差が小さい場合に、統計的に有意な結果が見つかる可能性が高まります。オンラインのサンプルサイズ計算ツールを利用して、テストの特性に基づいて推奨されるサンプルサイズを得ることもおすすめします。

テストの編集

実行中のテストについて選択した次のようなパラメータを編集できます。

  • テスト名
  • 説明
  • ターゲティング条件
  • バリアントの値

テストを編集するには:

  1. 変更するテストの結果ページを開きます。
  2. [その他] メニューで [実行中のテストを編集] を選択します。
  3. 必要に応じて変更を加え、[公開] をクリックします。

テストの実行中にアプリの動作を変更すると、結果に影響することがありますのでご注意ください。

Remote Config バリアントの割り当てロジック

すべてのテスト ターゲティング条件（露出率に関する条件を含む）に一致するユーザーが、バリアントの重みづけと、テスト ID とユーザーの Firebase インストール ID のハッシュに基づいてテスト バリアントに割り当てられます。

Google アナリティクスのオーディエンスはレイテンシの影響を受けるため、ユーザーが初めてオーディエンスの条件を満たした際にすぐには利用できません。

  • 作成したオーディエンスにユーザーが追加されるまでには、24～48 時間かかることがあります。
  • 新規ユーザーは通常、オーディエンスの条件を満たしてから 24～48 時間後に対象オーディエンスに登録されます。

時間的制約のあるターゲティングの場合は、Google アナリティクスのユーザー プロパティや、国や地域、言語、アプリのバージョンなどの組み込みのターゲティング オプションを使用することをおすすめします。

ユーザーがテストに参加すると、該当するテスト バリアントに持続的に割り当てられ、テストが有効である限り、ユーザー プロパティが変更されてテストのターゲティング条件を満たさなくなっても、テストからパラメータ値を受け取ります。

アクティベーション イベント

アクティベーション イベントのテストでは、アクティベーション イベントをトリガーしたアプリユーザーのみがテストの対象になります。 テストのアクティベーション イベントは、アプリによってフェッチされるテスト パラメータには影響しません。テストのターゲティング条件を満たすすべてのユーザーがテスト パラメータを受け取ります。そのため、テスト パラメータがフェッチされ有効化された後、テスト パラメータを使用してアプリの動作を変更する前に、発生するアクティベーション イベントを選択することが重要です。

バリアントの重み付け

テストの作成中にデフォルトのバリアントの重み付けを変更することで、バリアントに配置するテストユーザーの割合を増やすことができます。

テスト結果を解釈する

Firebase A/B Testing では、頻度主義的推論を使用して、偶然性だけによってテスト結果が生じている可能性を把握できます。この可能性は、確率値または p 値で表されます。p 値は、2 つのバリアント間のパフォーマンスの差異が偶然によって生じた可能性がある確率で、0～1 の値で測定されます。A/B Testing が使用する有意水準は 0.05 であるため、次のようになります。

  • p 値が 0.05 未満の場合、バリアント間の差に統計的有意性があることを示します。つまり、確率が偶然発生した可能性が低いということです。
  • p 値が 0.05 より大きい場合は、バリアント間の差が統計的に有意ではないことを示します。

テストデータは 1 日に 1 回更新され、最終更新日時はテスト結果ページの上部に表示されます。

テスト結果のグラフには、選択した指標の累積平均値が示されます。たとえば、ユーザーあたりの広告収益を指標としてトラッキングしている場合は、ユーザーごとの実測収益が表示されます。クラッシュの影響を受けていないユーザーをトラッキングしている場合は、クラッシュに遭遇していないユーザーの割合が追跡されます。このデータは、テスト開始からの累積データです。

結果は実測データと推論データに分けられます。実測データは Google アナリティクス データから直接計算されます。推論データは実測データの統計的有意性を評価する際に役立つ p 値と信頼区間を提供します。

指標ごとに、次の統計情報が表示されます。

実測データ

  • トラッキングされた指標の合計値（保持しているユーザー数、クラッシュしたユーザーの数、総収益）
  • 指標固有の率（維持率、コンバージョン率、ユーザーあたりの収益）
  • バリアントとベースラインの差異（伸び）の割合

推論データ

  • 95% CI（平均値の差）は、トラッキングされる指標の「真」値を 95% の信頼度で含む区間を表します。たとえば、テストの結果、推定総収益の 95% CI が $5～$10 となった場合、平均値の真の差が $5～$10 である可能性は 95% です。CI 範囲に 0 が含まれている場合、バリアントとベースラインの間に統計的有意差は検出されなかったことになります。

    信頼区間の値は、トラッキングされる指標と一致する形式で表示されます。たとえば、ユーザー維持率の場合は期間（HH:MM:SS）、ユーザーあたりの広告収益の場合は米ドル、コンバージョン率の場合は割合（%）です。

  • P 値は、バリアントとベースラインの間に真の差がない確率を表します。つまり、P 値が大きいと、観測された差異が偶然によるものの可能性が高くなります。p 値が小さいほど、観測されたパフォーマンスが将来も真であり続けるという信頼度が高くなります。0.05 以下の値は、有意差があることをを示し、結果が偶然によるものの可能性は低くなります。P 値は片側テストに基づいています。この場合、バリアントの値はベースライン値よりも大きくなります。Firebase は、連続変数（収益などの数値）には不等分散 t 検定、コンバージョン データ（ユーザー維持率、クラッシュの影響を受けていないユーザー、Google アナリティクス イベントをトリガーしたユーザーなどのバイナリ値）には比率の z 検定を使用します。

テスト結果は、各テスト バリアントに関する次のような重要な分析情報を提供します。

  • 直接測定した各テスト指標（つまり、実際の測定データ）が、ベースラインと比較してどの程度高いか、または低いか
  • バリアントとベースラインの間で観測された差が、偶然によって生じた可能性（p 値）
  • 各テスト指標について、バリアントとベースライン間のパフォーマンスの「真」の差が含まれる可能性が高い範囲（「最良のケース」と「最悪のケース」のパフォーマンス シナリオを理解するための方法）

Google オプティマイズを活用したテストの結果を解釈する

2023 年 10 月 23 日より前に開始されたテストの Firebase A/B Testing 結果は、Google オプティマイズを利用していました。Google オプティマイズは、ベイズ推定を使用してテストデータから有益な統計情報を生成していました。

結果は「実測データ」と「推定データ」に分けられます。 実測データはアナリティクス データから直接計算され、推定データは実測データにベイズモデルを適用したものでした。

指標ごとに、次の統計情報が表示されます。

実測データ

  • 合計値（バリアント内のすべてのユーザーの指標の合計）
  • 平均値（バリアント内のユーザーの指標の平均値）
  • ベースラインとの差異（%）

推定データ

  • ベースラインを上回る確率: ベースラインと比較して、このバリアントの指標が高い可能性
  • ベースラインとの差異の割合: バリアントとベースラインに関する指標の中央値モデル推定に基づく値
  • 指標の範囲: 指標の値が見つかる可能性が最も高い範囲（50% と 95% の確実性）

総合的には、テスト結果から、テストの各バリアントについて、次の 3 つの重要な分析情報が得られます。

  1. 直接測定した各テスト指標（実際の測定データ）が、ベースラインと比較してどの程度高いか、または低いか
  2. ベイズ推定に基づいた各テスト指標が、ベースラインより高い、または全体的に最高である可能性（それぞれ、より良い / 最良である可能性）
  3. ベイズ推定に基づいた各テスト指標の現実的な範囲（「最善」と「最悪」のシナリオ（信用区間））

リーダー（効果的なバリアント）の決定

頻度論的推論を使用するテストでは、目標指標に関してバリアントとベースラインの間に統計的に有意なパフォーマンスの差がある場合、Firebase はバリアントがリーダーであると宣言します。複数のバリアントがこの条件を満たす場合は、p 値が最も低いバリアントが選択されます。

Google オプティマイズを使用したテストでは、プライマリ指標のベースライン バリアントよりも優れている可能性が 95% を超える場合、Firebase はバリアントが「クリアリーダー」であると宣言していました。複数のバリアントが「クリアリーダー」の条件を満たしている場合、全体的なパフォーマンスが最も高いバリアントのみが「クリアリーダー」としてラベル付けされました。

リーダーの決定は主要な目標のみに基づいているため、リーダー バリアントを展開するかどうかを決定する前に、関連するすべての要素を検討し、二次的指標の結果を確認する必要があります。変更によって予想されるメリット、デメリットのリスク（信頼区間の下限の改善必要性など）や、プライマリ以外の指標への影響を考慮することをおすすめします。

たとえば、メインの指標がクラッシュの影響を受けていないユーザー数で、バリアント A がベースラインより効果的なクリアリーダーであっても、バリアント A のユーザー維持率指標がベースラインのユーザー維持率を下回る場合は、バリアント A を広く展開する前にさらに詳しく調査することをおすすめします。

プライマリ指標とセカンダリ指標の両方の全体的なパフォーマンスの評価に基づいて、リーダー バリアントだけでなく、任意のバリアントを展開できます。

テスト期間

Firebase では、次の条件が満たされるまでテストを続行することをおすすめします。

  1. テストで十分なデータが蓄積され、有用な結果が得られた。 テストと結果データは 1 日 1 回更新されます。オンラインのサンプルサイズ計算ツールを利用して、テストの推奨サンプルサイズを評価することをおすすめします。
  2. ユーザーの代表サンプルを確保し、長期的なパフォーマンスを測定するのに十分な期間テストを実行した。一般的な Remote Config テストでは、推奨される最小実行期間は 2 週間です。

テストデータは、テストの開始後最大 90 日間処理されます。90 日が経過すると、テストは自動的に停止されます。テストの結果は Firebase コンソールで更新されなくなり、テスト固有のパラメータ値がテストによって送信されなくなります。この時点で、クライアントは Remote Config テンプレートで設定された条件に基づいてパラメータ値の取得を開始します。過去のテストデータは、ユーザーが削除するまで保持されます。

BigQuery のスキーマ

Firebase コンソールで A/B Testing のテストデータを表示するだけでなく、BigQuery でテストデータを検査して分析することもできます。A/B Testing に個別の BigQuery テーブルは含まれませんが、テストとバリアントのメンバーシップはアナリティクス イベント テーブル内のすべての Google アナリティクス イベントに保存されます。

テスト情報を含むユーザー プロパティは、userProperty.key like "firebase_exp_%" または userProperty.key = "firebase_exp_01" の形式です。01 はテスト ID であり、userProperty.value.string_value にはテスト バリアントの（ゼロから始まる）インデックスが含まれます。

これらのテスト ユーザー プロパティを使用すると、テストデータを抽出できます。これにより、さまざまな方法でテスト結果を分割し、A/B Testing の結果を個別に検証できます。

開始するには、このガイドの説明に沿って次の操作を行います。

  1. Firebase コンソールで Google アナリティクスの BigQuery Export を有効にする
  2. BigQuery を使用して A/B Testing データにアクセスする
  3. クエリの例を確認する

Firebase コンソールで Google アナリティクスの BigQuery Export を有効にする

Spark プランをご利用の場合は、BigQuery サンドボックスを使用して、サンドボックスの制限内で BigQuery に無料でアクセスできます。詳細については、料金と BigQuery サンドボックスをご覧ください。

まず、アナリティクス データを BigQuery にエクスポートできるようにします。

  1. [統合] タブを開きます。このタブにアクセスするには、Firebase コンソールで、 > [プロジェクトの設定] の順に選択します。
  2. 他の Firebase サービスですでに BigQuery を使用している場合は、[管理] をクリックします。それ以外の場合は、[リンク] をクリックします。
  3. [Firebase と BigQuery のリンクについて] を確認し、[次へ] をクリックします。
  4. [統合を構成する] セクションで、[Google アナリティクス] の切り替えボタンをオンにします。

  5. リージョンを選択し、エクスポートの設定を選択します。

  6. [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 アナリティクスのプロパティ ID: 9 桁の Google アナリティクスのプロパティ ID です。Google アナリティクス内で確認できます。プロジェクト名を展開して Google アナリティクス イベント テーブル（project_name.analytics_000000000.events）の名前を表示すると、BigQuery にも表示されます。
  • テスト日: クエリをより短時間で、効率的に作成するには、クエリの対象を、テストデータ（接尾辞 YYYYMMDD で識別されるテーブル）を含む Google アナリティクスの日別イベント テーブル パーティションに限定することをおすすめします。たとえば、テストを 2024 年 2 月 2 日から 2024 年 5 月 2 日まで実施した場合は、_TABLE_SUFFIX between '20240202' AND '20240502' を指定します。例については、特定のテストの値を選択するをご覧ください。
  • イベント名: 通常は、テストで構成した目標指標に対応しています。たとえば、in_app_purchase イベント、ad_impression イベント、user_retention イベントなどです。

クエリの生成に必要な情報を収集したら、次の操作を行います。

  1. Google Cloud コンソールで BigQuery を開きます。
  2. プロジェクトを選択し、[SQL クエリを作成] を選択します。
  3. クエリを追加します。実行するクエリの例については、クエリの例を確認するをご覧ください。
  4. [実行] をクリックします。

Firebase コンソールの自動生成クエリを使用してテストデータをクエリする

Blaze プランを使用している場合は、[テストの概要] ページに、表示しているテストのテスト名、バリアント、イベント名、イベント数を返すサンプルクエリが表示されます。

自動生成クエリを取得して実行するには:

  1. Firebase コンソールで A/B Testing を開き、クエリする A/B Testing テストを選択して、[テストの概要] を開きます。
  2. [オプション] メニューの [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 アナリティクスのイベント テーブルから 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

上限

A/B Testing では、合計テストは 300 件、実施中のテストは 24 件、未公開状態のテストは 24 件に制限されています。

  • テストの合計が上限の 300 件、または未公開状態のテストが上限の 24 件に達した場合は、新しいテストを作成する前に、既存のテストを削除する必要があります。

  • 実行中のテストが上限の 24 件に達した場合は、新しいテストを開始する前に実行中のテストを停止する必要があります。

テスト 1 件につき最大 8 個のバリアント（ベースラインを含む）を作成でき、バリアントごとに最大 25 個のパラメータを含めることができます。 テストのサイズは最大約 200 KiB です。これには、バリアント名、バリアント パラメータ、その他の構成メタデータが含まれます。