コンテンツ・メディア第1事業部の荒木です。ピクトリンクというアプリのAndroid版を開発しています。今回は、Google I/O 2016 で新しく生まれ変わったFirebaseを使ったABテストと、従来の方法であるGoogle Tag Manager (GTM)とGoogle Analytics (GA)を連携させて行うABテストの違いを見ることで、新しいFirebaseの強みと弱みを考えてみたいと思います。
ちなみに、この記事はumeda.apk #1でLT発表した内容をもとに書かれております。発表スライドは以下です。また、記事の最後にumeda.apkの様子についても書かせていただきます。
https://speakerdeck.com/takuaraki/b-testing-gtm-and-ga-vs-firebase
ABテストの流れ
GTM&GAでもFirebaseでもABテストの流れは、以下の三つのステップに分けられます。
- ABを出し分けるためのWebコンソールでの設定
- ABを受け取るためのアプリの実装
- テスト結果の解析
今回は、上記の三つのステップについてGTM&GAとFirebase Remote Configを比較したいと思います。
1. Webコンソールでの設定
GTM&GA
GTMのWebコンソールで「Google アナリティクスのウェブテスト」という変数を設定することで、ABの出し分けをすることができます。変数の設定画面は以下のようになっています。
まだまだあります。
結構長いですね。具体的には、GAとの連携部分やテストの詳細設定が項目数を増やしています。
Firebase Remote Config
FirebaseでABの出し分けをする際は、Remote Configを利用します。Remote Configとは、特定のキーに対する値をWeb上で自由に設定して、アプリに渡すことができるサービスです。アプリのアップデートをせずにWeb上で値を変えるだけで、ユーザーに見せる文言を変更したり、ゲームの難易度を調整したりできます。また、Remote Configには、ユーザーごとに違う値を渡す機能があります。ABテストではこの機能を利用してABの出し分けを行います。Remote Configの設定画面は以下のようになっています。
先ほどと比べると、非常にシンプルな印象を受けるのではないでしょうか。Webコンソールで設定する項目を説明します。
パラメータ
パラメータとは、キーと値のペアのことです。たとえば、キーに”hoge”を指定したら値として”fuga”がもらえるという設定ができます。今回は、キー値”pattern”でデフォルト値”A”がもらえる設定を行います。
条件
条件とはパラメータにつけることができるもので、特定の条件を満たしたときだけ”hoge”キーで値として”piyo”がもらえるという設定ができます。たとえば、キー値”pattern”でデフォルトでは値として”A”を渡すが、半分のユーザーには”B”を渡したい場合、以下のように条件を追加してパラメータに追加し、条件達成時の値を”B”としてやれば、ABの出し分けができます。
2. AB受け取りの実装
各手法の初期化とABの値の受け取りをJavaで実装します。
GTM&GA
初期化の流れは、
TagManager
インスタンスの生成- コンテナID(GTMのWebコンソールで取得)とデフォルト値(リモートからの値取得失敗時の値)の設定
- リモートからの値取得完了時のコールバック設定
となっています。また、ABの値の取得にはContainer#getString(String key)
が利用されています。
// 初期化 // GTMインスタンスの生成 TagManager tagManager = TagManager.getInstance(context); // コンテナIDとデフォルト値の設定 PendingResult<ContainerHolder> pending = tagManager.loadContainerPreferNonDefault(CONTAINER_ID, R.raw.gtm_default_container); // リモートからの値取得完了時のコールバック設定 pending.setResultCallback(new ResultCallback<ContainerHolder>() { @Override public void onResult(ContainerHolder containerHolder) { ContainerHolderSingleton.setContainerHolder(containerHolder); if (!containerHolder.getStatus().isSuccess()) { Log.e(TAG, "failure loading container"); return; } startMainActivity(); } }, 2, TimeUnit.SECONDS); // ABの値の取得 Container c = ContainerHolderSingleton.getContainerHolder().getContainer(); String pattern = c.getString("pattern");
Firebase Remote Config
初期化の流れはGTM&GAとかなり似ています。
FirebaseRemoteConfig
インスタンスの生成- デフォルト値(リモートからの値取得失敗時の値)の設定
- リモートからの値取得完了時のコールバック設定
違う点は、GTMにおけるコンテナIDの設定に相当する部分がないことです。
また、ABの値の取得はFirebaseRemoteConfig#getString(String key)
で行っています。この点もGTM&GAに似ていますが、GTMではリモートからの値取得完了時にContainerHolder
のインスタンスを自作のシングルトンクラス(ContainerHolderSingleton
)に保存しておく手間があるので、若干Firebaseの方がシンプルになっています。
// 初期化 // FirebaseRemoteConfigインスタンスの生成 final FirebaseRemoteConfig remoteConfig = FirebaseRemoteConfig.getInstance(); // デフォルト値の設定 remoteConfig.setDefaults(R.xml.remote_config_defaults); // リモートからの値取得完了時のコールバック設定 remoteConfig.fetch().addOnCompleteListener(new OnCompleteListener<Void>() { @Override public void onComplete(@NonNull Task<Void> task) { if (task.isSuccessful()) { Log.d(TAG, "Success"); remoteConfig.activateFetched(); } else { Log.e(TAG, "Failure", task.getException()); } startMainActivity(); } }); // ABの値を取得 String pattern = FirebaseRemoteConfig.getInstance().getString("pattern");
3. テスト結果の解析
GTM&GA
GTMとGAを連携させた場合は、イベント送信時に自動的にそのイベントのセッションがどのパターンであるか(AであるかBであるか)の情報を付与してくれます。また、コンバージョン率やBのコンバージョンがAを上回る確率も計算して、GAのコンソールに表示してくれます。以下は、GAの「ウェブテスト」から見られる画面の例です。
Firebase Remote Config
Firebase Remote ConfigはAかBかの値をアプリに渡すだけなので、あるユーザーがAを受け取ったのかBを受け取ったのかの情報はイベント送信時に送る必要があります。Firebase Analyticsで送信する場合は、以下のようにカスタムパラメータを付与してイベント送信する必要があると思われます。
Bundle params = new Bundle(); params.putString("test_pattern", pattern); // add A or B FirebaseAnalytics.getInstance(context).logEvent("button_tapped", params);
また、コンバージョン率の計算や統計的な解析なども自力で行う必要があります。私なら、Firebase AnalyticsとBigQueryを連携させて解析する方法をとると思います。
比較のまとめ
ここまで、ABテストの流れに沿ってGTM&GAとFirebase Remote Configを比較してきました。比較の結果をまとめると、
- Webコンソールの設定:Firebaseの方がシンプルである
- AB受け取りの実装:FirebaseはGTM&GAと似ている(Firebaseの方が若干シンプルである)
- テスト結果の解析:Firebaseは自前でやる必要がある
となりました。Firebaseの強みは、とにかくシンプルであることだと感じました。逆に、シンプルであるがゆえ、高度なことをするときは自分たちで考える必要がある点は抑えておきたいと考えました。
おまけ umeda.apk #1 について
突然ですが、京都はとても住みやすいところです。自転車でどこにでもいけるし、よいお店がたくさんあるし、観光地なので見るところもたくさんあります。そんな京都で私は働いているのですが、一つ困っていることがあります。それは、Android開発者の集まる勉強会が少ないことです。これは京都に限らず関西全体の話です。関西モバイルアプリ研究会という素晴らしい勉強会が京都を中心に開かれていていますが、こちらはiOSとAndroidの両方を対象にしているので、純粋にAndroidアプリ開発者の集まりとなるとなかなか見つかりません。そんな状況の中、umeda.apkという勉強会が6月17日にサイバーエージェントさんの大阪支社で開催されました。
この勉強会は、shibuya.apkという渋谷で開催されているAndroidアプリ開発者の勉強会を関西でもやろうということで開催されたそうです。第一回なので、どのような勉強会になるか分かりませんでしたが、日本有数のAndroidアプリ開発者の方が登壇されると知り、すぐに参加を決めました。#1のメインテーマは Google I/O 2016 の報告で、Building for Billions、Firebase、Android in Car、Awareness API、Project Tango、Google I/O セッションまとめ、設計の話(Bento vs Burrito)などの発表がありました。
発表を聞いた印象として、どの発表も非常に分かりやすかったです。参加前には、自分が理解できない高度な発表かもしれないと不安を抱いていましたが、Android開発をやっていて最新情報にも多少興味をもっている人なら十分ついていける内容でした。次回は8月に開催予定らしいので、また参加したいと思います。関西でAndroidアプリ開発をされている方は、是非参加してみてください。