ウェブサイトの改善プロセスを学ぼう！〜後編：仮説立案から結果の検証まで〜

前編では、ウェブサイトのCVR改善のプロセスのうち、「目標の定義」と「調査、分析」のフェーズについてご説明しました。必要なデータが蓄積されてきたら、次のフェーズへと進みましょう。今回は、「仮説立案と優先順位づけ」、「テストの実装」、「結果の検証」のフェーズについてお伝えします。

↓ 前編はこちら

仮説のリストアップ

調査、分析によって解決すべき問題や課題が明確になったら、改善のための仮説を立案しましょう。得られたデータやヒートマップから、どのような知見が得られるでしょうか。
どんな施策を行えば、ウェブサイトの成果が改善するでしょうか。
このとき、「事実」と「推察」と「施策」に分けて考え、ロジックが破綻しないよう意識しましょう。
例えば
「フォーム到達後に離脱が多い」という課題が見えており、ヒートマップより、「ナビゲーションへのタップが多い」という事実がわかったとします。
「ユーザーがナビゲーションに気を取られ、フォームに集中できていない」という推察から、「フォームのページでは、ナビゲーションを隠す」という施策が考えられます。
まとめると、「フォームのページでは、ナビゲーションを隠す事により離脱が防げる」という仮説になります。

このようにテータと事実を元にした仮説を複数立案していきましょう。
解像度の高い「調査と分析」ができていると、質の高い仮説立案につながります。

優先順位付け

仮説が一つ立てられたからと言って、それに飛びついてテストを始めてしまうのは早計です。「思いついた仮説を順番に行う」のではなく、複数の仮説を並べ、優先順位をつけて、成果につながるものから実行するべき、というところに注意しましょう。
テストの優先順位をつける手法として、「PIEスコア」や「ICEスコア」という方法があります。良く似ているので、まずは自分に合ってしっくり来る方を選べばよいでしょう。
「PIEスコア」
Potential：ページに対しどの程度良い効果が見込める？
Importance：その改善箇所はどのくらい重要？
Ease: テストの実装はどれくらいかんたんにできる？

「ICEスコア」
Impact ：このテストはどの程度影響がある？
Confidence ：このテストが仮説を証明するということをどの程度確信できる？
Ease：テストの実装はどれくらいかんたんにできる？

これらの各基準を1〜10の範囲で採点し、平均値をICEスコアとして算出します。スコアが高いものから優先的にテストを行います。

３つのスコアに慣れないようなら、「実装は簡単か」と、「改善効果がどれぐらい見込めるか」の２つのスコアから運用してみましょう。

テストの設計

優先順位ができ、どのテストを行うか決まったら、いよいよテストを実装しましょう！
その前に、チェックしておくべきことがいくつかあります。

・ゴールが設定できていることを確認

ABテストを定量的に評価するため、目的のコンバージョン、マイクロコンバージョンがゴールとして設定されていることを確認しましょう。

・テストの対象を明確にする

あらかじめデバイスや流入元による傾向が明らかなのであれば、対象を絞ってテストを行いましょう。新規のユーザーだけにテストを行う必要があれば、それも考慮に入れます。

・テストの期間の設定

流入数と想定コンバージョン数から逆算し、どれくらいの期間テストを行うか決めます。
閲覧者の行動、習慣を必ず考慮に入れましょう。例えば土日と平日では全く行動は異なりますので、最低一週間はテストを行う必要があります。ページへの流入数から逆算して、どれくらいの期間が必要なのか考えましょう。

・テストパターンの数は？A/Bテストか？多変量テストか？

テストに際して、複数の改善案を同時に試したい、と思うかもしれません。
しかし、複数のパターンでテストを行うと、サンプルが分散してしまい、どのパターンが成果が高かったのか統計学的に有意な差がでるまでに時間がかかってしまいます。また、複数の箇所を同時にテストすることも、どの部分が改善に効果があったのか曖昧になるので避けましょう。
ただし、十分な流入量があるのであれば、複数パターンのテストや、「多変量テスト」で同時に複数の案を実装することも視野に入れます。

・書き換えパターンかリダイレクトテストか

SiTest をはじめ多くのA/Bテストツールでは、ヴィジュアルエディターなどを使いURLを変えずにテストパターンが作れる機能と、別々のURLを用意してテストを行える機能があります。同じURLで一箇所だけクリエイティブの比較をするならエディターをつかった「書き換えテスト」がおすすめですし、ページ内の殆どの要素を変えてしまうのであれば別々のURLをつか「リダイレクトテスト」を行うほうが安定します。それぞれのメリットデメリットを知って使い分けましょう。

そのテストで本当に仮説が検証できるのか注意して設計しましょう。

テストパターンの作成

どのようなテストを行うか設計できたら、ツールを使ってテストパターンをつくりましょう。リダイレクトテストの場合はデザインやコーディングが必要になるかもしれません。「優先順位付け」の際に確認しているはずですが、実装にあまりに時間や労力、技術がいるようなテストは好ましくありません。画像を作成して貼り付けるなど、細かいコーディングは使わずできるだけシンプルな操作で仮説が検証できるようにしましょう。テストで大事なのは「仮説が正しいか」早く検証することです。ディテールはテストで結果が出てから詰めましょう。またパターンはできるだけ実環境で配信して問題がないことを確認しましょう。

テストのスタート

準備が完了し、テストをスタートしたら、しばらくはデータが正しく取得されているか確認します。目的のセグメントに配信されているでしょうか。また極端な差が出ていないかなど注意して進めましょう。安定してデータが取得できているようなら、一定のスパンで確認しつつ、設計した期間まで待ちましょう。
パターン同士に大きな差がついている場合は、より短い期間で終了してもよいでしょう。
SiTest では、ベイズ統計をもとに「勝利する確率」を算出しており、それをもとに王冠マークを表示することで勝ちパターンを判定しやすくしています。逆にしばらくテストをおこなってもあまり有意な差が出ていない場合、一旦テストを終了し次のテストを進行することも考えておきましょう。

出た結果に対して仮説は正しかったのか、異なっていたのか分析、検証しましょう。最終のゴール（コンバージョン）が多かった少なかったということだけにとらわれず、訪問者が意図したとおりの行動をとったのかを分析します。ボタンクリックやスクロール到達などのマイクロコンバージョンや、ヒートマップを確認することでより解像度の高い分析を行いましょう。仮説通りにならなかった場合は、なぜ結果が出なかったのかを検証しましょう。「上手くいかない場合」の知見を得ることも、今後の成功のためには重要です。

フィードバック

検証によって得られた知見を、ウェブサイトに反映します。結果にもとづいてページをリニューアルするか、必要があればブラッシュアップしたフォローテストを行いましょう。
改めてリストアップした仮説に立ち返り、改善できそうな施策を繰り返しテストしていきます。

今回の記事ではウェブサイトの改善プロセスのうち「仮説立案と優先順位付け」と「テストの実装」、そして「結果の検証」についてお伝えしました。
重要なポイントは、

などが挙げられます。

SiTest を使えば、分析で得られた仮説をスピーディーにテスト実装、検証できます。
ツールのしての機能性、使いやすさはもちろん、「ウェブサイト改善ははじめて」といった場合にも、国産ツールならではの充実したサポート体制でご活用をフォローしています。