サイトを改善する上で重要になるものにABテストがあります。

これは違うデザインのサイトパターンAとB（2つ以上でも言い）を実際にユーザーに使って貰って、より効果の高い方を採用するというテストですが、ABテストを実施する上で考えないといけない厄介な事が幾つかあります。

1. ユーザーを振り分けて違うデザインを見せる必要がある
2. 効果測定を行うための仕組みが必要になる
3. 各パターンのview数にばらつきがでるので補正する必要がある

特に１が厄介で、単にランダムで見せれば良いわけではなくて、一度テストパターンを見せたユーザーにはテスト期間中ずっと同じページを見せる必要があります。

細かく言っていくとキリがないのですが、この辺りの悩ましさはGoogle Analyticsでまとめて解決してくれます。

AnalyticsによるABテストのメリット

凄く簡単に言うと楽だって事ですが、ちゃんと書くと以下のメリットがあります。

1. jsを貼るだけでユーザーの振り分けをしてくれる
2. ユーザーを振り分けるロジックが柔軟（多腕バンディットテストを採用）
3. 効果測定がAnalytics標準的な機能が使える
4. 集計から判定までAnalytics任せに出来る

デメリットはというと、jsかつ一般的に公開されているので、ABテストを実施していることがバレバレっていう所があります。

実際に設定する所を見てみる

AnalyticsでのABテストはウェブテストという名称で、「標準レポート」→「コンテンツ」→「ウェブテスト」にあります。

クリックするとまず始めにテストを実施するページのURLを入力します。後述しますが、このURLは絶対ではなく、IDなどURLの一部が動的に変わるページでも大丈夫です。

次はテストの基本設定です。

名称はわかり安いものならなんでもOKだとして、ちょっと解り辛い項目を説明しておきます。

このテストの目的

これが成果ポイントとなります。シンプルにPVや直帰率、滞在時間などの指標の他、イベント数や特定URLへのフロー、商品の販売数などかなり柔軟に設定できます。複雑な条件に関しては、「標準レポート」→「コンバージョン」→「目標 or eコマース」に別途設定しまたものがそのまま使えます。よく使いそうなのは、クリックイベントの件数などでしょうか。

テスト対象のトラフィックの割合

画像では100%になっていますが、これはテストパターンを見せる対象のパーセンテージで、ABテストですからオリジナルのページも含まれます。

テストパターンが１つの場合、テスト当初に割り振られるのは、

オリジナルのページ(50%) + テストパターンA（50%）

となります。もしテストパターンが3つあった場合は、

オリジナルのページ(33.3..%) + テストパターンA（33.3..%）+テストパターンB（33.3..%）

です。

割合は100, 75, 50, 25, 10, 5, 1（いずれも%）から選べます。50%でパターンが2つのケースならば、

オリジナルのページ(50%) + テストパターンA（25%）+テストパターンB（25%）

になります。対象の割合をテストパターン数でシェアする感じです。

ただし、ウェブテストが採用するアルゴリズムは多腕バンディットテストで、実はテストパターンに割り振られる比率が動的に変わります。その辺りは公式のドキュメント(多腕バンディット テスト)に詳しい記述があります。冒頭を引用すると。

「多腕バンディット（multi-armed bandit）」という名前は、それぞれに異なる見込み配当率が設定された、「One-armed bandit（片腕の盗賊）」というスロット マシンが複数並んでいる状況を模した仮説テストという意味を持っています。スロット マシンのプレイヤーは、最も見込み配当率が高いスロット マシンを見つけ出す必要がある一方で、利益を最大化する必要もあります。この状況では、これまでの配当率が最も優れているマシンのみをプレイするか、それともさらに配当率が高いマシンがある場合を想定し、別のマシン（配当率が劣る可能性もあるマシン）も試してみるべきか、というジレンマが生じます。Google アナリティクス ウェブテストでは、この多腕バンディット問題に対処するために構築された高度な数学モデルを使用します。

具体例を交え解りやすく書かれているので、一読してみるのをお勧めします。

詳細設定の所は主にテストの期間に関わる設定ですが、はじめはそのままで良いでしょう。デフォルトで最低テスト期間が２週間なので、もっと短くしたいときのみ設定するところですが、最適パターンが見つからず終わるケースもあります。

次は具体的なテストページの設定をします。

このケースはパターンAとBのページを設定しています。パターンAがオリジナルのページだと思って下さい。オリジナルのページは絶対パスを設定する必要がありますが、テストパターンの方は相対パスを指定出来ます。

一番シンプルなのはhtmlを分けて、index_a.htmlとindex_b.htmlなどに分けるケースですが、動的なサイトではこれはちょっと面倒な事が多いですよね。この相対パスを使えば一つのhtml内で条件分岐して表示を変えることが出来ます。

たとえば、テストするウェブページをhttp://example.com/とした場合、テストパターンのウェブページの設定をrelativeの?var=1と設定すると、http://example.com/とhttp://example.com/?var=1bに振り分けてくれます。なお、location hashを使った#var=1なども可能です。詳しくは公式ドキュメント(パターンのページの相対 URL)にあります。

そもそもURLにクエリパラメータがついていた場合のケースはどうなるかと言うと、基本的にパラメータを継承してくれるので問題無く動くはずです。こちらも公式ドキュメント(オリジナルまたはパターンのページのパラメータの伝達)に詳しく書いてあります。

テストパターンページは最大で９個まで設定できます。あと、テストパターンのURLが異なる場合は検索エンジンでの評価が下がらないようにrel="canonical"を設定する必要があります。（参考:ウェブテストと SEO ランキング）

上記の設定で生成されたコードを埋め込みます。特に此処は言うことないです。

コードを設定したら次に進むと、コードのチェックをしてくれます。

テスト開始を押すと実際に振り分けが始まります。

URLが動的に変わる場合はどうなるか？

ドキュメントとして見つけられなかったのですが、URLにパラメータを埋め込んでいるケースは良くあると思います。たとえば http://example.com/entry/34959/の様に、最後の34959がドキュメントのidになっているケースです。

オリジナルのURLは絶対パスしかかけないので、http://example.com/entry/34959/しか登録できないのですが、たとえば、http://example.com/entry/4567/とアクセスされた場合は、テストが無効になるのか？というのが疑問でした。結論から言うと、下記の設定でhttp://example.com/entry/4567/でアクセスした場合もちゃんとテストを有効になっていました。

1. オリジナルのURLは代表となるURLを入れる(この場合http://example.com/entry/34959/)
2. テストパターンのURLは全てrelativeで設定する

こうする事で、http://example.com/entry/1234/でアクセスすると、http://example.com/entry/1234/?var=1など適切にリダイレクトされます。

設定に必要な事は書いたつもりですが、ウェブテストの仕組みや効率良くテストを行うためのパターンの作り方など、色々かいてあるので、公式ドキュメントは見ておくと良いと思います。

Analyticsを導入しているサイトは多いと思うので、試して見てはいかがでしょうか？

注意すべき点 5/11追記

１つ書き忘れていました。この方式の弊害として、テストページへの振り分けにjsを使ってリダイレクトしているというのがあります。つまり、振り分けされるまえのアクセスも振り分けのためのリダイレクトもHTTPのステータス200になります。

なにが問題になるかというと、リダイレクトされているにもかかわらずアクセスログでは２回アクセスされているのと同じように見えてしまいます。なので、アクセスログからPVを集計する際に、リダイレクト後のアクセスをカウントしないようにするなどの工夫が必要になります。