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

EVENT

2021年05月28日に開催

多数のヘルステックサービスを企画・開発しているメドピアが、リモートワーク継続中でも事業成長を加速させたプロダクト開発の事例や技術的な知見を紹介する「事業成長を加速させたエンジニアリングのウラ側」。ここでライフログプラットフォーム事業部で、サーバーサイドの開発を担当している串崎氏が登壇。チームで運用しているA／Bテストについて紹介します。

スピーカー

串崎康介

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

串崎康介氏（以下、串崎）：「もう迷わない！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の回し者みたいな感じになってしまいましたが、以上で発表を終わりたいと思います。ご清聴ありがとうございました。