Google Optimizeでテストをしてる話

ごきげんよう！

TRILL開発部のWebを担当しています、maseoです。

この記事は「dely #2 Advent Calendar 2020」19日目の記事です。

dely #1 Advent Calendar 2020 - Adventar adventar.org

dely #2 Advent Calendar 2020 - Adventar adventar.org

昨日は HPdM（ハイパープロダクトマネージャー）のRiceさんの記事「初心者PdMに贈る「"伝書鳩"が意思を持つために意識すべきこと」でした。
エンジニアはHPdMさんに本当に助けてもらってます。
こんなに色々考えてくださっているのは本当にありがたいです。いつもありがとうHPdMさん達！

さて

今回はTRILLのWebで行っているGoogle Optimize*1を使ったA/Bテストはこんな感じ！というお話を書きたいと思います。

TRILLでは、以下のドキュメントを参考に、Google Optimize JavaScript API を利用しています。

developers.google.com

TRILL Webでこの方法を採用している理由は色々ありますが、A/Bテストを行う上でサーバーサイド側の操作がGoogle Optimize上では厳しいとか、テスト内容によってはDBから取得する値を変えたいとか、テスト用の広告を入れたいとかです。

もう少し具体的に言うと、
記事詳細でA/Bテストがしたい！となった時に、URLが記事のID毎に異なっているため、「このタイプの記事はテスト対象……、このタイプの記事は非対称……」なんてことがGoogle Optimizeのビジュアルエディタでは大変そうだな……ってなったからです。

実装

今回は過去に実際に実施したテストを書いてみます。
※仮説の設定とか、テストパターンの作成とかは割愛します。

■テスト内容
新しいモジュールを追加するにあたって、
「どのタイプの表示がいいかな〜？そもそも追加しても他のモジュールに影響はないかな〜？」
を確認したい

■テストパターン

オリジナル（現行パターン）
サムネイル小
サムネイル大

の３パターン

ざっくりこんな感じです。

それでは、早速ですが、実装コードはこちら（ドンっ）

export default class OptimizeUtil {
　constructor() {
    　this.getElement();
 　}

　init() {
　　gtag('event', 'optimize.callback', {
　　　callback: (value) => {
　　　　this.callback(value);
　　　}
　　});
　}

　getElement() {
　　this.nextArticleList = document.querySelector('.js-next-article-list');
　　this.nextArticleItems = document.querySelectorAll('.js-next-article-item'); 
　　…
　}

　changeClassToSmall3() {  // テストパターンの表示を実現する操作
　　if (this.nextArticleList) {
　　　this.nextArticleList.classList.remove(`Articles_List`);
　　}

　　if (this.nextArticleItems) {
　　　this.nextArticleItems.forEach((el) => {
　　　　el.classList.remove(`Articles_Item`);
　　　　el.classList.add(`Articles_Item-small3`);
　　　});
　　}
       …
　}

　changeClassToBig3() {  // テストパターンの表示を実現する操作
　　…
　}

　callback(value) {
　　switch (value) {
　　　case '0':
　　　　break;

　　　case '1':
　　　　this.changeClassToSmall3();
　　　　break;

　　　case '2':
　　　　this.changeClassToBig3();
　　　　break;

　　　default:
　　　　break;
　　}
　}
}

一部割愛してますが作りはシンプルです。
テストパターン毎に適切な関数を呼び出して、あとはCSSとかで見た目を整えてあげます。

このテスト方法では、Google Optimizeでそれぞれのパターンの効果が見られるのはもちろん、新しいクリックイベントの計測もできますし、今回は実装されていませんがパターン毎にリンクにクエリパラメータを簡単に付けれたりします。

例えば、Adjustを使ったアプリストアへの送客なんかもパターン毎の計測が簡単です。

また、同じ "記事" だけど、Aカテゴリーの記事ではテストして、Bカテゴリーの記事でテストしない！みたいなこともHTMLの出しわけとかで簡単に制御できます。（トラフィックには影響ない範囲で）

全部まとめて実装できるのも良いですね。レビューなども普段のフローでできるので、安心です。

表示確認

そして見た目はこんな感じになります。（ドドンっ）

①

f:id:trill_tech:20201215193353p:plain — 表示結果１

②

f:id:trill_tech:20201215193428p:plain — 表示結果２

ちゃんと表示が変わっていますね！

あとはテストを見守るのみです。
他のモジュールに悪い影響がないかに注意して日々を過ごします。

テスト終了

時は流れ、
オプティマイズの結果はこんな感じになりました。

f:id:trill_tech:20201217171503p:plain — オプティマイズの結果

差が出てますね。（よかった）
計測データで他のモジュールにもマイナスな影響は確認されなかったので、テストしたパターンは無事採用されました！（よかった）

ただ、このテストはGoogle Optimize上では全ユーザーに出てることになっておりまして、
Optimizeのトラフィックの割り当てを使ってないです。（別途ゴニョゴニョして数％のユーザーをテスト対象としています）
なので、トラフィック割り当てを使う場合は、テストパターンの対象になっていないユーザーのこともしっかり考える必要があります。