「Firebase AB Testing」でサクッとABテスト
Firebase AB Testing で AB テストが簡単にできるよ！実際に個人で開発しているアプリを対象に設定から結果までやってみました！という記事です
AB テストとは
A/B テストとは、2 つの異なるバージョンのコンテンツ（A と B）をランダムにユーザーに配信し、その効果を比較する手法です。
目的は、どちらのバージョンがより良い結果をもたらすかを検証することです。例えば、広告の表示間隔やウェブページのデザインなどをテストし、どちらがユーザーの反応が良いかを確認します。
NetFlix が行っていた AB テストの例 :（https://goodui.org/leaks/ より引用）
実際に試してみる！
私は現在本気のチンチロというチンチロアプリを開発しています。（サイコロを転がすゲームです）
アプリのフィードバックとして出た目の履歴に行くボタンがイケてない。よくわからないというご意見をいただきました。
そこで、ボタンのアイコンを変えてどれが一番いいかユーザーに AB テストを行って検証してみます
うーんダサい！
対象郡
| ベースライン | チャレンジャー１ | チャレンジャー２ |
|---|---|---|
 |
 |
 |
※ Icon は全て Material Icon
※ ここのアイコンのセンスに関してはこの記事の対象外とさせてください
今回の AB テストについて簡単に言うと
ユーザーを３グループに分けてそれぞれのグループに上記の各アイコンを表示する。
一番効果が良かったアイコンを確認する
ということです。
設定
Firebase AB Testing を選択
設定の初期画面
アプリごとに選択しなければなりません。iOS と Android で実験したいときはすこし面倒。
ポイント 1: 対象割合の決定ができる
この変更は影響が大きいのでミニマムに抑えたい…というときは対象割合を調整することができます。
が、有意な結果を検証するための時間が必要になります。1%にしたときは 100%の 100 倍の時間がかかるということです。
ポイント 2: アクティベートイベント(オプション)が選択できる
これは AB テストを有効にするイベントの選択ができます。
たとえば、このアイコンの例でいうとそのモードにいかなければ表示されることもないのでモードに入っていないユーザーは対象外になるようにすることができます
目標の設定
目標設定
評価を行うイベントです。
今回はメインイベントにタップされた回数を置きました。
このイベントに対して有意な結果がでたかを検証できます
サブイベントに定着や、収益的な部分をおきました。
今考えるとタップされた回数が目標に適しているかは議論がありそうですが、履歴は１度タップされたら何度も確認されるものという仮説でした。個人開発なのであまり深くは考えていません
ターゲット（バリアント）の設定
ターゲット設定
キーと対応する値を決めます。
ここではベースラインから 0,1,2 の番号を振っています。
実際の実装（Flutter）では以下のようになっています
また設定の取得も数行で済みます。
// 履歴を示すアイコンの番号を取得
RemoteConfigService.instance.setDefaults({historyIconNumberKey: 0});
historyIconNumber =
RemoteConfigService.instance.getIntValue(historyIconNumberKey);
ターゲットの重み付け
バリアントの重み付け
デフォルトでは等分ですが選択できるみたいです。基本は等分かな
ドラフトの確認と開始
開始前の状態
初期状態ではドラフトですぐには実行されません
「開始」を押すことで実行開始されます
結果の確認
対象ユーザーの母数にもよりますがしばらくおいて置くことで結果が出ます。
開始直後
数日おいた結果
結論: レシートのアイコンが一番タップされる！！
最も数字が良かった Receipt の Material icon👍
ということでもう少し流して見てこのまま問題なければとりあえず全設定をレシートのアイコンにします。
暫定対応としてすべての値を修正することで Firebase 上でも完結することができます。
統計的に優位か？も含めて、キーイベントに対する評価やユーザー数が確認できるところはとても良いですね！
所感
AB テストの注意ですが効果量（影響を与える割合）が大きければ少ないユーザーですみますが、効果サイズが小さいと多くのユーザーが必要になります。
私のアプリでは他には広告の表示間隔や広告表示の有無などを行っています、こちらはなかなか統計的な優位な結果がでていません
Duolingo の AB テストの投稿を見て興味深かったと同時に因数おおすぎない？と思っていたけれどこれくらい大きく行くのがかえってシンプルなのかもしれない
| Version A | VersionB |
|---|---|
|
|
Duolingo で行った A/B テスト。
Version B がよりパフォーマンスが良かったのはもちろんビジュアルなどの理由もあるが、実は一番の要因はそこではない。
多くのデザイナーはカウントダウンが要因と答えるかもしれないが、実は既に年間プランを既に選んでいるのが大事だった。
https://x.com/tmiyatake1/status/1794882131656945775 >
Discussion