はじめに
こんにちは、カナリー の中野です。
普段は React Native で「CANARY」というお部屋探しのアプリを開発しています。
よりよいアプリにすべく週 1〜2 回のペースでアップデートをしていますが、
新しい施策を打つときは、その効果を検証するために Firebase A/B Testing を利用しています。
CANARY では Firebase A/B Testing の用途として、以下の 2 つの面で利用しています。
- AB Testing - 2 つの機能・UI の優位比較
- Feature flag - 段階的なリリースコントロール
たとえばユーザー影響の大きい変更の場合は
- はじめから全ユーザーを対象とせず、まずは全体の 20% をテスト対象とする。
- その中で 50:50 のテスト（つまり全体の 10% vs 10% のテスト）を開始する。
- 問題なさそうであれば少しずつテスト対象ユーザーを広げていく。
といったような流れです。
さまざまな数字とかけあわせて分析をするので、コンソールだけで判断するのではなく BigQuery にエクスポートして分析しています。
しかし、これを BigQuery で集計して分析しようとしたときに罠がありました。
この記事では「どんな罠があったか」そして「回避するにはどうしたらよいか」をまとめます。
この記事に書いていること
- 対象ユーザーをしぼったテストを BigQuery で集計している場合 Remote Config のデフォルト値を注意しないと分析に困るよということ
- 結論、デフォルト値は baseline でも variant A でもない別の値にしたほうがよい
Remote Config / AB Testing のおさらい
話を進める前に機能についておさらいです
Firebase Remote Config
Firebase のコンソールから設定値を変更することで、ユーザーにアプリのアップデート ver.をダウンロードしてもらわなくても、動作や外観を変更できるサービスです。
Firebase A/B Testing
Remote Config を使用して複数のバリアントでいくつかのパラメータの変更を試し、各バリアント グループ内でアプリの動作や外観をさまざまに変えることができます。この方法は、最適な配色やメニュー オプションの配置といった軽微な変更にも、まったく新しい機能や UI デザインのテストのような大きな変更にも使用できます。
つまり Firebase Remote Config の仕組みを使って AB テストをおこなうサービスです。
対象ユーザーをしぼって AB テストしたい理由
もしテストパターンにバグがあった場合、対象をしぼっていれば影響を最小限にできるからです。
そしてテストパターンが好調であれば上述したように、そのまま少しずつ対象ユーザーを増やしていく段階的リリースも兼ねて実施しています。
「露出」の値を調整して対象ユーザーをしぼっている
対象ユーザーをしぼった AB テストの罠
しかし罠がありました。
仮に対象ユーザーを 20% にしぼって「new-layout」というテストを実施したとします。
テスト開始後に BigQuery で「new-layout」のパラメータを持つデータを抽出して分析しようとしました。
Firebase A/B Testing では基本的に baseline（既存バージョン）と variant A（新機能）で争うことになります。
（テスト内容によっては variant B, variant C が存在することもある）
ここで期待することはテスト対象ユーザーを baseline と variant A の 50:50 に分けて分析することですが、
実際にクエリを叩くと variant A と baseline のユーザー割合が 10:90 のように映ってしまうことがあります。
どうやらテスト対象ではない残りの 80% のユーザーが baseline に割り当てられているようでした。
なぜこんなことが起こるのか
対象ユーザーを 20% にしぼった場合、残りの 80% のユーザーがどのようにふるまうかを考える必要があります。
残りの 80% のユーザーはテスト対象ではなくても Remote Config の値自体は受け取っています。
ここで受け取る値は「デフォルト値」です。
デフォルト値の設定画面
デフォルト値の設定パターンは以下の 3 つです。
- デフォルト値を直接入力して指定する
- 「アプリ内デフォルト値を使用する」にチェックをつける
- 空欄のまま
設定パターンごとに
残りの 80% のユーザーがどのようなデフォルト値を受け取るのかを検証してみました。
-
デフォルト値を直接入力して指定する
- 入力したデフォルト値をそのまま返します
- たとえば「default」と入力した場合、残り 80% のユーザーは「default」を受け取ります
-
「アプリ内デフォルト値を使用する」にチェックをつける
- baseline の値を返します
-
空欄のまま
- baseline の値を返します
つまり「アプリ内デフォルト値」または「空欄」で進めた場合、残り 80% のユーザーには baseline の値を返すので、
結果、BigQuery で集計すると 90:10 のテストのように映ってしまいます。
解決策
- デフォルト値を直接入力して指定する
- baseline でも variant A でもない別の値を入れる
こうすることで baseline と variant A を純粋に比較でき、期待していた 50:50 のテストとして分析できます。
Discussion