このページは Cloud Translation API によって翻訳されました。

A/B Testing を使用して In-App Messaging のテストを作成する

ユーザーに働きかけたり、新しいマーケティングキャンペーンを開始したりするときには、確実に効果が得られるように方策を練る必要があります。A/B テストでは、ユーザーベース内の選択した集合を対象にいくつかのメッセージバリアントをテストすることにより、最適な表現や見せ方を見つけられます。リテンション（ユーザー維持率）の改善が目的の場合も、オファーに対するコンバージョンの改善が目的の場合も、A/B テストで統計的分析を実行することにより、選択した目的に照らしてメッセージの特定のバリアントがベースラインよりも効果的かどうかを判断できます。

ベースラインを使って機能バリアントの A/B テストを実施するには:

テストを作成します。
テストデバイスでテストを検証します。
テストを管理します。

テストを作成する

Firebase In-App Messaging を使用するテストでは、1 つのアプリ内メッセージの複数のバリアントを評価できます。

Firebase コンソールにログインし、プロジェクトで Google Analytics が有効になっていることを確認します。これにより、テストで Analytics データにアクセスできるようになります。

プロジェクトの作成時に Google Analytics を有効にしていない場合は、[統合] タブで有効にすることができます。このタブには、Firebase コンソールで、 > [プロジェクトの設定] を選択してアクセスできます。
Firebase コンソールのナビゲーションメニューの [エンゲージメント] セクションで、[A/B Testing] をクリックします。
[テストを作成] をクリックし、テストするサービスの選択を求めるメッセージが表示されたら [In-App Messaging] を選択します。
または、Firebase コンソールのナビゲーションメニューで [エンゲージメント] を開き、[In-App Messaging] をクリックします。[新しいテスト] をクリックします。
テストの名前とオプションの説明を入力し、[次へ] をクリックします。
[ターゲット設定] の各フィールドに入力します。最初に、そのテストを使用するアプリを選択します。また、次のオプションを選択することによって、テストに参加してもらうユーザーサブセットをターゲットに設定できます。
- バージョン: アプリの 1 つ以上のバージョン。
- ユーザーオーディエンス: テストに含める可能性のあるユーザーをターゲットとして設定するための Analytics のユーザーオーディエンス
- ユーザープロパティ: テスト対象とする可能性のあるユーザーを選択するための、1 つ以上の Analytics ユーザープロパティ
- 国 / 地域: テスト対象とする可能性のあるユーザーを選択するための 1 つ以上の国またはリージョン。
- デバイスの言語: テストに含める可能性のあるユーザーを選択するための、1 つ以上の言語とロケール。
- 初回起動: アプリの初回起動に基づいてターゲットに設定するユーザー。
- 前回のアプリエンゲージメント: 最後にアプリを利用した日時に基づいてターゲットに設定するユーザー。
注: Analytics のユーザーオーディエンスをターゲットにしたテストでは、データの収集に 24〜48 時間かかることがあります。このオプションとその他のターゲティングオプションの詳細については、ユーザーターゲティングをご覧ください。
[ターゲットユーザーの割合] の設定: テストのベースラインと 1 つ以上のバリアントの間で均等に分散させる、[ターゲットユーザー] で設定した条件に一致するアプリのユーザーベースの割合を選択します。これは 0.01%～100% の任意のパーセント値にすることができます。パーセント値は、重複したテストも含め、各テストでユーザーにランダムに再割り当てされます。
[バリアント] セクションで、通常のアプリ内メッセージングキャンペーンで使用するベースラインのアプリ内メッセージを構成します。このメッセージは、メッセージデザインインターフェースを使用してベースライングループに送信します。
テストにバリアントを追加するには、[バリアントを追加] をクリックします。デフォルトでは、テストには 1 つのベースラインと 1 つのバリアントがあります。
（省略可）各バリアントに、よりわかりやすい名前を入力します。
（省略可）[バリアント] セクションの上部にある [バリアントの比較] ボタンをクリックして、ベースラインメッセージと比較します。
リストから、テストのバリアントを評価する際に使用するテストの目標指標と使用する追加の指標を選択して定義します。この指標には、組み込みの目標（エンゲージメント、購入、収益、維持率など）、Analytics コンバージョンイベント、その他の Analytics イベント。
テストのスケジュールを構成します。
- テストの開始日と終了日を設定します。
- すべてのバリアントでアプリ内メッセージをトリガーする方法を設定します。
[レビュー] をクリックしてテストを保存します。

プロジェクトあたり最大 300 個のテストを使用できます。その内訳は、実行中のテストが最大 24 個まで、残りはドラフトまたは完了済みのテストになります。

テストデバイスでテストを検証する

Firebase の各インストールに関連付けられているインストール認証トークンを取得できます。このトークンを使用して、アプリがインストールされているテストデバイス上の特定のテストバリアントをテストできます。テストデバイスでテストを検証する方法を次に示します。

次のようにインストール認証トークンを取得します。

Swift

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");
        }
    }
});MainActivity.java

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")
        }
    }MainActivity.kt

Firebase コンソールのナビゲーションバーで、[A/B Testing] をクリックします。
[ドラフト]（Remote Config テストでは [実行中] の場合もあり）をクリックし、テストにカーソルを合わせてコンテキストメニュー（）をクリックしてから、[テストデバイスを管理] をクリックします。
テストデバイスのインストール認証トークンを入力して、そのテストデバイスに送信するテストバリアントを選択します。
アプリを実行して、選択したバリアントがテストデバイスで受信されていることを確認します。

Firebase インストールの詳細については、Firebase インストールの管理をご覧ください。

テストを管理する

テストの作成に 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 イベント。詳細については、自動収集イベントをご覧ください。