ABテストの設計の流れ｜前篇

ABテストを言うと、ボタンを赤にするか緑にするかのイメージが強いですが、売上規模が一定以上のサービスにとって、施策によって、ほんの少しだけ予約率が下がってしまったら、数千万単位の売上損失に繋がってしまうことになるため、安易に施策を実施することができません。

それで、施策が売上への影響を把握するために、ABテストを実施し、有意に勝っていたら、施策を全展開し、本番反映に踏み切る流れが必要なわけです。

このブログを書こうと思ったきっかけは、この流れの中で、ABテストが意外と勝てないことが分かりました。
一体どうすれば勝てるかを、自分の振り返りも含め、今まで考えてきたことを整理しようと思います。

このブログに書いていることは、あくまでも私個人の理解 / 見解であるため、100%正しい保証はできませんが、「勝てるためのABテストの設計」に同じ悩みを抱える人に、参考程度に読んで頂けると嬉しいです。

AB設計のアプローチ

AB設計するには、様々なアプローチがありますが、私が今まで見てきたアプローチを分類すると、大きく２つあります。

調査による / 直感的なAB設計
データ / 技術ドリブンのAB設計

【調査による/直感的なAB】は、競合と自社のインタフェースを比較する / ユーザーにヒアリング・調査することを通じて、自社が劣っているところを改善するアプローチのことです。
※こういった調査も、定性・定量的なデータを使っているとも言えるが、人の主観が決める部分が多いため、「直感的なAB設計」と呼ばせていただきます。

このアプローチの強化版もあります。
ワークショップなどの形式に踏まえ、複数のメンバーで、改善できるアイディアを出し切ってから、アイディアをグルーピングして、順序を立てて、行っていくアプローチがあります。

その一方、【データ/技術ドリブンのAB設計】は、ユーザーのアクセスログから分析し、面白いファクトを見つけてから、仮設を立てて、改善を行っていくアプローチが多いです。
※もちろん、仮設や施策を考える時に、競合を参考したりユーザーヒアリングしたりすることが多いですが、比較的に客観的に決めることが多いため、ここでは、「データ/技術ドリブンのAB設計」と呼ばせてください。

この中でも、データサイエンティストがいる部隊では、商品の並び順や広告出稿などの、影響する売上規模が極めて高いところに、機械学習などの手法を使って改善を図るケースがあります。

どちらのアプローチがより優れているという話ではなく、必要性に応じて、手法を組み合わせるなり選ぶなりにしたほうが良いと、私は思います。
そして、何よりも、アプローチ / 手法を選ぶ前に、一回のABテストをどう設計するかより、なにを改善したいかを俯瞰し、全体を捉えてから、戦略 / 方向性を決めることが、極めて重要です。
特になかなか勝てない時は、方向性があることで、テストを中断することなく、リベンジに繋げられるからです。

それでは、全体のAB戦略〜具体的に毎回毎回のABの設計までの流れを紹介していきたいと思います。

全体のAB戦略〜個々のABまでの設計プロセス

AB全体のスコープ決め

一担当者として、あるABのプロジェクトを最初に受ける際に、テストする面 / 機能の指定なりなんなりのスコープは、一定レベルまで決められていることが多いでしょう。
しかし、スコープはある程度決められているとはいえ、具体的な施策に落とすには、まだまだスコープとして広すぎます。

この時に、以下２つの視点でスコープを絞ったほうが良いでしょう。

技術難易度
施策母数となるターゲットボリュームと改善余地のバランス

■技術難易度

レガシーのサービスのほど、技術制限が多く、改善したくてもなかなかできない課題が多くあります。
その中で、技術にとにかく強く、制限を突破できるチームなら、問題はありませんが、実際の現場において、こういった課題を長年放置するケースは少なくありません。

そのために、本来は解決すべきだが、技術の壁を解決できない課題に対して、諦めなければいけないのもあります。
ここは、技術者に相談・確認しながら、ある程度主観で決めて良いです。

■施策母数となるターゲットボリュームと改善余地のバランス

テストする面（具体的なページ）は決まった以上、ターゲットのボリュームが同じでは？と、そう思う人がいるかもしれません。
しかし、そうではありません。

例えば、ページの下にあるコンテンツと、ページの上にあるコンテンツを閲覧するユーザー数はイコールではないし、ページにある機能を、使ったユーザー数と、そのページに到着したユーザー数ともイコールではありません。

こういったコンテンツや機能など、サービスの構成要素となるものをオブジェクトと呼びます。
ユーザーが、それぞれのオブジェクトをどれぐらいに接触 / 利用し、かつ、どのオブジェクトを接触 / 利用したユーザーのCVRが高いかを、施策を打つ前に、事実を把握する必要があります。

例えば、skyscannerの検索条件では、「出発地、到着地、時間、人数」などの基本検索条件もあれば、「経由地、出発時刻」などの絞り込み条件もあります。
限られた時間とリソースの中で、どの検索オブジェクトを優先に改善するかは、使うユーザー数と改善余地をバランスを見ながら、判断する必要があります。

f:id:RaNxxx:20190120163847p:plain

具体的にいうと、下記のイメージで優先順位を立てたほうがよいです：

f:id:RaNxxx:20190120164908p:plain

☓となる部分は、最初からプロジェクトのスコープから切り捨てたほうがよいです。
そして、△となる部分は、◎の部分を解決してから、case by caseでどちらを優先するかを決めれば良いです。

念のために、ユーザー数と改善余地が多い少ないかをどう知るかについて少し言及します。
Google AnalyticsやAdobe Analyticsなどアクセスログを簡単に取れるツールが普及している今、ツールからsession数やUU数を集計すれば、施策のターゲットボリュームを簡単に知ることができます。
そして、改善余地というのは、技術の壁をさほど持っていない前提で、その課題に対して考えられる改善すべき箇所の数を意味します。
なんとなく課題意識はあるものの、具体的にどこをどう改善するかをクリアに言えないなら、一旦優先順位を落としても良いでしょう。

このフェーズのゴールは、テストするオブジェクトを絞ることです。
つまり、【WHATを改善するか】を、オブジェクト単位まで明確に決めることです。

AB全体の方向性

AB全体のスコープを上述のように更に絞っていても、具体的にどう進むかの方向性を決めるには、まだまだ絞る必要があります。

この時に、競合比較 / ユーザー調査 / アクセスログを使った深掘り分析を通じて、ABテストの方向性とその方向性を分解できるテーマを決める必要があります。

ここで言っている、「競合比較」は、調査員によるUI/UX調査もありますが、いきなり部分的に入りすぎる恐れがあるため、まずは競合調査ツールであるeMark+やsimilarwebを利用し、定量的に把握したほうが効率的でしょう。

個人的には、eMark+をおすすめします：

eMark+は、無料なアカウントを申請することもできます。そこで、過去一年のPCサイトのuu, session, pv/sessionなどを簡単に調べることができます。
eMark+の月額以外に、更にお金を払えば、CV関連の指標も取れるので、今自社サービスは、競合に比べて、どの指標*1においてネガティブな差*2があるのかをまず調べたほうが効率良いです。

※補足説明：

指標*1：よく使うのは、量的資料（uu, sessionなど）、質的指標（直帰率、スクロール状況、PV/Session、Session/UUなど）、結果指標（予約率、予約単価など）の三種類です。
ネガティブな差*2：競合の数値と比べると、差分はあるものの、自社が優れている指標がある項目もあります。更に強化することもできますが、レガシーのサービスのほど、まずは、劣っている項目から強化したほうが良いでしょう。
ただし、ここで、【劣っている項目】というのは、単純に数値的に競合より高い・低いという話ではなく、なにかのネガティブな理由によって、差が生じるケースを指しています。
例えば、PV/Sessionが競合より多い場合、コンテンツ系のサービスならプラスとしてみなしてOKで、予約系やECサイトなら、サイトの構造（例：同じ量のコンテンツや機能を複数にページに分割する）によって生じるのであれば、ネガティブな可能性があります。
また、ここで、ある指標がどうなったかといって、必ずしもネガティブだと判断することが難しいでしょう。
しかし、プロジェクトのスコープを絞る必要があり、その指標が一体ネガティブかどうかの検証も含め、一定の確度があれば、まず一旦その指標から深掘ってみても良いでしょう。
もちろん、その指標をひたすら上げる・下げるという話でもありません。さっきのPV/Sessionの例だと、流入してからCVまでするのに不可欠なステップがある中、必要なステップ数よりPV/Sessionが下回らないようにする必要があります。

こうやって、競合と定量的に比較することで、テストの方向性につながるなんらかのヒントが隠されていると思います。

例えば、Session/UUが低ければ、再来訪を促す方向性（例：前回訪問の履歴を引き継ぐ機能の投入やプッシュなどの集客機能の活用など）が考えられるし、PV/Sessionが悪ければ、インタラクションコストを削減する方向性（例：オブジェクトを厳選・まとめて表示・アクセスしやすくするなど）が考えられます。

このフェーズのゴールは、決めたオブジェクトに対して、どのような方向性で改善を図っていけばよいかを、具体的な言葉に落とすことです。
つまり、【HOW】を具体的な言葉にすることです。

ただし、ここで気をつけなければいけないのは、HOWのところは、具体的な施策内容やソリューション内容ではないことです。
ユーザーに提供したいUI/UXの理想像を書きましょう。

方向性に沿った施策を図るための指標設計

指標なしにしては評価することもできません。
プロジェクトも、個々のテストも、正しく評価するために、指標の設計が大事でしょう。

自己流ですが、私はABテストの指標を以下４つもレベルで考えています。
※以下は予約やECサイトを前提として考えています。

項目	利用目的	内容（例）	備考
KGI	プロジェクトを貢献を図る・評価する	売上	テストの本数、テストの勝率、テストあたりの売上と分解できる
KPI	テスト内容を本番反映するかしないか	訪問者あたり売上	ABテストの場合、sample数は予め決めているケースが多いため、ここではUU数使って評価しない
subKPI	本番反映には至らないが、施策を磨いてリベンジするかどうか	CVR、予約/購買ごと売上など	UU売上が有意に負けていない前提で subKPIが勝っていれば本番反映もOK
マイクロCV	施策の直接効果を図る・ユーザーインサイトを得る	case by case	ここは単一指標ではなく、複数の指標を立てて、施策ごとに選ぶ

ここは少し補足説明をさせてください。

【KGI】

AB全体の方向性を定める際に、施策の内容以外に、

テスト本数を増やす
本数を一定にするが、勝率を上げる
大きな改善を狙えるよう、テストあたりの売上を向上させる

など、プロジェクトベースの方向性を定めることも必要です。

なぜなら、一定期間において、より少数のメンバー・コストの投入で、より大きな売上を狙ったほうが、プロジェクトも長続きするし、評価も受けるでしょう。

【KPI】

ここでどうしてSessionベースではなく、訪問者あたりの売上（UUベース）を指標とするかは、一定期間における施策の長期的な効果と短期的な効果を両方評価しなければいけないからです。

少し極端の例を挙げると、煽り表現（例：商品残り１件）を使うと、Sessionベースでみた場合、予約率が高いが、ユーザーが急いで予約してしまったゆえに、その後のsessionにキャンセルが多く発生し、結果売上が上がらなかったケースが想定できます。
また、クーポンなどの施策も、結局新たなニーズを生み出せたのか、それとも一部のユーザーのニーズを早めただけなのかも、UUベースで施策を評価すると、より総合的に判断することができます。

ただし、集客を絡めた施策の場合（例：リスティング流入のランディングページのオプティマイズ）、集客コストへの責任もあるので、その場合は、Sessionベースの売上が有意に負けていない、かつUUベースで有意に勝っていればOKでしょう。

【subKPI】

subKPIというのは、KPI指標を分解できる指標のことです。

CVRと予約あたりの売上は、時には片方が勝って片方が負けるケースがあります。

※例えば、ホテルの予約サイトで、「カプセルホテルを除外してから、安い順でホテルをソートし、一番安いホテルを予約したい」ニーズがあります。
「カプセルホテルを除外」というフィルター機能をつけると、カプセルホテル以外の安いホテルを探す効率が圧倒的に上がるため、CVRが上がると想定できますが、予約あたりの売上が下がってしまう恐れがあります。

この時は、片方が勝っていて、そして、KPIである訪問者あたりの売上が有意に負けていなければ、OKと判断することはできます。

【マイクロCV】

ここは具体的な例を持って説明したいです。

例えば、AB全体の方向性は、インタラクションコストの削減と決めた場合、ここで考えられる指標は：