デプロイせずにABテストを行う

この記事は[PORT Advent Calender](https://qiita.com/advent-calendar/2017/port)の6日目の穴埋めです。
個人的にやってみたのをまとめておきます。

# 前書き
昨今ABテストは様々なツールでの導入が行われ、Webサービス開発にはなくてはならない存在です。弊社でも[split](https://github.com/splitrb/split)を用いたABテスト検証が行われますが、ABテストを仕込むためにはデプロイが必要です。また、見た目のABテストのためのロジックをアプリケーションに入れ込むのもなんだか気が乗りません。

そんな時、外部ツールに任せたいなと思って知ったのが、googleが提供している[Google Optimize](https://www.google.com/analytics/optimize/)です。試しに使ってみようと思います。

# Google Optimizeとは
[オプティマイズについて](https://support.google.com/360suite/optimize/answer/6197440?hl=ja&ref_topic=6314903)
ABテストの他、リダイレクトテストや多変量テストが行えるみたいです。また、GoogleAnalyticsと連携して目標やリンククリックイベントをコンバージョンポイントにできるらしいです。

また、無料で使えました。制限は以下の通りです。
[オプティマイズとオプティマイズ 360 の比較](https://support.google.com/360suite/optimize/answer/7084762?hl=ja)

制限はあるものの、他社のマーケティングツールは軒並み有料なのを考えるととても嬉しいですね。

# 準備
アカウントとコンテナの作成。

## アカウント
複数のコンテナを一括りにしたもの。他のユーザへの共有をこの単位で行うみたいです。

## コンテナ
複数のテストを一括りにしたもの。コンテナIDが割り振られるので、それをアプリケーション側にも設定する感じになる

ここまででテストを作れますが、`googleアナリティクスへのリンク`と`オプティマイズプラグインのインストール`は先にやってしまいましょう。

![スクリーンショット_2018-01-02_5_49_00.png](https://qiita-image-store.s3.amazonaws.com/0/140026/26c1bf86-d5e2-de88-63ca-343dd5cdd6f3.png)

## その他

基本的にはチュートリアルに沿っていけば難なく行えると思います。ただし私はanalytics.jsではなくGoogle Site Tag(gtag.js)を利用していたので、記述方法が異なっていました。
https://support.google.com/360suite/optimize/answer/7513085
上記通りにやってみましたが、ABテストが実行されずハマりました（プレビューまでは難なくいけたんだけど）
analytics.jsに差し替えて確認したところ、問題なくいけちゃいました。なぜgtagでいけなかったのかはまだわからず終いです。

# テストの作成手順
![スクリーンショット 2018-01-02 5.57.38.png](https://qiita-image-store.s3.amazonaws.com/0/140026/7eb6e3b2-cb89-0616-96ea-d59aee6c95a3.png)

テスト名、対象ページのURL、テストタイプを選んで作成します。今回はA/Bテスト

あとは、チュートリアルの通りで、パターンの作成、目標の設定、ターゲット設定で完了でした。簡単ですね。

## パターンの作成
下記でも記載しますがここではあくまでパターンの作成なので、正規表現等で条件を作成し、複数ページでテストすることが可能みたいです。

![スクリーンショット 2018-01-02 6.05.12.png](https://qiita-image-store.s3.amazonaws.com/0/140026/d00dc450-21b9-cf73-6c56-93d21d13f3a2.png)
こんな感じでUI上で色々いじれました。また、htmlの編集やjavascriptの実行も行えるので、やりたいことはだいたいできると思います。

今回のサンプルではcssを当ててボタンのデザインを変更してみました。

![スクリーンショット 2018-01-02 6.15.16.png](https://qiita-image-store.s3.amazonaws.com/0/140026/b6c1dd33-0f40-81e3-f720-4947b6da90ef.png)

![スクリーンショット 2018-01-02 6.15.36.png](https://qiita-image-store.s3.amazonaws.com/0/140026/e05c6b42-ecf2-09fc-03bf-0888dde6b81e.png)

## 目標の設定
今回のテストのコンバージョンポイントを指定します。
デフォルトで用意されているもの（セッション数、ページビュー数、直帰数）だと、ボタンのデザイン変更などでどの程度リンク先に遷移したかは測ることができないです。

測るための方法はいくつかありました。

- googleアナリティクスの目標を作成し、到達プロセスを設定、それを利用する
- カスタム目標を利用する
    - ページビュー数

カスタム目標はトラッキングイベントで指定することもできますが、デプロイなしだとオリジナルでも`send('event', ...)`を配置する必要があるのでできませんでした。
どちらも簡単ですが、今回は一番シンプルなページビュー数でやってみようと思います。

リンク先のページを指定するのみです。
![スクリーンショット 2018-01-02 6.37.06.png](https://qiita-image-store.s3.amazonaws.com/0/140026/7a1fc3bc-de64-ede8-e026-e332747d11f9.png)


ちょっと心配なのは、`/articles`にオーガニックなどから直接流入した場合はそれが除外されるかどうかですが、多分されると思うので気にしないようにします。（後日検証）

## ターゲット
基本的にはこのままの設定で良さそうです。
![スクリーンショット 2018-01-02 6.46.08.png](https://qiita-image-store.s3.amazonaws.com/0/140026/e73695f8-528a-e03f-d4e4-6ef324b08d9e.png)

## 条件
![スクリーンショット 2018-01-02 6.50.12.png](https://qiita-image-store.s3.amazonaws.com/0/140026/85e41343-5a48-077e-5545-12e47b270629.png)
条件を指定することで、テスト対象のページを決めることができます。正規表現も使えました

# テスト後
まだ十分な検証データがなく、レポーティング機能が見れない・・！後日まとめようとおもいます


# 最後に
簡単にABテストを実行できました。これで素早くPDCAが回せそうですね。
注意点としては、ABテストが実行されている箇所がアプリケーションから切り離されているので

- テストが実行されていることの可視化とコミュニケーション（エンジニアがびっくりする）
- ABテストを実行する前の検証注意（影響範囲が大きな変更を容易にできてしまう）

が大事な感じがしました。

また、緊急的な対応（文言修正など）があるけどデプロイができない時も、ターゲットを検証パターンに100%振り切ってしまえば取り急ぎの対応にも使えそうでした。