2021.10.08

FirebaseのA/B Testing・Personalizationはビジネスでどれほど活用できるのだろうか

こんにちは。次世代システム研究室のY. O.です。

今回は、mBaaS (mobile Backend as a Service)の筆頭であるFirebaseで提供されるA/B testing(βリリース)・Personalization(αリリース)について、その活用方法をビジネス観点で考えてみます。

 

TL;DR

  • Firebase A/B testing
    • 悩んだらユーザに聞いてみる、の精神で相対評価ができれば良いのであれば十分
    • 結局はBigQueryに吐き出して都度分析を行うことになりそう
  • Firebase Remote Config personalization
    • 試したいパターンが複数存在し、手軽にパーソナライズを行いたい場合に便利
    • Firebaseイベント内で評価関数を定義できない場合には利用できず、また、効果測定の実施は一工夫必要
 

はじめに

前回・前々回と因果推論手法について記事を書きました。今回は、因果推論手法の中でも最も基礎的なA/Bテスト周りについて調査した内容を紹介します。このように”因果推論”に取り憑かれているのは、筆者が共に働いている、スマホアプリを運営するグループ会社のチームにて、ビジネス施策を精緻に測定し定量的な意思決定につなげたいと考えているからです。
ビジネスにおける意思決定という内容については、先日GMOインターネットが主催するDevelopers Dayにて講演をしましたので、そちらも合わせて参照ください。[1]

Firebase Remote Configとは

A/B testing・Personalizationについて議論するためには、Firebase Remote Config (以下Remote Config)についての予備知識が必要です。
簡潔に言うと、Remote Configはサーバ側でのパラメータ変更を簡単・高度に行うことができるサービスです。
例えば、アプリのある画面に複数候補の中からどの候補を表示するかをパラメータで制御しているようなケースにおいて、Remote Configのコンソール画面で変更後のパラメータ値を設定するだけで、期間限定である候補を表示させるようにすることができます。

メリットは大きく3つあります。
  • サーバ側の開発が必要ない
  • ユーザ側でアプリのアップデートが必要ない
  • Google Analyticsのユーザセグメントごとにパラメータ設定ができる
 

「サーバ側の開発が必要ない」言わずもがなです。これはmBaaSの提供する価値の本質ですね。

「ユーザ側でアプリのアップデートが必要ない」サーバ側の設定変更のみ行い、アプリが問い合わせをしてきたときの返答が変化するだけなので、アプリのアップデートの必要はありません。
これは2つの面でメリットがあり、1つ目は全ユーザに即時にアプローチできることです。OSごとに傾向は異なりますが、アプリの新バージョンをリリースしてもすぐに全ユーザがアップデートをしてくれるわけではありません。
2つ目は効果測定時のバイアスを除去できることです。アプリを能動的にアップデートするユーザはアプリを普段から活用してくださっていたり、スマホ自体の利用頻度が高いユーザであったりする可能性が高いです。そのような状況で、「アップデートバージョンの〇〇という機能改善により滞在時間が〇〇分延びた」というような効果測定をしてしまうのは、機能改善のおかげだけではなく、アプリを能動的にアップデートしたというバイアスが含まれているため非常に危険です。Remote Configでのパラメータ割り付けは開発者側で自由に設定できるため(ランダム割り付けにしても良いし、ある確率値に基づいて割り付けを行っても良い)、上記のアプリ能動的アップデートバイアスを除去することができます。

「Google Analyticsのユーザセグメントごとにパラメータ設定ができる」もちろん自前のサーバでパラメータ設定を変更してRemote Configと同じような機能を実現することもできます。ただ、言語でのセグメント・OSバージョンでのセグメント・etc.などでセグメントごとにパラメータ設定を行いたい場合、幾分か開発が必要になります。Remote Configを利用すれば、Google Analyticsで標準搭載されているユーザセグメントを利用してセグメントごとのパラメータ設定を行うことができます。

Firebase A/B testingとは


機能

Remote Configの機能がわかったところで、Firebase A/B testingで何ができるのかについて見ていきましょう。

Firebase A/B testingは、以下の3つをコンソール画面で提供するサービスです。
  • Remote Configパラメータ設定のランダム割り付け
  • 結果のレポーティング
  • 結果のロールアウト

ビジネス活用

筆者が各種チュートリアルやドキュメントを調査した限り、結論として、AパターンBパターンの相対評価をする際には十分利用できるが、勝利したパターンがビジネスKPIにどれほど貢献するのかを絶対評価するのはコンソール画面だけでは難しい、と判断しました。

理由1:コンソール画面における指標の集計方法が不足している
コンソール画面で提供しているレポーティング指標は、ある指標(複数設定可)の「ユーザ1人あたりの回数」「累計回数」の2つなのですが、筆者の普段の解析では「○日後の1人あたりの回数」という指標でも効果測定を行います。これは、キャンペーンなど実施後すぐのタイミングでは高い効果があるものの効果が持続するわけではないケースや(プライマシー効果)、普段と見慣れない画面が出てくることで実施後すぐのタイミングでは拒絶反応を示してしまうというケース(リーセンシー効果)を除外した効果も測定したいためです。現状のA/B testingではこのような指標集計を行うことはできず、別途BigQueryで集計を行うことになりそうです [2][3]。

理由2:Firebase外のデータは連携できない
どれだけバックエンドをFirebaseに寄せたとしても、それ以外のDBは少なからず存在すると思います。それらのDBを利用して集計される指標をコンソール画面でモニタリングすることはできません。ビジネスKPIの全てをFirebaseで算出することはまずないと思いますので、結局BigQueryやスプレッドシートでの集計が必要になるということです。

Firebase Remote Config personalizationとは


機能

2021/5のGoogle I/Oにて発表された新機能で(現在はαリリース)、FirebaseイベントログをMLモデルに学習させ、ユーザごとにRemote Configのパラメータを動的に最適化することができるサービスです。

ビジネス活用

サービス側で最適化を動的に進めてしまうため、うまいことやらないと効果測定ができない、というビジネス施策としては致命的な欠点があります。さらに、Firebaseイベントの線形和で評価関数を定義できるケースでしか利用できません。このようにできないことが多そうなFirebase Remote Config personalizationですが、活躍しそうなシーンを考えました。

シーン1:マイナスの効果が著しく低いと想定できるとき
評価関数を定義する際に、プラス効果をどのように組み合わせるかというのも難しい問題ですが、さらにマイナスの効果も考えると非常に複雑な評価関数となってしまいます。パーソナライズされてどのパターンが採用されたとしてもマイナスの効果は著しく低い、と想定されるケースにおいては、どのパターンがプラスの効果を最大化できるか、ということだけを考えれば良いので、Remote Config personalizationに任せても良いと考えられます。

シーン2:データサイエンティストがチームにいないとき
上述のようにRemote Config personalizationでは簡単には効果測定ができないため(期間の前後比較などしかできない)、効果の絶対評価はできないけれどパーソナライズにより大きな効果があるはずだ、という強い仮説が立てられれば、ビジネス施策としてGOを出せると想定されます。

さて、このRemote Config personalizationですが、ドキュメントを見る限りうまいことやれば効果測定ができそうです。

ステップ1:ユーザセグメントのインポートを行う準備をする
上述のRemote Configのパートでは記載しませんでしたが、Google Analytics以外のユーザセグメントもBigQueryからインポートすることができます [4]。

ステップ2:BigQueryにてRemote Config personalization割り付け群と非割り付け群をユーザごとに明示的に指定する
次に、割り付け群と非割り付け群というセグメントを事前にBigQueryで作成します

ステップ3:Remote Config personalizationのターゲットユーザ条件に上記で作成・インポートした割り付け群を指定する
Remote Config personalizationではパーソナライズ機能をアクティブ化するための条件設定が行えます。ここでBigQueryからインポートした割り付け群を指定することで、明示的に割り付け群・非割り付け群を区別することができ、効果測定が可能になります

最後に

FirebaseのA/B TestingとPersonalizationについてビジネス活用方法を考察してみました。サービス単体では解析完了とはならないものの、今後使い倒して知見を溜めて行きたいと考えています。

次世代システム研究室では、ビッグデータ解析プラットホームの設計・開発を行うアーキテクトとデータサイエンティストを募集しています。興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧からご応募をお願いします。
一緒に勉強しながら楽しく働きたい方のご応募をお待ちしております。




参考資料

[1] https://www.youtube.com/watch?v=cOCpDmhyGzU&list=PL-nSubl7UrR4GYfl4mbwdX7iuY_d-BOV7

[2] https://firebase.google.com/docs/ab-testing/abtest-config#bigquery_data_export

[3] https://youtu.be/YGxrAB1MNEY?t=410

[4] https://firebase.google.com/docs/projects/import-segments

 

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事