Firebase で A/B テスト - Remote Config と A/B Testing
はじめに
この記事は，Recruit Engineers Advent Calendar 2018の12日目の記事です．
先日 AB テストのために初めて Firebase の Remote Config を触ったのですが，そのときに「Remote Config と A/B Testing があるけどどっちを使えばいいんだ？」と戸惑ったので，違いをここにまとめます．
本記事で取り扱う内容は以下の通りです．
- 扱う
- Remote Config と A/B Testing の違い
- Remote Config と A/B Testing それぞれにおける A/B テストパターンの割当，パターンの配信方法
- 扱わない
- Analytics 等を使ったイベントログの取得
- 実装の解説
Remote Config と A/B Testing の違い
Remote Config と A/B Testing の違いはざっくりこんな感じです．
- Remote Config
- アプリのパラメータをリモートで管理するサービス．
- そのため，A/B テストにおける AB パターンの割当，アプリへの配信に使える．
- AB Testing
- AB テストを簡単に設計，実行，分析するサービス．
- 配信は Remote Config または Cloud Messaging を使う
よって，Firebase を使った A/B テストの方法は以下の2つが考えられます．
- Remote Config で A/B パターンの管理 + 外部サービスでログ集計・分析
- A/B Testing を中心とした Firebase のみの構成 (下図)
以下でそれぞれについてもう少し詳しく説明します．
Remote Config とは
Firebase Remote Config は、アプリのアップデートをユーザーにダウンロードしてもらわなくても、アプリの動作と外観を変更できるクラウドサービスです。
Remote Config の概要は，以下の通りです．
- Firebase コンソール側でパラメータ (Key-Value ペア) を定義，リアルタイムで配信
- ユーザーセグメント（アプリバージョン，OS，ランダムで指定した割合のユーザ)ごとに Value を変えられる
- 用途
- 機能変更のすばやい公開
- ユーザーベースのセグメントに対してアプリをカスタマイズ
- A/B テスト
参考: Firebase Remote Config for Androidの勘所
A/B Testing とは
Firebase A/B テストを使用すると、製品とマーケティングのテストを簡単に実行、分析、スケーリングできるため、アプリの使用体験の最適化に役立ちます。アプリの UI、機能、エンゲージメント キャンペーンに対する変更をテストし、変更を広範囲にロールアウトする前に変更内容が実際に主要な指標（収益や維持など）に大きな変化をもたらすかどうかを確認することができます。
A/B テストは、さまざまなマーケティング メッセージをテストできるように FCM と連携し、アプリ内での変更をテストできるように Remote Config と連携します。
A/B Testing の概要は，以下の通りです．
- テストで評価するバリアントの定義する
- 成功をどのように測定するかの定義する
- テストをモニタリングして最良のバリアントを見つける
AB テストを実装してみる
以下では，Remote Config, A/B Testing それぞれで AB テストを実装してみます．
ソースコードは公式の quickstart を使います． 本記事では実装の解説を行わないので，解説は Firebase Remote Config の iOS 向けサンプルアプリのチュートリアル をご覧ください．
Remote Config を使った場合
Firebase のセットアップ
まず，ここ の「コンソールへ移動」などから，Firebase のコンソールにログインしてください．
次に，プロジェクトの新規作成をします．
次に，アプリの追加をします．
設定ファイルをダウンロードし，サンプルアプリのプロジェクトへ追加します．
パラメータと条件の設定
パラメータを，以下のように設定します
| パラメータキー | デフォルト値 | A パターン (50%) | B パターン (50%) |
|---|---|---|---|
| welcome_message | Welcome to this sample app | Welcome A | Welcome B |
| welcome_message_caps | false | true | false |
実装について詳しくは説明しませんが，パラメータ値は RemoteConfig.remoteConfig()[【パラメータキー】].stringValue などと呼び出します．たとえば，RemoteConfig.remoteConfig()["welcome_message"].stringValue の値は，Welcome to this sample app, Welcome A, もしくはWelcome B となります．
コンソールで Remote Config を開いて，以下のように設定していきます．
まずパラメータキーとデフォルト値を定義します．
条件を加えていきます．下図は，"WELCOME" というキーでランダムにソートしたユーザの最初から50%を意味します．
同様に条件と値を追加していきます．
キーが同一の場合はソート順も同一になるため，以下の welcome_messege_A と welcome_messege_B はユーザー全体を50%, 50% で分割していることになります．
最後に，「変更を公開」ボタンを押しましょう．これを押さないと，変更が保存されずに破棄されてしまいます．
動作確認
公式の quickstart をビルドし，iOS シミュレータを起動します．
デフォルト時はこのような画面なのですが
Remote Config からパラメータを取得し，表示される文言が「WELCOME A」に変わりました．
Conditions を書き換えてみる
Conditions を以下のように書き換えてみましょう．
Conditions は上から順に評価され，条件を満たした時点でそのセグメントに割り当てられるため，今回は必ず B パターンに割り当てられます．
結果，表示される文言が「Welcome B」に変わりました．
A/B Testing を使った場合
本記事では，A/B テストパターンの割り振りを主に説明します． 集計や分析は取り扱わないため，詳しくは，公式ドキュメント をご覧ください．
Firebase のセットアップ
Remote Config の場合と同様なので省略します．
テストの作成
A/B Testing から 新規テストを作成します．Remote Config を選択します．
このような設定にします．
バリアント（パターン）を2つ作成します．ここで，ややこしいのが割り振られる人数です．1つ前の画像の「ターゲット設定」の「ターゲットユーザーの100%」が，2つのバリアントに等分されます．つまり，ターゲットユーザーの50%がコントロールグループに，残り50%が Variant A に割り当てられます．もしバリアントが3つなら，33.3% ずつが割り当てられるということです．
動作確認
print("InstanceID token: \(InstanceID.instanceID().token())") を使って端末のトークンIDを取得します．
このトークンIDを下記に入力することで，手動でバリアントを制御できます．
テストの開始（は本記事では扱いません）
今回はターゲットをきちんと設定していないため，テストを開始しても失敗します．詳しくは 公式ドキュメント を読み，Analytics との連携などを行ってください．
おわりに
本記事では，Remote Config と A/B Testing の違いについて述べました．
A/B Testing を使えば簡単に A/B テストが作れそうですが，何らかの制約で Google Analytics を使えずに外部サービスを使う必要がある場合などに，本記事が参考になれば幸いです．
