#optimize360 | Explore Tumblr posts and blogs

mediba-ce · 6 years ago

Text

Google Optimize360でレコメンドエンジンの評価をしてみる

こんにちは。フロントエンジニアの苅部です。

今回はECサイトでのレコメンドエンジン評価にあたって、Google Optimize360のフロント組み込みやGoogle Analyticsのユーザーリスト利用を実施しましたので一連の流れを共有したいと思います。テスト実装であったりレコメンド評価の理解の一助となれば幸いです。

※Google Optimizeの導入方法については過去の記事をご確認ください。・Google Optimize導入とA/Bテスト実施のポイント | mediba Creator × Engineer Blog

レコメンドエンジン評価の目的

「どのくらいの効果が見込まれるか」「A or B or n どのモデルが優れているか」といった疑問を明らかにするためにレコメンドエンジンのパフォーマンス評価を実施しました。

「効果」とは費用対効果であったり事業指標への貢献度合いとなります。インフラや保守など何かしらの形でアプリケーションを維持するためのコストは発生するため、効果とコストのバランスが取れているか評価することが大切です。

またレコメンドエンジンは開発して終わりではなく、パフォーマンスを計測して評価・改善を続けることが望ましいです。ただ前後比較の評価では他の要因を除去できず因果関係の判断が難しいため、より正確なモデル評価のためにA/Bテスト(統計的な因果推論)の必要があると考えています。

今回のレコメンド実装方法

レコメンドの有無でのA/Bテストを��提に、以下のような形で実装を進めました。

・API

分析会社様に構築いただいたレコメンドのAPIを使い、AJAXにてレコメンド結果をJSONで受け取っています。アクセスログ・コンバージョンログを元にバッチ処理でアソシエーション分析を行い、ユーザー・商品ごとに最適な(購買される可能性の高い)商品を提案しています。

・DOM

Google Optimizeのエディタで空タグの挿入とJavaScriptの実行を指定しています。そして別JavaScriptファイルにて[AJAX実行,HTML文字列構築,引数のHTMLElementへinnerHTML代入する関数]をグローバル空間に用意して、それをGoogle Optimizeから呼び出せるようにしています。

・任意の箇所へ空タグを挿入

・空タグの中でJS(AJAX/innerHTML)を実行

Google Optimize側のエディタを使ってDOM書き換えやJavaScript(AJAX)の実行��可能ですが、今回はターゲティングルール設定・関数実行・テストの評価をGoogle Optimizeに委ねて、ロジック・ビューは別JavaScriptファイルに持たせています。メンテナンス性やコードレビューの観点で、可能な限りコードとしてGitでバージョン管理する方が好ましいと考えています。

※この方法を取るとテスト期間中にもDOM変更が可能になるため、何かと便利です。 ※クリックイベントも併せて取っておくと後の分析で役に立ちます。

A/Bテストの実施概要

今回は複数画面でのレコメンド実装を想定しています。ただGoogle Optimizeは基本的に1画面1テストとなるためこのままではページごとにA/Bテストの抽選が実施され、それぞれでテストパターンが変化してしまいます。レコメンド有無やモデルの比較のために「レコメンドのある世界・レコメンドのない世界」「モデルAの世界・モデルBの世界」を作りたいわけですが、このままではそれぞれの世界が混在して本来意図していたテストが実施できません。

そこで今回は、Google Optimize360(有償)の機能を利用してGoogle Analytics側のユーザーリストをインポートしてターゲティング設定することにしました。ちょっと複雑ですが、テスト動作の全体の流れは以下の通りです。

起点ページにてユーザーごとにテストパターンが決定

Google Analytics側にシステムディメンションがセット(ID/パターン)

ユーザーリストが動的に生成(時差有り)

他ページでもユーザーリストのターゲットに対してテストが着火

ユーザーリストはリターゲティング向けの機能となりますが、Google Optimize360ではA/Bテストのターゲティング配信の条件としてGoogle Analyticsのユーザーリストをインポートすることができます。

Google Optimize,Google Analyticsの設定

1. テストの起点となるページのテストIDを取得

まずはテストパターンの抽選が実施される起点ページを決め、Google Optimizeでテストを作成します。下書きの状態でテストIDが割り振られるため、このテストIDを他のページでのターゲティング配信に利用します。

2. テストIDを元にセグメントを作成・ユーザーリストを公開

起点ページで実施するテストのテストIDとテストバリエーションを元に、Google Analytics側でユーザーリストを作成して公開します。まずはセグメントビルダーにてGoogle Optimize側で発行されたテストIDを利用して任意のテストパターンを指定します。

・[テストID]ディメンションと[パターン]ディメンションを使う場合

・[パターンを含むテストID]ディメンションを使う場合

パターンディメンションは、オリジナルであれば[0]、バリエーションの1つめであれば[1]、2つめであれば[2]といった形で連番で指定す��事ができます。今回はA/Bテストのバリエーションの1つめを判定したいため[1]としています。これで[A/BテストのBパターンが表示された人(レコメンドが表示された人)]というセグメントが作成できました。

次に、セグメントを元にユーザーリストを作成します。

・一覧画面にて任意のセグメントで[ユーザーリストを作成]を選択

・ユーザーリスト名を入力

・ユーザーリストの宛先にGoogleオプティマイズ360を選択

・公開先にGoogleオプティマイズ360が含まれていることを確認して公開

以上でユーザーリストの設定は完了です。

今回の仕組みでは全ページのテストを稼働させるためにユーザーリストが更新される必要がありますので、数時間の開始時差を許容する必要があります。なお今回は最短で4時間程度でユーザーリストが反映されました。

3. 画面ごとにテストを作成

レコメンドを掲出する画面ごとにテストを作成します。

・ターゲティング条件に任意のユーザーリストを指定

・テスト目標は収益とトランザクション数を指定

一連の設定が完了したので、すべての画面でテストを開始できる状態となりました。

A/Bテストを始める前に

A/Bテストは万能ではなく、実施においてはサンプルの[偏り]を常に意識することが大事です。単純無作為(ランダム)に割り振っても必ず偏りが発生しますし、サンプルが少ないほど偏りやすくなります。特にリピーターの比率が高いサイトでは、偏った場合にはそのテストの中では偏り続けることになります。そのためA/Bテストの実施にあたっては[事前にA/Aテストを実施して偏りの起こりやすさを把握]したり[A/Bテスト期間だけでなく、実施前期間まで含めた前後比較で各バリエーションの評価すること]が大事です。

・直帰率でのA/Aテストの例。徐々に偏りが減少していきます。

レコメンドエンジンの評価結果

さて、1ヶ月ほどレコメンドの有無でA/Bテストした結果は以下のようになりました。

��Google Optimize

レコメンド有りのパターンの売り上げが[95%の確率で4%〜16%、中央値で10%の向上]という、なかなか良い結果となりました。

95%信頼区間にマイナスの値を含んでいないため、今回は[レコメンドによって収益の向上が期待できる]という判断をしました。

・Google Analytics

レコメンド有り・無しのセグメントを作成し、eコマースレポートにて重ねて比較してみました。ブルーの線がレコメンドなしのセグメントで、オレンジの線がレコメンドありのセグメントです。 ※ユーザーセグメントであれば、過去90日まで遡ることができます。

・A/Bテスト開始前。大きな収益の差が無さそう。

・A/Bテスト開始後。何度かリフトしている様子が確認できます。

今回のA/Bテストを用いたレポート・評価によって、全ユーザーに開放した場合の収益のインパクトが推測することができ、レコメンドの費用対効果の試算が可能になりました。

おわりに

統計・機械学習を用いたプロダクトはリリースするまで効果が分かりませんし、リリースしたものが事業指標に繋がる保証はありません。そしてリリースしても効果の因果関係は見えづらいです。そのため、適切な指標を元にリリース後に継続したモデル評価が必要になりますが、そのフェーズで因果推論としてのA/Bテストが有効活用できると実感できました。

また費用対効果の推定だけでなく「投資対効果」という幅を持たせた考え方も大事だと思います。ひとつの機能レベルでシビアに費用対効果を考えてしまうと、なかなか成果を出すのが難しいと感じています。特にECサイトではトランザクション・売り上げを向上させるのは相当に難しいです。そのため例えばUXという文脈で[エンゲージメント指標の向上]も判断基準に含めたり、単体のプロダクトではなく[分析・データ活用のプロジェクト]という視点で、広く捉える必要があるとも感じました。

備考

A/Bテストの結果は将来の指標を保証するものではありません。

複数画面で同一パターンを反映させるためにユーザーリストを利用していますが、今回の構成はちょっと冗長でした。各画面にHTML差し込み用の共通のDOMを用意したり、Cookieにテストパターンを保持するなどして、ユーザーリストを使わずとも複数画面でパターンを固定する事は可能です。

Google Analytics360はGoogle Optimize360のみ接続が可能です。つ��り有償版Analyticsと無償版Optimizeを接続することはできません。

参考文献

データ分析の力因果関係に迫る思考法 (光文社新書)

セグメントについて - アナリティクスヘルプ

セグメントからユーザーリストを作成する - アナリティクスヘルプ

ユーザーリストを作成、編集する - アナリティクスヘルプ

#googleoptimize #abtesting

1 note · View note