Firebase Remote Config と Analytics を使用する

Firebase Remote Config と Firebase Analytics の両方を含むアプリを作成すると、アプリのユーザーについて詳細に把握し、ユーザーのニーズにすばやく対応することができます。これらの機能を組み合わせることで、以下を行うことができます。

Firebase Analytics によるアプリの使用状況の分析について詳しくは、Firebase Analytics の概要をご覧ください。

Remote Config およびユーザー プロパティ

Remote Config で、Analytics のユーザー プロパティを使用して条件を作成できるようになりました。これにより、定義したユーザー層のセグメントに対するアプリのカスタマイズが、以前よりも格段に正確にできるようになります。

Remote Config と Analytics ユーザーリストを使用する場合、ユーザー プロパティを使用するときにはない、いくつかの制限があります。具体的には、ユーザーはユーザーリストが割り当てられると、そのユーザーリストの永続的なメンバーになります。これに対して、ユーザー プロパティは特定のユーザーに対して一時的にだけ有効になるように定義できます。

たとえば、時間と難易度が異なるさまざまなエクササイズ アクティビティがあるエクササイズ アプリで使用するため、次のユーザー プロパティを Firebase Analytics で定義できます。

  • Exercise_Interest
  • Preferred_Exercise_Duration
  • Preferred_Difficulty_Level

次に、これらのプロパティを使用する条件を(個別に、または組み合わせて)作成して、特定のユーザーに対してアプリの外観や動作をカスタマイズできます。たとえば、ランニングに興味を持っているユーザーには、アプリのロード中にジョギングする人の画像を表示するようにアプリを設計することができます。または、エクササイズの時間と難易度によってユーザー層のセグメントを定義して、アプリを起動したときに、カジュアル ユーザーには最初に短時間の簡単なワークアウトの提案を表示し、本格的なアスリートには 40 分間のランニングから始める提案を表示することができます。

ユーザーの行動にユーザー プロパティを変えるような変化があった場合、Firebase Analytics によってこれらの更新が収集され、次回のフェッチ リクエスト後にアプリ インスタンスの動作と外観が変更されることがあります。あらゆる演算子を使用できるため、特定のユーザー プロパティ(またはプロパティの組み合わせ)を持つユーザーを除外したり含めたりするルールを作成できます。

また、他の Remote Config ルールとユーザー プロパティに基づくルールを組み合わせて、カスタマイズしたアプリの動作を、次のようにユーザー層に配信することができます。

  • ヨガが好きなユーザー(Exercise_Interestyoga に完全一致)、Android 搭載端末でアプリを使用していて(OS type == Android)、カナダにいる(Device in region/country == Canada)ユーザー
  • ウェイト リフティングまたは減量に興味を持っているユーザー(Exercise_Interestweight が含まれる)、英語 UI(Device language ==English)の iOS 搭載端末でアプリを使用しているユーザー(OS type == iOS

次のステップ

ユーザ プロパティの詳細については、以下のガイドをご覧ください。

ルールを組み合わせることで条件を作成する方法については、Remote Config のパラメータと条件をご覧ください。

プロジェクトに Remote Config の条件を追加するには、条件を追加または編集するをご覧ください。 パラメータ、ルール、条件は Firebase console で作成できます。

2 つの機能バリエーションの A/B テストを実施する

利用頻度の高いユーザーがいるアプリケーションの新しい機能を作成する場合は間違いがないようにする必要がありますが、次のような点が不確かな場合があります。

  • ユーザー エクスペリエンスを最適化する機能の最適な実装方法。機能を実装する際に複数の異なるデザインが考えられる場合があります。単純に気に入っている方の案を採用することもできますが、すべてのユーザーに機能を公開する前に、ユーザーを代表するサンプルがどちらの案を好むかを調べることができます。この例では、2 つの機能バリエーションの A/B テストを実施する方法を説明します。
  • ユーザーに新しい機能を気に入ってもらえるかどうか。 新機能や新しくなったユーザー エクスペリエンスがユーザーに気に入られていないことが、アプリストアでのアプリの評価が下がって初めてわかることがよくあります。A/B テストのコントロール グループを確立することで、ユーザーがどちらの機能バリエーションを気に入るか、またはアプリを現在のままにすることを望んでいるかを評価することができます。また、大半のユーザーをコントロール グループに含めることによって、テストの結果が出るまで、ほとんどのユーザー層が動作や外観の変更による影響を受けることなくアプリを使い続けることができます。

コントロール グループを使って 2 つの機能バリエーションの A/B テストを実施するには:

  1. Remote Config でテストを設定します。
  2. Analytics ユーザー プロパティを作成します。
  3. A/B テストをサポートするコードをアプリに追加します。

ここからは、シンプルなショッピング アプリで A/B テストを設定する方法について説明します。

Remote Config で A/B テストを設定する

この仮想 A/B テストでは、ShoppingApp というショッピング アプリに追加する新しいプロモーション通知 UI 要素の表示位置について、左側と右側のどちらをアプリユーザーが好むかを調べます。この例では、アプリにはすでに定着したユーザー層があり、画面はさまざまな UI 要素で埋まっているため、この UI 要素を追加することによってアプリを毎日使用するユーザーとアプリから生み出される収益に大きな影響が出る可能性があります。

このような理由から、各機能バリエーションをテストするときはユーザーの一部のみを対象にし、ほとんどのユーザーはテストの対象から外します。

テスト条件

まず、テストで両方のバリエーションを追跡する 2 つの条件を作成します。これらの条件に、「テスト 1」と「バリエーション A と B」であることがわかる名前を付けます。2 つの条件の名前は次のようになります。

  • Experiment_1_Variant_A
  • Experiment_1_Variant_B

この例では、各バリエーションに対してインストール済みアプリ インスタンスの重複しないグループを含めるため、各条件に 1 つ以上のユーザー(ランダム %)ルールを設定します。

条件 ルール
Experiment_1_Variant_A ユーザー(ランダム %)が 5 以下
Experiment_1_Variant_B ユーザー(ランダム %)が 5 より大きい
ユーザー(ランダム %)が 10 以下

条件 Experiment_1_Variant_A に該当するのがアプリ インスタンスの最初の 5%、条件 Experiment_1_Variant_B に該当するのがアプリ インスタンスの次の 5% で、両方の条件に該当するアプリ インスタンスはないという結果になります。各条件にルールを追加して条件をさらに細かくすることもできます。

テスト パラメータ

次に、experiment1 というパラメータを作成して、デフォルト値と条件値を次のように設定します。

  • デフォルト値: None
  • Experiment_1_Variant_A: variant_A
  • Experiment_1_Variant_B: variant_B

experiment1 は、特定のユーザーがどのテストに参加しているかを識別するために使います(参加しているユーザーがいる場合)。この例では、アプリはこのパラメータを使って、テストしている機能の動作も変更します。デフォルト値は None で、「この機能は使用しない」とアプリで解釈されます。その他 2 つの値は、新しいプロモーション通知 UI 要素を画面の左側または右側に表示します。

この例では、1 つのパラメータを使って 1 つの機能をコントロールし、このテストで使用される 2 つのグループを管理します。ただし、ほとんどの場合はさらにパラメータを追加し、それらのパラメータ全体で同じ条件を再利用して、アプリのその他の側面をコントロールします。

Firebase console を使って Remote Config を管理する方法について詳しくは、Remote Config を使用して Firebase プロジェクトを設定する方法Remote Config のパラメータと条件についての記事をご覧ください。

Analytics ユーザー プロパティを作成する

Analytics で MyExperiment というユーザー プロパティを作成し、テストの概要を表す説明を追加します。たとえば、「MyShoppingApp に表示するプロモーション通知 UI 要素の最適な位置のテスト」といった説明にします。

A/B テストをサポートするコードをアプリに追加する

この例に出てくる ShoppingApp アプリが Remote Config と Analytics を使用するようにすでに設定されていれば、このガイドで説明している A/B テストをサポートするために必要なのは次の操作のみです。

  1. アプリによって直近にフェッチ済みのパラメータ値のセットが有効化されたときに、experiment1 パラメータを取得します。
  2. Analytics で作成した MyExperiment ユーザー プロパティに experiment1 パラメータの値を設定します。
    • iOS では、[FIRAnalytics setUserPropertyString: forName:] メソッドを使用します。
    • Android では AppMeasurement.setUserProperty() メソッドを使用します。

    iOS と Android では、これらの手順をたった 2 行のコードで表すことができます。

       NSString *experiment1_variant = [FIRRemoteConfig remoteConfig][@"experiment1"].stringValue;
       [FIRAnalytics setUserPropertyString:experiment1_variant forName:@"MyExperiment"];

    Android の場合:

       String experiment1_variant = FirebaseRemoteConfig.getInstance().getString("experiment1");
       AppMeasurement.getInstance(context).setUserProperty("MyExperiment",experiment1_variant);
  3. experiment1 のパラメータ値を使ってアプリの動作と外観を変更します。この例では、以下の値は次のようにアプリで解釈されます。
    • None: コントロール グループのユーザー エクスペリエンスを変更しない。
    • variant_A: 新しい UI 要素を画面の左側に配置する。
    • variant_B: 新しい UI 要素を画面の右側に配置する。

実際のシナリオでは、アプリで使用するさまざまなパラメータに対して、上記で定義した条件を使用します。

次のステップ

Analytics では、アプリユーザーの 2 つのグループとコントロール グループに関するデータを記録できます。Analytics を使って複数のユーザーリストを作成し、MyExperiment ユーザー プロパティのさまざまな値に基づいて各ユーザーリストの行動を分析することができます。Analytics について詳しくは、Firebase Analytics の概要についての記事をご覧ください。

後からこれらのユーザーリストを使って Analytics ユーザーリストに基づく条件値を持つパラメータをさらに作成することによって、テストを改良し、機能を向上させることができます。詳しくは Remote Config のパラメータと条件についての記事をご覧ください。

フィードバックを送信...