サイト改善の王道手法「A/Bテスト」を行う際のマインドと組織づくりとは

サイト改善の王道手法になりつつある「A/Bテスト」。A/Bテストツール導入のメリットからテストを運用するための心構えと、また、弊社メディア「Appliv」で行った組織を巻き込んだ強化方法について紹介します。

今回は「Googleオプティマイズによるウェブテストの教科書 ~A/Bテスト、リダイレクトテスト、多変量テストの実際~」（マイナビ出版）の執筆に参加した弊社メディア「Appliv」の責任者である針替健太と、デジタルマーケティング事業部でA/Bテストのコンサルティング・代行支援を行っているスペシャリスト飯野佐知子に話してもらいました。

＼ナイルのサイト改善提案の紹介はこちらから！／

A/Bテストツール導入で実装工数の削減とデータドリブンを実現

飯野：A/Bテストのメリットとしてよく言われていることは、大きなリニューアルを行う際に、失敗してしまった際の人的・資金的なリソースが無駄になってしまうリスクを事前にA/Bテストを行うことで回避できるという点ですよね。

針替：あとは、数値に基づいて改善案を出すことで改善案の精度もだいぶ上がります。数値など根拠がなにもない中で、リニューアルを行ってしまうと感覚や気持ちでリニューアルをやりがちになってしまう。A/Bテストを行うことで、データに基づいてリニューアルの改善案を考えることができます。

飯野：A/Bテストを行うことで、実際にApplivでもあったような感覚的な意見の効果検証を行う事ができる点はメリットですね。以前まではA/Bテストツールも高価で手が出しにくいものだったけれど、Googleが無料（※一部機能は有料版のみ）でGoogleオプティマイズを公開したことでA/Bテストツール導入のハードルは下がりましたよね。

針替： ApplivでもGoogleオプティマイズを導入したことですごく手軽にテストすることができるようになりました。もともとA/Bテスト自体はやっていたんですが、ツールを使わないでA/Bテストを行おうとすると施策を実装するだけで開発工数が掛かっていました。Googleオプティマイズを導入することで、テストの工数は大きく下げられました。

針替：効果検証も以前は検定を行わずに、Google アナリティクスで集計してなんとなく「コンバージョンが上がってるから成功」みたいな程度で採用することもありましたが、レポーティングや効果検証をするのもGoogleオプティマイズで楽になったし、データドリブンで日々の改善精度も上がりました。

ユーザー視点で仮説を立てCTR145％改善

飯野：Applivももちろんですがクライアントなどの事業をされている方は日々の改善活動が必要で、A/Bテストで確実に成果を積み上げることは必須になってきていますよね。
コンサルティング業務では、A/Bテストを始める前にサイト全体のアクセス解析を行い、改善対象ページの優先度を見極めてA/Bテストを行っています。
Applivではどうやってテストを実施しているんですか？

針替：改善インパクトが大きいところから取り組むべきなので、ユーザーの流入元の大多数を占めているアプリの一覧ページを重視しています。常に何かしらのテストが回っている状態です。
このページでどういう訴求をすれば、Applivの重要視している指標であるアプリストアへの遷移に繋がるか、自然なカタチでおすすめアプリをクリックしてくれるのかを考えています。

飯野：アプリストアの遷移先バナーの文言はCTRに影響してきますよね。

針替：サイトに来たユーザーが自分にあったアプリを探す時にどういう情報を求めているのか、あとは情報量が多すぎないかなど、ユーザー視点で仮説を立て、テストを行ってます。最近でも、おすすめアプリ枠に「Applivおすすめ」というラベルを追加するだけで、CTRが145%改善と成果が出ています。

スピードを落とさずA/Bテストを運用するコツは「決めの問題」

針替： 最近思うことは、うまく行っているときはスピード感をもって改善出来ているが、サンプル数の問題などで、結果に傾向が出にくいテストが重なってしまった時に、慎重になりすぎてしまいスピード感が下がってしまうなと感じてます。

飯野：分かりやすい結果が出ることってそう多くは無いし、逆にそういったパターンのほうが多いですよね。そういう時ってどう判断していますか？

針替：基本的には、「決断する期間を事前に決めておく」ということは常に心に留めています。期間を設定しておかないとズルズルとテストしてしまうので、期間を決めて、関係者で集まって結果について話し合い、次のテストを決めてます。

飯野：私も期間を決めるようにしていて、そのうえでテスト結果に統計的に有意な差が出ていなくても常に安定した傾向が出ていたら、勝ち負けを判断して、次のテストにいくようにします。累積データだけではなく、デイリーのデータも見て、問題ないかと思えるかどうかも参考にすることがあります。

針替：うちもいくつかの指標をみて、他の指標にも悪影響がなく、良い傾向があれば割り切ります。そこはもう「決めの問題」ですよね。

飯野：そう。あと、いい結果が出ないときは一度施策の仮説に立ち返って、結果を突き詰めることを大事にしています。テスト結果では仮説が正しかったかどうかを考えるようにしていて、仮説が棄却できたならそもそもの仮説を見直すように考えてます。

大前提として「仮説ありきの施策」を行えているか

飯野：針替さんがA/Bテストを行う上で、重要だと思うことって他になにかありますか？

針替：A/Bテスト案は大胆に変えないとテスト結果がでないことが往々にしてあるので、これは意識しています。でも、やっぱり「仮説ありきでテストを進めないと意味がない」という点です。とりあえずボタンをオレンジ色に変えてみようと施策を行っても結果は出ないです。

飯野：そもそも仮説がないと何で良くなったのかという原因が分からないし、振り返りや次の施策に活かすこととかもできないです。また、いい結果が得られなかった場合には、テストが終わったらまた別の新しいテスト案をどこかから捻出する必要が出てくるので、PDCA回らなくなっちゃうことってよくありますよね。

針替：あるあるですね。

飯野：でも、仮説が重要ではあるんですが、仮説がないアイデアをだからといって全くダメということにしないようにしています。

みんなの”勘“から出てくるアイデアも意外と当たっていることはよくあります。もちろん施策を行う前にそのアイデアに対して仮説の裏付けをする必要はありますけど、まずやってみてPDCAを回すサイクルを作ることに主眼をおいて、「導入のためのテスト」を行うこともあります。

A/Bテストを組織に浸透させることで様々な視点でアイデアが出てくる

飯野：コンサルティング業務のA/Bテストの初期段階では社内のアナリストを集めて施策案のブレストを行います。最終的な施策の実行、優先度の判断は担当アナリストが行ってますが。
Applivでは施策案の案出しから、実行可否の判断はどうされてますか？

針替：似たような感じで決めてます。今のApplivの運用体制はプロジェクト単位で動いていて、そのプロジェクトの中にマーケッター、エンジニア、デザイナーがいます。

プロジェクトメンバーで話し合い施策案を決めてますが、最終的に、プロジェクトリーダーが優先度つけています。実施決定した施策をプロジェクトメンバーの誰かがGoogleオプティマイズを設定してテストを動かしてます。

飯野：「誰かが」ということは、プロジェクトメンバー全員がA/Bテストの実装や設定ができるんですか？すごいですね。

針替：一通りできるはずです。社内にエバンジェリスト的な人がいないとみんなができるようにならないと思っていました。自分が勉強会を開きA/Bテストの面白さや成果に繋がるといった点をメンバーに伝えてA/Bテストを浸透させてきました。
やっぱり一人で施策案出しをやってると限界が出てくるんですよ。みんながA/Bテストを行える状態を作ることで、自分に無かったアイデアが出てくるようになりました。

ユーザーの気持ちの汲み取りや曖昧な結果は人の判断が必要

針替：基本的には、ウェブテストはどのサイトでもやったほうがいいと思います。だから、A/Bテストはwebでビジネスをしている人全員が導入してもいいと思ってます。

針替：ただし、A/Bテストツールを導入することが目的になってはいけない。目標達成に向けて仮説ありきのテストを行わないと、成果がでなくなってしまった時に結局モチベーションが無くなってABテストを行わなくなってしまいます。

飯野：A/Bテストツールはすごいですし、AIが流行って今まで人がやっていた仕事がなくなると言われてます。ただ、A/Bテストの施策案の仮説立てを行うために、ユーザーの気持ちを考えるとか想像するというところは、まだまだ人の頭で考えないといけないなと思ってます。

針替：Googleオプティマイズは便利ですが、所詮ツールなのでA/Bテストを行う上で一番大事になる「仮説を立てる」「レポート・結果を判断する」といったことは人間が行うことになります。

「仮説ありきの施策を立てる」「レポートとの向き合い方」「テスト結果の判断の仕方」などA/Bテストを行う上でのマインドを本書で紹介しています。そういったマインドを醸成させるためにも本著を読んでもらえると嬉しいです。

・「Googleオプティマイズによるウェブテストの教科書 ~A/Bテスト、リダイレクトテスト、多変量テストの実際~」（マイナビ出版）>

・収益改善A/Bテスト代行サービス