A／BテストツールにはGoogle Optimizeを使え　方式の選定基準は“領域の広さ”と“さっくり or かっちり”

自己紹介とセッションのアジェンダ

串崎康介氏（以下、串崎）：「もう迷わない！A／Bテスト技術選定で重視すべきポイント」というタイトルで発表します。串崎康介と言います。よろしくお願いします。メドピアに入社したのは昨年の4月で、ライフログプラットフォーム事業部でサーバーサイドの開発を担当しています。

「A／Bテストとは」「今運用しているA／Bテストの事例」「他のA／Bテストの方法とその比較」について話していきます。本題に入る前に、A／Bテストとは何なのか、認識を合わせておきたいと思います。Wikipediaによると、「広義のA／Bテストはインターネットマーケティングにおける施策の良否を判断するために、2つの施策同士を比較検討する行為全般」のことです。

この発表では、もう少しスコープを絞って話をしたいので、“施策”とはWebアプリの機能やデザインの変更を想定して話します。“良否”は、数値で測れるものを前提にしています。弊社の事例でいうと、コンバージョンです。“比較”は時期によってユーザーの傾向が変わってしまうので、同時期にきたアクセスでの比較になります。

運用しているA／Bテストの事例

「今運用しているA／Bテストの事例」を紹介したいと思います。私の所属している、ライフログプラットフォーム事業部では、通称“スギサポシリーズ”と呼んでいるサービス群を開発しています。毎日の食べる、歩くなどの日常生活を中心に、健康になりたいユーザーをサポートするサービスです。今回取り上げる「スギサポdeli」は、例えば塩分、あるいは糖質が気になる方に向けて作られた、お弁当が注文できるECサイトです。

その「スギサポdeli」でお試しセットという、初回購入者向けの商品を売り出しています。そのため、オンラインの広告からきた方は、このお試しセットのページ、ランディングページに着地するようになっています。このページからコンバージョンするユーザーの数を増やすために、継続的にA／Bテストを行っています。

A／Bテストに関わるメンバーは、PMとエンジニア1名ずつです。HTMLなどの変更は、他のプロジェクトも兼務されているコーダーの方にお願いしています。A／Bテストを経て、継続的にデザイン変更を行いたいという話だったので、テストの度に僕が介入せず、最小限の2人でA／Bテスト回せる体制にできたらいいなと考えました。

そのため、このA／BテストではGoogle OptimizeのLowCodeパターンを採用しています。マーケティング用の計測や分析のツールには今のところGoogle Analyticsを使っていて、結果はそのままGoogle Analyticsで取得するのが楽だなと思い、そうしています。

具体的なパターン作成の操作の画面は、今出ているような感じです。HTMLを、指定した別のHTMLに変えたいとか、CSSやJSを追加したいとかを、画面上で追加できます。今回はコーダーがいるので特に検討はしていませんでしたが、LowCodeとはいわず、NoCodeでテストパターンを作ることもできます。例えば、右下に出ている画面で操作できます。

A／Bテストの結果はこのような表で確認できます。ちょっと今隠していますが、パターンの名前、コンバージョンやコンバージョン率、またそのパターンが最適である確率や、推定されたコンバージョン率などの指標を見れます。この方式で進めていった結果、導入時に、PMとコーダーでだいたい完結できるようにしたいと考えていましたが、おおむねできているかなといった感じです。

A／Bテストのサイクルは2週間くらいでテストの準備、1ヶ月くらいでテストの計測を行う感じにしています。2020年の12月から半年やっていて、今5回目の途中で、A／Bテストで比較ができている状態です。

LowCodeパターンを使用するときの注意点

この方式を使用する際の注意点がいくつかあります。1つは、LowCodeであってもコードなので、ソースコードと分離していることです。コードが競合したりすることもあります。実際に、ランディングページに貼っていたキャンペーンのバナーがキャンペーンの終了時に消え、Google　Optimizeのパターンの出し分けができなかったことが1回ありました。また、LowCode側で置き換えるHTMLをCSSセレクタで指定するため、動的な要素が多いページだと指定が難しい場合があります。

また、Railsで管理するasset、要は画像のことですが、フィンガープリントがつくので、他の画像と同様のフローでリリースする場合は、いったんデベロップメント環境でフィンガープリントを特定して、それをコーダーにリンクとして伝えるなどの手間が必要でした。以上が、今チームで行っている方法です。他の方法との比較を引き続き話していきます。

別パターンの紹介

まず1つ目、Google Optimize（FrontEnd）と命名しましたが、FrontEndのソースコードとGoogle Optimizeを連携させることもできます。その場合は、先ほどと同様にA／Bテストの実験、Google Optimize上では“Experience”と呼ばれているものを作ります。その後、ページの読み込み時にGoogle Optimizeに決めてもらった値、基本的には0か1が返ってくることになると思いますが、その値に応じて表示を変える操作になります。

ほぼ同様ですが、FrontEnd側ではなく、BackEndのソースコードとGoogle Optimizeを連携させることもできます。1つ違うのは、どちらのパターンでいくかは、BackEnd側で決めることになります。そのため、BackEnd側で決めたVariant_idと、もともと設定されているExperience idをGoogle Optimizeに送る感じになります。

もう1つ別のパターンとして、“Split”というRubyのgemで実装もできます。こちらは、Rackベースのアプリで使えるA／Bテストのフレームワークです。アクセスやコンバージョンのデータは基本Redisに保存できて、普通のデータとは別れる感じです。一応、専用の管理画面でRedisに保存されたデータや、基本的な分析を見れます。

Google Analyticsでサイトの分析をしていることが多いと思うので、別途連携する必要があるこの方式は、個人的にはあまり推していません。データの出し分けや、コンバージョンの記録はRubyコードのようなイメージで実装できます。

技術選定のポイントはどの領域まで広がるか

結論、A／Bテストの導入の際に、基本的なツールとしてはGoogle Optimizeの使用を前提に置いておけばいいんじゃないかなと考えています。技術選定としては、A／Bテストで変更する施策が、FrontEnd領域にとどまるか、BackEnd領域にも広がるのかが1つのポイントです。施策の変更がFrontEnd領域にとどまる場合は、次はちょっとざっくりですが、さっくり入れたいのか、かっちり入れたいのかという分類になるかと考えています。

チームが小さかったり、アプリの規模が小さかったり、A／Bテストの実行頻度がちょっと高いとか、コードを書ける人が少ない場合は、さっくり入れることを重視してLowCode方式になるのかなと考えています。A／Bテストによる変更も同様に、「そのソースコードに入れたい」という場合はFrontEnd方式が良さそうです。ソースコードの変更は通常の開発フローと同じになるので、特に違いを意識せずに開発が続けられるので、安心できるかなと考えています。

BackEndの変更を含む場合は、基本的にはGoogle OptimizeのBackEnd方式が良いのかなと考えています。gemの方式だと、やはりA／Bテストの結果を他のGoogle Analyticsのイベントと絡ませて分析したりが難しくなるかなと考えています。結論、Googleの回し者みたいな感じになってしまいましたが、以上で発表を終わりたいと思います。ご清聴ありがとうございました。

質疑応答

司会：はいどうも、ありがとうございました。さっそく、質問がきています。Google Optimize、Google Analyticsとかにもあるのかな？　「多腕バンディットアルゴリズム、使えるんでしたっけ？」という質問がきていますが、Optimizeって使えますか？

串崎：すみません、もともとの何でしたっけ？　要は50、50で出すのではなく、たぶん結果に応じて出す割合を変えてく方式のことだと思ってるんですが。Optimizeでどうなのかはちょっと把握できてないです。

司会：使ってない？

串崎：はい、使ってないです。

司会：ありがとうございます。用途によってLowCodeとFrontEnd分けてると思いますが、串崎さんの理想としては、どっちのほうがいいんですか？

串崎：今の状況でいうと、まだLowCodeのほうが手間が少ない。効果が大きいのかなと考えています。「以前競合した」という話をしたと思いますが、今後はFrontEndの方式に寄せていったほうが、そういう事故などは少ないので、今もうスイッチしてもいいのかなとちょっと考えてる次第ですね。

司会：なるほど。お手軽だけど、ちょっとした修正が事故になるっていう（笑）。

串崎：そうですね。コーダーのスキル的にも、別にかっちり方式でもできるとは思っているので。ちょっと移行とかは僕がやらないといけないのかなと考えているんですけど。

司会：わかりました。なんかA／Bテストやってよかったなっていう、一番の成果はどんな感じですか？

串崎：ちょっとまだA／Bテストをして、すごい結果が出たことがなくて。どちらのパターンも、多少は確率が変わりますが、そこまでっていう感じです。少しずつ良くはなっていますが、今のところすごい結果が出てはいません。ただ、継続的に実験できるのがいいのかなと考えています。

司会：わかりました。回数増やしていきましょう、というところで。視聴されてる方も、ぜひGoogle Optimizeを使ってもらえたらと思います。（笑）ということで、登壇ありがとうございました。

串崎：ありがとうございました。