こんにちは。delyでAndroidエンジニアをしているkenzoです。
この記事は「dely #1 Advent Calendar 2020」の17日目の記事です。
昨日はサーバサイドエンジニア高松さんの「バンディットアルゴリズムをライトに解説」という記事でした。
A/Bテストとバンディットアルゴリズムを用いた施行が進む様子を並べて見比べられるのが面白かったです。ご興味ある方はぜひこちらも御覧ください！
今回はFirebaseのRemote Configを用いて一定割合のユーザーに値を振り分ける（A/Bテストをする）ときの設定方法についてお話します。
delyではクラシルを使用してくれているユーザーにより良い料理体験を届けられるよう、日々の機能開発・改善やキャンペーン施策等に対して開発部・マーケティング部のメンバーがFirebase Remote ConfigやA/B Testingを使ってユーザーに値を振り分け、機能の出し分け等を行うことが頻繁にあります。
今回少し複雑な設定を試す必要があり、改めて設定方法について検証したので、その内容をご紹介します。
今回は主にFirebaseのコンソール画面におけるRemote ConfigのConditionsタブでの値の振り分けの設定の仕方と反映のされ方についてご紹介します。
Remote Configと組み合わせて使用するA/B Testingも便利な機能でよく利用していますが、本記事ではあまり触れません。
また、今回はアプリ側の実装についても触れません。
こちらの順で説明していきます。
今回主に用いる設定
Remote Config画面のConditionsタブ右上の「条件を追加」ボタンを押して表示されるポップアップにおいて、
「ユーザー（ランダム %）」と、
「%」の右のボタンで設定できる「キー」を利用してユーザーを分けていきます。
シンプルに振り分ける例
2分割
50:50のユーザーに振り分ける場合はこちらのように <= 50% と > 50% の条件を作成します。
キーにはどちらの条件にも同じ値をセットします（ここでは test_a ）。
（条件を1つだけにしてデフォルトを利用することもできます）
作成した条件を用いてRemote Configのパラメータを作成します。
作成したパラメータを公開して少し経つとパラメータの値が振り分けられたユーザーの割合が表示されます。
このように50:50のユーザーに値を振り分けることができました。
3分割以上
3つ以上のグループに値を振り分けたい場合はこちらのように複数の条件を作成します。
もちろんこれらの条件のキーは揃えます。
この場合は <= > のどちらかに統一するのがわかりやすくておすすめです。
こちらの設定ではデフォルトも含め4グループに値を振り分けています。
少し複雑になるので、ユーザー群に対してどのように値が振り分けられるのか説明します。
どのように振り分けられるのか
引き続き上記の3分割以上の例について見ていきます。
Conditionsにある条件は上にあるものが優先されるので（画像だと A_3 > A_2 > A_1）、下記の順に条件を満たしたユーザーに値が振り分けられていきます。*1
random_user_test_A_3で対象のユーザー100%のうち25%以下に当たる25%のユーザーに値3が振り分けられるrandom_user_test_A_2残りの75%（25~100%）のうち50%以下（25~50%）に当たる25%のユーザーに値2が振り分けられるrandom_user_test_A_1残りの50%（50~100%）のうち70%以下（50~70%）に当たる20%のユーザーに値1が振り分けられる- 残りの30%のユーザーにはデフォルトの空の文字列が振り分けられる
図にするとこんな感じです。
その結果このように値が振り分けられています。
具体的なユースケースでの設定例
今度は架空のユースケースにおける設定を試してみます。
- 新機能をリリースし、その機能を30%のユーザーに対してのみ表示させる
- 新機能が表示されているユーザーの中でもプレミアムユーザーにのみ、新機能の特別な使い方をお知らせするページへ飛べるバナーを表示させる
- プレミアムユーザーかどうかはユーザープロパティを使用して判定 *2
- この検証の環境ではプレミアムユーザーの割合は50%程度
Conditionsにてこのような条件を作成します。
作成した条件を用いてRemote Configのパラメータを設定します。
これで上記の仕様通りにパラメータが function banner に割り振られますが、今回はRemote Configの画面を見るだけでは正しく割り振られたことが確認できません。
クラシルではRemote Configで設定した値がどのように割り振られたのか知るために、ログ基盤にどんな値が割り振られたのかを送るようになっています。
今回はこのようにログ基板に送られたログを確認することで、仕様通りにパラメータが割り振られたのかを確認します。
このような感じのSQLで実際に振り分けられた結果のログを確認します。
AB_TEST_LOGテーブルにユーザー毎に割り振られた値が入っているものとします。
実際に上記の仕様と同様の設定をしてログに溜まった値を計測した結果がこちらです。*3
- 新機能はおよそ30%（0.87 + 13.29 + 15.86 = 30.02）がonで、およそ60%（33.15 + 36.83 = 69.98）がoff
- バナーは新機能がonのユーザーのみがonで、かつ、プレミアムユーザーのみがon
となっており、上記の仕様を満たしています。
（プレミアムユーザーで新機能がon、バナーがoffのユーザーが少しの割合存在していますがこれはログ送信のタイミングによって生じている誤差です。*4）
注意事項
設定の際に気を付けておくことをご紹介します。
キーが異なる条件の組み合わせだとうまくいかない
下記のように設定されたキーが別の条件を組み合わせてパラメータを作成すると、
条件ごとにユーザーのマッピングが変わってしまうため、このように意図しないユーザー群に振り分けられてしまいます。
実際に反映された値はこちらのようになっていました。
条件の順番を間違えるとうまくいかない
3分割以上の場合、上の説明のように値が割り振られていくため、条件に設定するユーザーの割合は狭い範囲の条件から順に反映されるように設定します。
Conditionsにある条件は上にあるものが優先されるので、狭い範囲の条件から順に並べておきます。
逆に、こちらのように広い範囲の条件が優先されるように設定してしまうと、
このように広い範囲の条件のみに値が割り振られてしまいます。
まとめ
Firebase Remote ConfigのConditionsを用いた少し複雑な設定をする方法をご紹介しました。
ユーザーに値を振り分けるのは今回の方法の他にも同じFirebaseのA/B Testingや他社サービスでも実現できますが、今回のように具体的なユースケースとして紹介した振り分け方も知っておくと、選択肢が1つ増えると思います。
また、今回の方法は設定が少し複雑になるため運用上のミスも発生しやすい箇所となりますので、実際に振り分けられても影響のない値で検証してから利用することをおすすめします。
今回の内容が皆様の日々の改善の一助になれば幸いです。
おわりに
明日はデザイナーredさんの「Material DesignでUIデザインをブーストしよう」です。ぜひ御覧ください！
また、dely ではエンジニアを絶賛募集中です。 ご興味ある方はこちらのリンクからお気軽にエントリーください！
delyではエンジニアを絶賛募集中です。ご興味のある方はぜひこちらのリンクを覗いてみてください。 カルチャーについて説明しているスライドや、過去のブログもこちらから見ることができます。
delyの開発部では定期的にTechTalkというイベントを開催し、クラシル開発における技術や組織に関する内容を発信しています。
クラシルで使われている技術や、エンジニアがどのような働き方をしているのか少しでも気になった方はぜひお気軽にご参加ください！
*1:参照: Remote Config のパラメータと条件
*2:参照: Remote Config とユーザー プロパティ
*3:実際はプレミアムユーザーではなく50%くらいとなる条件を設定し、そのログを計測した結果です
*4:「非プレミアムユーザーがプレミアムユーザーになったタイミング」と「それがFirebaseにユーザープロパティとして反映されて値を再取得するまで」の間にログ送信のタイミングがきてしまったことによるものです
