こちらは、アソビュー！Advent Calendar 22日目の記事になります。
はじめまして！新卒2年目の山内と申します。
特徴的な髪型から、社内ではキノコとしばしば呼ばれています。
現在は、社内基幹システムの運用保守とバックエンド開発をしているのですが、1年目のときにアソビュー！のグロースを目的としたA/Bテストを行っていたので、その時のことを書いていこうと思います。
A/Bテストとは
A/Bテストとは、オリジナルページに変化を加え、オリジナルパターンとテストパターンを同条件で比べて効果をはかるテスト手法になります。
様々なツールがありますが、弊社では、VWO（visual website optimizer）やGoogle Optimizeを利用していました。 今回は、Google Optimizeでの手法を紹介していこうと思います。
テスト準備
さて、いざテスト実装と言いたいところですが、施策を考えなければ実装ができません。
施策を考えるときに重要になるのが、施策の目的・課題・仮説を明確にすることです。
▼ページを特定
まず、テストを行うページを特定します。
▼課題の抽出・仮説出し
次に仮説を考え、そのページにはどのような課題があるかを洗い出します。
私の場合、色々な場面で実際にアソビュー！を使って仮説を出していきました。
外にいるときはこのボタンは目立たないかもしれない。であったり、
お出かけ先で、明日の朝体験したいとなったらどのような情報があったら良いだろうか。
等々あらゆる場面や時間、状況を想定しました。
また、実際に知人にアソビューを使ってもらい、ページの課題のインタビューを行いました。
▼施策出し
最後に、課題を解決する施策を出します。
このように施策を考え出すまでの目的・課題・仮説を明確にすることでテスト後の考察が的確にできるようになります。
いざテスト実装
いざ、テストを実装していきます。
今回は、アソビューのチケット枚数選択画面の「購入する」というボタンに対して実際に行ったテスト例を紹介します。
- 購入に進む
- 上記で購入に進む
- 次へ
- 枚数を確定する
こちらの4つの文言をOptimizeに反映させ、テストを作成します。
OptimizeではGUIで簡単にボタンの大きさや色、文言を変更することができます。
ただ、この方法だと実際のページ上にDOMが追加されたり、複数ボタンがある際に思わぬ挙動を起こす可能性があるため、
直接Optimize上でCSSを上書きする方法がおすすめです。
Optimize上で実際にCSSを書いてみるとこのような感じで文言の変更ができます。
.button {
font-size : 0px;
}
.button::after {
font-size : 14px;
content : "購入にすすむ";
}
※クラス名は仮です。
このようにCSSを上書きすることで、文言の変更を行うことができます。
テスト開始
テストパターンの作成が完了したら、目標の設定や、テスト対象ページの設定、対象デバイス（PC/SP/タブレット）等の選択を行い開始ボタンを押すと実際に開始されます。
ページにもよりますが、2週間ほどテストを行うと十分なOptimizeが十分な結果が取れたと認識し、レポートが作成されます。
効果検証
最も重要なのは効果検証です。
今回の結果から、「購入に進む」というすぐに購入するわけではないという文言を示したことにより、ゲストの不安が払拭され、次ページへの遷移率が向上したと考察する事ができます。
このように結果を元に、なんでうまくいったのだろう、なんでうまくいかなかったのだろうと考察すると思います。
その際に活きるのが、テスト前に明確にした施策を行った目的・課題・仮説です。
うまくいった際は、この仮説のようなゲストが多かった、なので同じ仮説を元に考えると次はこの施策をやってみよう、であったり、
うまくいかなかった際にも、この仮説のようなゲストは少なかった、なので次の施策はこうすれば良いのではないかと考えることができます。
施策の目的・課題・仮説を明確にすることで格段に素早くPDCAを回すことができます。
効果まとめ
1つのテストが終了し、結果を集約することも重要です。
私達は、A/Bテストの成功事例を青シート、失敗事例を赤シートというようにまとめました。
今回の結果をまとめたシートがこちらです。
失敗した際も同じように考察し、シートにまとめます。
変更点は何なのか、目標や仮説は何なのか、結果はどうなったのか、どう考察できるのか、をすべての施策に対してまとめました。
このようにシートにまとめることで、ひと目で過去の具体的なA/Bテストの振り返りや、社内でA/Bテストの知見を広めることができます。
また、A/Bテストのタスク管理チケットや実際の結果、青/赤シートがわかるようにスプレッドシートに集約し、管理していました。
このように一括して管理することで、テスト後のソースコード改修や、変化率、テストの消化状況をモニタリングすることができます。
まとめ
実際に僕は紹介した手法で、2ヶ月間で15個ほどのA/Bテストを実行しました。
うまくいったもの、いかなかったものとそれぞれありましたが、どちらのパターンもシートにまとめ考察することで、アソビュー！を利用するゲストがより使いやすくなるにはどう改修すればいいのか、という知見を貯めることができたと思います。
これからA/Bテストを行おうと思っている方は参考にしていただけると幸いです！
最後に
アソビューでは、一緒にワクワクしながら課題解決の遊びしたい方大募集中です！
