Firebase A/B Testingとは
Remote Config または Cloud Messaging を使ってA/B テストを簡単に実行，分析するサービスです。
分析後に、アプリのアップデートなしに変更を反映することも可能です。
流れとしては
テストで評価するグループを作成して、
成功測定のための目標値を設定し、
テストをモニタリングして最良のグループ（施策）を見つける。
です。
A/Bテストとは
主にマーケティングで行われる、施策判断のためのテスト。
- 施策の良し悪しを判断するために、２つ以上(基本は２つ)の施策同士を比較検討することです。
- 測定したい基準を元に、コントロールグループとテストをさせたいグループに分けて後者にチャレンジをさせて結果を比較します。
新しいものを２つ同時にチャレンジさせて比較するものではないようです。
メリット
コンソールで設定して実行するだけなので、簡単に操作してテストを開始することができる。
- それぞれのパターンを設定すれば、出し分けする値を元にアプリの外観や動作を変更してテストできる。
デメリット
- 事前にAnalyticsのイベントだったりユーザープロパティを定義しておかないと細かい出し分け、 期待通りのデータの集計がしづらいので、準備のコストがかかるand設計が難しい。
- A/Bを分けるときのルールを考えるのが難しそう。
- 検証数が少ないと結果が出づらい。
後半は特にこのサービスに限ったことではないデメリットも。
使い方
1.わかりやすいテスト名,どのようなテストかを書く
2.ターゲットを設定する。
ターゲットの条件とターゲットユーザーの割合、オプションでアクティベーションイベントを設定できる。
3.目標を設定する。
メインの指標を設定します。デフォルトで定着率、クラッシュの影響を受けていないユーザーが設定されています。
4. バリアントを設定する。
別のバリアントを追加ボタンを押せば２つ以上のパターンで分析できる。
その後のアクション
検証結果が溜まってくるとFirebaseのコンソール上で結果を確認することができ、
テストの結果を利用するには早すぎるかどうかなどもFirebaseが教えてくれる（らしい）です。
新規機能やデザインの評価が良ければそちらを反映させ、悪ければ既存のものを利用する、といったことをしていきます。
最後に
実際のレビューではバナーの画像URLをRemoteConfigからURLをA/Bで振り分け
どちらの画像の方がタップ数が多いかをテストするケースを作成しました。
デフォルト値が決まっているもの、必ず表示させるべきものが決まっていれば良いですがフェッチに失敗して、
見せてはいけないものや見せたいのに見せれないものは使用しない方が良いですね。FCMとRemoteConfigだけど。
