Googleオプティマイズはご存知、ABテストを手軽に実施できるGoogle製の無料ツールです。
僕は2年くらい前からクライアントワークで本格的に使い始めましたが、いろいろ試行錯誤した中で「こうしたほうが良い」というやり方がけっこう貯まったので、ざざっとまとめてみたいと思います。なおテストパターン作成をコーディングが得意なパートナーさんに依頼することもあり、本記事はそのときにシェアするマニュアルも兼ねています。
タグ設置など、前準備のとき
オプティマイズタグ設置は、GTM経由ではなく「直書き」のほうが良い
Googleオプティマイズを開始するには、まずテスト対象ページ（基本的には全ページ）にオプティマイズタグを設置する必要があります。設置方法はGA等と同じで2つあり、1つはGTMなどのタグマネジメントツール経由、もう1つは直書きです。GTMを使う場合は専用のタグテンプレートが用意されているので、それを使うことになります。
オプティマイズのインストールに関する詳細はこちらのページで確認できます。
タグマネジメントの観点からするとGTM経由のほうが良さそうですが、オプティマイズタグ設置は面倒でも「直書き」のほうがベターです。理由は、GTM経由だと「ページフリッカー」が発生するのを避けられないからです。
ページフリッカーというのは、対象ページが読み込まれてから、オプティマイズ経由でテストパターンが読み込まれるまでの間にオリジナルパターンがチラ見えしちゃう現象のことです。だいたい0.2〜0.4秒くらいこの状態になります。ファーストビューでがっつり変更を行っている場合は特に影響が大きくなります。実際に見てみると分かりますが、けっこうチラチラして不快です。CVRにも悪影響を及ぼすと思われます。
この0.2〜0.4秒というのは、GTM内で設定を変えてどんなに早くオプティマイズタグを発火させても無くすことはできません。一方、<head> 開始タグ直下などに直書きしてかなり早い段階で読み込ませるようにすれば、ページフリッカーは発生しなくなります。
感覚的にはこれでもページフリッカーは発生しそうな気がしますが、実際には無くなります。
なお「アンチフリッカースニペット」という、ページフリッカーを防止するための専用コードを別途置く方法が案内されていて、これを使うことによってもページフリッカーは無くなります。ただし、アンチフリッカースニペットの設置はGTM経由ではなく「直書き」必須。そもそもアンチフリッカースニペットを直書きできるならオプティマイズタグも直書きできるはずなので結論、不要です。
また、アンチフリッカースニペットがやっていることというのは「ちらつく0.2〜0.4秒の間、ページを真っ白にしておく」というもので、えげつないレベルでイケてなく、読み込み速度にもダイレクトに悪影響を及ぼすのでこの点においても基本、推奨できません。
どうしてもGTM経由で配信しないといけない場合は、実際にはページフリッカーが発生している状態でもABテストを通じてCVR改善はできちゃいますので、お客さんと相談して「ページフリッカーは気にしない」「ファーストビューのがっつり変更は避ける」など対応を検討されると良いでしょう。
※オプティマイズタグには「同期タグ」と「非同期タグ」というものがあり、管理画面で案内されているのは「同期タグ」のほうです。違いはこちらのヘルプで案内されています。そして、同期タグでGAオーディエンスターゲティングやGoogle広告連携を行う場合、アンチフリッカースニペットが必要と書いてあるんですが、ちゃんと検証したことがないので暇なときに諸々確かめてみようと思っています。おそらくはGAオーディエンスやGoogle広告の読み込みに少しだけ時間がかかるということだと思います。特にGAオーディエンスターゲティングはもともと360限定の機能でしたが、GA4の登場に際し無料版でも使えるようになったので、今後は利用機会が増えるかも知れません。
画像はあらかじめFTPなどでアップできるよう手配したほうが良い
Googleオプティマイズには、画像をアップロードする機能がありません。
画像が必要な場合は別途、サーバーにあらかじめアップロードしておくなどの対応が面倒ですが必要になります。お客様に、テスト用に自由に使えるサーバーの場所と、接続用のFTPを用意してもらえるのがベストです。あるいは、社内で使っているワードプレスなどのCMSのメディア管理機能を使うのも良いでしょう。後者のほうがパートナーにテストパターン作成を依頼するときにセキュリティ的なやらかしリスクが少ないかも知れません。
ちょっとしたアイコン画像であればSVGで直接CSSに書いちゃったほうが早いケースもあるので、それで事足りる場合はそれで対応します。ただ、SVGのコードってちょっとしたアイコン画像でもけっこう長いので、CSSと混ぜちゃうとコードが見づらくなるのが悩ましいところです。
テストパターンを作成するとき
大きい変更を伴うテストは、エクスペリエンスをデバイスで分けたほうが良い
エクスペリエンスというのは、オプティマイズ内で実施されるABテストの1単位のことです。これを、僕はだいたいデバイス別でエクスペリエンスを2つに分けて作成します。特に、大きい変更を伴うものはこうします。ちょろっとしたテストなら面倒なのでやりません。
理由は2つありますが、1つはこうするとレポートが楽だからです。
PCとスマホは、同じような内容のテストをやっても結果がけっこう違うことがよくあります。例えば、デバイス一緒くただとテスト結果は「変化なし」だったけれど、デバイス別に見たらPCはCVR下がってて、SPはCVR上がってた、とかはあるあるです。このとき、じゃあSPだけデプロイ（サイトに適用）しよう！となりますし、ABテストとしても「うまく行ったね」という評価になります。
こういう事があるので、デバイス別にABテストのパフォーマンスを見るというのは基本的に必ずやることになります。ここでエクスペリエンスがデバイス一緒くたになっていると、GAでセグメントを作成してレポートしたりしないといけないので、面倒です。最初からデバイスを分けておけば、管理画面をキャプチャするだけでレポートが一瞬で終わります。
もちろんテスト後に分析をちゃんとした上で再度レポートするわけなんですが、途中経過のレポートや、初期レポートはこれで済ませてしまっても問題ありません。
もう1つの理由は、テストパターンの作成もデバイス別に分けていたほうが楽だからです。
デバイスごとにエクスペリエンスを分けていない場合は、通常のCSS修正と同じで、メディアクエリを書いて変更内容をデバイスごとに分ける必要が生じます。また、要素の移動を行いたい場合も「PC表示のときだけ動かしてSP表示時は動かさない」という設定はできません。等しく全デバイスで動いてしまいます。
一方、オーディエンスターゲティングでPC/SPを選んでエクスペリエンスを分けておけば、上記の懸念はなくなります。CSSもメディアクエリで分岐させずに雑に書いてもそんなに問題になりませんし、要素の移動もPC/SPで別々の内容にできるので、作業が圧倒的に楽です。
このとき少しだけ注意したいのが、上記オプティマイズのデバイス判定がユーザーエージェントで行われるのに対して、現在多くのサイトでデバイス出し分けに使われているのは「画面の幅」なので、PCとタブレットの境目など、中途半端な画面幅のところはオプティマイズの設定とサイトの出し分けが正確に一致しません。これで大きな問題が起こるかどうかはサイトによるので、テスト開始前にプレビューで必ず確かめておきましょう。
また、オプティマイズ無料版では同時に実施可能なテスト数が5件までに制限されています。上の内容だとテスト企画1つで5枠のうち2枠を消費してしまうので、それで問題ないかどうかも考える必要があります。今後のテストスケジュールも考慮して、やっぱりPC/SPは分けずに同じエクスペリエンスでレスポンシブ対応を頑張るか？あるいはオプティマイズのアカウントを2個以上設置しちゃうなどの力技で対応するか？そんなことを検討することになります。
テストパターンの変更数は少ないほうが良い
Googleオプティマイズは、テストパターンのエディターを使うとすごく手軽に変更を追加できるんですが、この「変更数」は少ないほうが良いです。多くても10は超えたくないですね。できれば5,6個で収めたいところです。
理由は、あとで修正したり、同じ箇所を再テストしたり、勝ちパターンをデプロイ（サイトに適用）したりするときに変更数が少ないほうが楽だからです。
下記はオプティマイズの変更リストのキャプチャですが、ご覧のとおり編集した内容を一覧で見返しやすいUIになっていません。1, 2, 3 に、どういう目的でどこを変更したコードが入っているか、全く分からないですよね？5, 6個であればポチポチクリックして確かめることもそんなに苦ではありませんが、この点を意識せずに編集していると変更数がすぐに20, 30と増えて、手がつけられなくなります。
変更数を少なくするために必要なのは、まずCSSの変更はスタイルごとに作成するのではなく、<style> タグの挿入という形で1箇所にまとめることです。CSS変更はテストパターン作成時に必ずやることになるので、僕は下記のようにテンプレ的に毎回、空タグを <head> に挿入するルールにしています。これでだいぶ変更数が減らせます。
加えて、要素の移動は計画的に、最小限に抑えます。編集中にあれこれ試していると、不要な移動（行ってまた戻るとか）を繰り返しやすくなります。そうならないよう、編集前にパターンの最終形を想定して、それに必要な最小限の要素移動はどこか？をHTMLをよく見て見極める必要があります。
上記のような事情から、エディターの右下に要素をいろいろと編集できる下記のようなUIが出てくるのですが、これは基本使いません。というか、使ってはいけません。
代わりに、ページ左上にちっちゃい四角があってクリックすると「要素の選択」という機能が出現するので、こちらを使用します。
テストパターンには Clarity のカスタムタグを入れたほうが良い
Clarity はマイクロソフトが出している無料で使えるヒートマップ解析ツールです。
2020年10月に正式リリースされたばかりの新しいツールで、無料なのに画面の録画もできるなど、すごい高機能な代物。画面録画って、以前は ClickTale っていう超高いツールくらいしか対応してなかったんですが、本当に良い時代になりましたね。サーバーの容量めちゃくちゃ食うはずなので、いつまで無料で使わせてもらえるか怪しいもんです。
Clarity の基本的な使い方は、キーワードマーケティングの川手さんのブログで詳しく紹介されています。
オプティマイズにおける鉄板の使い方としては、ABテストしながら Clarity でパターンごとのヒートマップを撮って比較するというもので、これをやるとテスト結果に対する解像度がめちゃくちゃ上がります。例えば、テストパターンごとのリンクのクリック状況を比較するとして、GAだけだとこんなちょっとしたのでも結構めんどくさいんですよね。それが Clarity ならサクっとレポートできます。
ただ、そのままClarityを入れただけでは、テストパターンごとにヒートマップをフィルタすることが出来ません。そこで、Clarityの「カスタムタグ」というものを入れます。入れ方は簡単で、下記のようなJavaScriptを1行、オプティマイズの変更リストとして追加するだけです。
clarity("set", "Google Optimize", "なんちゃらテスト_パターン1");
set 以外の引数は自分で判別できれば何でもオッケーですが、一定のルールを設けたほうが良いでしょう。パターンごとに最後の引数（Value）を異なる内容にするのだけ忘れないようにしてください。ここ同じだと入れる意味ないので。
入れると Clarity の Filter の一番下「Custom tags」でこんな感じで出てきて、テストパターンごとにフィルタできるようになります。
ただ、これだけだと実は1個足りなくて、オリジナルパターンにはカスタムタグを入れられないので、これだとオリジナルとテストパターンとの厳密な比較ができません。じゃあどうするかというと、「カスタムタグを入れただけのパターン」というのを作成し、下記のように配信割合を調整したうえで、新しい方を「オリジナル」と称して配信します。
ただ、これをやると元のオリジナルのほうに「配信数が足りません」みたいな表示が出て、オプティマイズのレポート画面がちょっとおかしい感じになるので、そこまでの厳密さを求められない場合は、やらなかったりします。
仕上げ、公開準備のとき
スマホ・タブレットの実機プレビューはステージング環境等で公開後に行うのが良い
スマホやタブレットは作り中はデベロッパーツールを使ってプレビューするのが一般的ですが、大きい変更をするときや、注文フォームなどセンシティブな箇所をいじるときはやはり実機でも確かめたいですよね。
ですが実は、オプティマイズはモバイル実機でプレビューするのが難しいんです。一応、下記のようにプレビューURLを共有する機能があるんですが、このURLをスマホ実機に送って開いてうまくいった試しがないので、たぶんできるようになってないと思います。どうしてかはよく分からんです。
なので、実機でプレビューをどうしてもしたい場合は、
- ページターゲティングURLにデバッグ用パラメータを付けて一旦公開、実機確認で問題なければパラメータ除去
- ページターゲティングURLをステージング環境のURLで一旦公開、実機確認で問題なければ本番URLに変更
このような運用をする必要があります。ただ、これも実際にやるとちょっと面倒なので、だいたい大丈夫だろという変更内容の場合は、公開後に実機でちらっと確認する程度で済ませることも多いです。
ページターゲティングURLは正規表現でなるべく多く配信したほうがよい
ABテストは、十分な信頼度の結果を得るために配信母数を多くするのが重要です。どれくらい必要かというと一般的には1パターンあたり100CVはあったほうが良いと言われています。実際、これくらいは無いとテストパターンとの差を見出すのが難しいです。
100CVということはCVR1%と仮定して1万UU、これが1テストパターンで必要なので1テスト最低2万UUは同じページでユーザー数が要ることになります。デバイス別で考えるならもっと必要ですし、テストパターンを2つ3つと作るならもっともっと必要になります。テストはできれば長くても1ヶ月くらいで終わらせたいので、いま想定しているテスト対象ページでそもそも月2万UUが稼げているのかは最初に想定しといたほうがよいです。
真摯さんが公開している「A/Bテスト信頼度判定ツール」というのがあります。これを使うと、テストパターンがうまくいったと言える場合の配信母数がどれくらい必要なのかをあらかじめ見積もることが出来ます。
たとえば、上記の例を下記のように打ち込んでシミュレーションしてみます。テストパターンの改善度は20%いったら既にけっこう良い方なので、CVRは1.2%に設定します。すると信頼度80%で「明確な差とは言えません」と出てしまいます。実際にはこれだけ配信してもまだ足りないということです。具体的には、信頼度95%を超えないと明確な差と言えません。
ではどれだけ配信したら95%を超えるのか？各パターンの母数を1万ずつ増やして確かめてみます。すると3万UUずつでようやく95%信頼度になりました。
したがってテスト期間中に合計6万UUがそもそも集まる見込みがない場合は、たとえばCVの定義を「注文完了」でなく手前の「カート追加」にするなど、もっと短期間でCVが多く稼げる形などにテスト自体を見直す必要があります。
なお、オプティマイズはGAアカウントと紐付けて使用することになりますが、紐付けられるGAアカウントは1コンテナあたり1つだけとなっているので、UAとGA4用でコンテナを分ける必要があります。また、UA用とGA4用では配信期間の上限が異なっていて、UAは最長90日間ですがGA4はもっと短くなってしまって最長で35日となっています。なので35日で6万UUが集まるようにしないといけないということで、GA4はテスト実施のハードルが若干上がっています。
上記のような事情があるので、テスト範囲を広くするために正規表現を駆使したいところです。ただ、正規表現は書き間違いも起きやすいので、GAで正規表現で検索してみて、どのURLにテスト配信されるのかはあらかじめチェックしておくことが望ましいです。（正規表現についてはこちらの記事で詳しくまとめているので良かったら読んでください）
副目標として「間接指標」を必ず設定したほうがよい
ABテストの成果指標には、直接指標と間接指標があります。
ABテストの目的は基本的にはサイト改善を通じて売上や利益を増やすことなので、オプティマイズにおいては「主目標」でCV数、加えてeコマース設定をしているGAであれば収益を、2つ設定できる「副目標」のうちの1つに設定すると思います。この2つが売上や利益に直結する直接指標で、テストの効果を説明するうえで一番わかり易い指標です。
間接指標というのは例えば「商品詳細ページから注文フォーム入力ページへの遷移率を改善してCV数を増やす」みたいなテストにおける、「フォーム入力ページへの遷移数」のようなものです。これが増えたからといってCVが増えるとは限らないけど、手前のページで行ったUI変更の効果を端的に示す指標ではあるので、ちょっと面倒ですが取っておいたほうがテスト結果のレビューがしやすいです。
設定はお好みですが例えば下記の様な感じ。
ABテストは、本当にわかりやすく改善するのはだいたい4回に1回くらいで、ほかは上がってるのかどうかよく分からないというケースになります。
よく分からないという結果のうち半分くらいが、「間接指標は上がったけど直接指標は変わらなかった」というケースで、間接指標を取っていればこういうケースでも一応改善を前に進められます。たとえば間接指標がないと「注文数が変わらなかったから全然意味なかったね」で終わりやすいですが、間接指標があれば「注文数は変わらなかったけれど、フォームへの遷移数は増えたわけだから、次はフォームに課題がある可能性を検討してみよう」という感じで、話が前に進みやすくなります。
このようにテストがあんまりうまく行かなかったときの打ち手をあらかじめ考えておくのは結構重要なので、忘れずに設定しましょう。
まとめ
こうやって見てみると、オプティマイズを使ったABテストって結構やること多くてめんどくさいですね。
僕の前職のギャプライズは、Optimizely, ABTasty, VWO という海外製の有料ABテストツールを代理店として提供していますが、これらのツールたちはもうちょっと気が利いているのかも知んないですね。使ったこと無いので詳細わからないですが。
プロジェクトとしてきちんと回す場合は実施数が重要なので、例えばオプティマイズのABテスト実施枠を常に3つか4つは稼働している状態を維持するとか、月2個はテスト開始するとか、そういうルールで運用するのも良いかもです。そのときに1つのテストで準備に時間かけてコネコネしてると実施数がなかなか増えていかないので、時短できる部分は時短して、うまくやるのが大事かなと思います。
