mixiグループアドベントカレンダー22日目の記事です。
2ヶ月くらい前にA/Bテストで改善しようとしたけどうまく行かなかった話を書きます。
失敗談から学ぶこともきっとあるかと思い、自ら恥を晒してみます。
経緯
チケットキャンプはこれまで創業者のセンスと思いで作り上げてきました。
創業者の頭のなかにあったものをゼロから形にしていたので、主に定性的な視点から改善を繰り返してきた訳ですが、ここから更に成長するためにも、違うアプローチをとってみようというのが今回の目的でした。
プランニング
まず、A/Bテストで改善するKPIを定める
A/Bテストを行う前に、何を持って成功とするかを定義する必要があります。
もちろん、サービスを成長させるためにA/Bテストを行うのですから、成功＝「サービスが成長している」となり、さらに深掘りして何を持ってサービスが成長しているかを定義します。
当たり前のことのように思いますが、意外と当初の目的を見失ってしまい、細かい改善を繰り返して見た目上の数字は良くなったけど、サービスの成長には結びついていなかったということがたまにあります。
チケットキャンプにおいては、もちろんチケットの取引がより多く成立することがサービスの成長だと考えているので、ここではDAUに対する決済数を決済率として、それを上げていくことを目標として定めました。
ちなみにこの決済率はここで初めて監視を始めたものではなく、常にモニタリングしている指標の一つです。
KPIを計測できるようにする
GoogleAnalyticsには、拡張eコマースという機能があり、それを用いることで、ショッピング行動のどこでユーザーが離脱しているかを見ることができます。
拡張eコマースについての詳しい説明と、実装方法については下記の記事が詳しいので割愛します。
Google アナリティクスで強化された「拡張eコマース」機能がサクッとわかる6つの特徴 | 単発記事 | Web担当者Forum
これをチケットキャンプに応用して、購入に至るまでのプロセスを可視化しました。
ユーザーがサイトに訪問してから決済に至るまでのトランザクション毎の数値がわかるようになったので、ボトルネックになっている箇所に対して施策を行い、これらの離脱しているポイントを改善していこうと考えました。
加えて、A/Bテストなので、A/Bパターンそれぞれ独立して計測できるようにする必要があります。
これはカスタムディメンションを用いて、ユーザーごとにランダムにA/Bを決めれば、簡単に計測可能となりました。
カスタムディメンションについては、下記の記事で詳しく説明されています。
http://qiita.com/ssaita/items/007d743fab5bf8739309
実行
実際に施策を打つ
ボタンの位置を変える、文字の大きさを変えるなど、見た目の変更だけなら、OptimizelyやKaizen platformなどのJavascriptを埋め込むだけのサービスで簡単にできますが、これらの導入は見送りました。
これらのサービスでは、コードの変更を行わずに自由にページのレイアウトを変更できるというところが特徴ですが、ユーザーの状態などサーバサイドで取得が必要なものに関しては、結局コードの修正が必要になるため、できることに制限があるだろうという判断でした。
上記2つの比較は下記が非常に参考になります。
http://blog.s-en.jp/optimizely-vs-planbcd-235.html
反省
なぜ浸透しなかったのか？
さて、準備もできて実際にA/Bテストが始まりました。。が、浸透せずにすぐに方針転換となりました。
理由は大きく3つありました。
- 開発が入るため改善施策を行うために時間が思ったよりもかかっていた
- 何件か施策を打った結果、殆ど改善が見られなかった。
- わかりやすくユーザーの満足度に繋がるような改善案がまだまだあった
（例えば、決済方法にケータイ払いの追加など）
結局のところ、費用対効果が悪いということで、仕組みは出来ましたが殆ど使われていません。
特に、2つ目のところで、既に2年間運営されてきたサイトを改善するので、納得感はある施策を打ったつもりではありますが、効果が目に見えて良くならないということが続きました。
しかも、その一つ一つにエンジニアのコストもかかっています。
3つ目のところについても、よくA/Bテストで○%改善！と謳っている記事がありますが、よく見ると「そりゃ改善するでしょ」という施策も多く、それはわざわざ追加のコストをかけてA/Bテストで比較する必要もないのかもしれません。
どうすればよかったか？
施策を行うためにかかるコストを最小限に抑えるべき
一つ一つの施策による微々たるものでも、2%改善を36回繰り返せば倍になります。
しかし36回の施策が全て改善に繋がるわけでもないし、その度にエンジニアのコストをかけることになるので、それを考えるとディレクターのみで行えるツールを導入するほうが結果的に良かったのかもしれません。
最後に
明日はmrmt大先生が「サンタさんとネットセキュリティ」について書いてくれる予定です。
おたのしみに！