クロスチャネルメジャメントの考え方3 – 測定プラットフォームとしての自社サイト

 

クロスチャネルメジャメントの考え方1 – 基本コンセプト
クロスチャネルメジャメントの考え方2 – ユーザー行動

 

前回、クロスチャネル時代のユーザー行動について見ていき、各施策ごとのKGI/KPI定義の方法まで進みました。今回は、実際にデータを取得する方法を考えます。

各施策のKPIについては、基本的に各施策内の効果測定システムを利用してデータを取得します。それについては、特にここでは説明しません。今回は、各施策のKGIであるコンバージョンへの貢献をどのようにして取得するのかを中心に説明します。「コンバージョンへの貢献」は基本的に自社サイト上での測定プラットフォームで行います。この測定プラットフォームは大きく分けると2つの計測システムと、アクセスログ解析ツールを連動させたものとなります。

 

接触履歴を取得するシステム

1つは各メディアとの接触履歴を取得するシステムとログ解析ツールを連動させることです。もちろん将来的には、ログ解析ツールにビルトインされるようになる可能性もあります。ただ、現状で満足のいく接触履歴を取得できるツールはないので、計測タグのカスタマイズという方法で接触履歴を取得するシステムを構築する必要があります。具体的にはJavaScriptとcookieを用いて、データを保存・収集し、アクセスログ解析サーバーへとデータを送るというプログラムを開発します。

あえて、「接触履歴」という言葉を使ったことには理由があります。これは単なる流入元の分析ではないからです。別の言い方をすると、「流入元」である必要すらありません。マーケティング施策はサイトの「内部」にある場合もあり、また、サイトから誘導する「先」にある場合もあります。それらも含めた各施策とユーザーとの「接触」を履歴として取得していきます。

利用できるデータとしては下記の4つのパターンが考えられます。

  • リファラー情報
  • URLパラメータ(?~)
  • リンククリック
  • URL表示

当然、サイト内での滞在時間やPVなど、あらゆるイベントを接触のトリガーとして考える事もできます。ただ、通常は上記の4つで十分でしょう。

しかし、大きな問題があります。それは、「ログ解析ツールとどのようにして連動させるか」です。基本的には自由に設定できる変数(Googleアナリティクスでいえば、カスタム変数)に接触履歴データを入れることが、もっとも簡単な方法でしょう。ただし、これらの変数は、どのツールも結構厳しい制限があります。Googleアナリティクスはカスタム変数が5つに限定される上に、1個あたり64byteという厳しすぎる制限があります。こういった制限がある以上、すべてのデータを記録しておくことは、ほとんど不可能なため、何らかの犠牲は必要です。何を記録して、何を記録せずに妥協するかは、ユーザー行動の整理ができていれば、決めることはできると思います。例えば、認知系の施策を評価するために、ファーストタッチメディアだけ記録しておくなどが考えられるでしょう。この問題はツールの進化の過程における過渡期的な問題なはずで、おそらくわざわざJavaScriptで開発しなくても、ツールに標準で付いてくる時代がやってくると思います。

ポイントとしては、

「各チャネルの目的に即した形で、各チャネルとの接触を記録すること」

にあります。この接触履歴データと、最終的なコンバージョンのデータを結びつけて、各施策のコンバージョンへの貢献度を評価していきます。

 

オンサイト・サーベイ

2つ目の計測システムは「オンサイト・サーベイ」、いわゆるサイト内アンケートです。サイト内アンケートと、アクセスログ解析ツールを連動させます。

アンケートを利用する目的は3つあります。一つ一つ見ていきます。

検討フェーズの測定

クロスチャネルメジャメントでは、各施策から自社サイトへと誘導することが必要なアプローチとなります。そこでは、それぞれの施策から「どのようなユーザーを連れてこれたのか」が重要となります。下の図にもあるように、検討初期のフェーズにいるユーザーを連れてくるためのメディアと、検討後期のフェーズにいるユーザーを連れてくるためのメディアは明確に異なるように定義しています。


例えば、購買までの検討期間が長い商品で、バナー広告を「認知」のための媒体として定義した場合、バナー広告から来たユーザーの多くが商品を購入することが決定した後であれば、そのバナー広告は「認知」という意味では失敗です。バナー広告のランディング先ページも初めて商品を知った人向けに作ったページであるため、その施策も無意味になってしまいます。

「それぞれの施策が連れてきたユーザーが、検討フェーズのどの段階にいるユーザーなのかを測定すること」

はクロスチャネルメジャメントの重要な要素の1つです。

態度変容の測定

クロスチャネルメジャメントでは、全てのチャネルは「態度変容の場」であると考えます。そういう意味では、全てのメディアは別々の役割を持ったフラットな存在であり、当然、自社サイトも「態度変容の場」の1つです。しかし、自社サイトでは、「Searching」のフェーズにいる顕在化したユーザーに対して施策を行う場であり、態度変容させることの重要性が非常に高い場であります。ユーザーの「行動」で測れる態度変容だけではなく、ユーザーの「意識」上での態度変容まで測ることも重要です。つまり、自社サイトを閲覧してもらうことによって、検討フェーズが上がったのかどうかを、直接ユーザーに尋ねてしまおうというアプローチ方法です。

意識の変容を測定するためには、ある程度ユーザーにサイトを閲覧してもらわなくてはいけません。そのため、サイトへ来た瞬間にアンケートを出すというアプローチでは成立しません。何ページかページを閲覧してもらった後か、数分サイトに滞在してもらったあとに、アンケートを出すという仕組みにする必要があります。

接触履歴の補足

接触履歴は前述のように、基本的にはcookieベースでデータを取得します。しかし、現実的な問題として、すべての接触履歴をトラックすることは不可能です。まず問題となってくるのが、異なるデバイス・異なるブラウザを使った場合でのトラックです。技術的問題、プライバシー上の問題の両面で、デバイス・ブラウザを超えたトラッキングは実質的に不可能です。デバイス・ブラウザを超えて、同じユーザーのトラックを可能にするためには、一度何らかの登録を行なってもらって、会員IDという別の仕組みで紐付けなくてはいけません。基本的にオープンなスペースである多くの自社サイトにとって、全てのユーザーに対して一意のIDを付与することは不可能です。

もう1つ。下記の図を見てみてください。

さりげなく「リアル広告」と「口コミ」に向けて、「測定」の矢印が伸びています。cookieをベースにしたトラックであれば、これらの施策に接触したユーザーが、どれだけサイトに来ていて、コンバージョンまで至ったのかを測定することは、ほぼ不可能です。

では、どうすれば良いか?実際に聞いてみるのが一番です。普通にアンケートで、サイト閲覧前にどの施策に接触したのかを聞いてみれば、問題は全て解決します。当然全てのトラッキングができるわけではないのですが、多くの場合、ユーザーは印象に強く残ったメディアについては、きちんと回答してくれます。

 

オンサイト・サーベイ利用上の課題

オンサイト・サーベイは非常に便利な方法ですが、大きな課題がいくつもあります。

まず、1つ目はサンプルの代表性の問題です。どんなにうまい方法で、アンケートを出すようにしたとしても、アンケートに答えてくれるユーザーが、すべてのユーザーの代表性を保証しているのかどうかという疑問は残ります。極力、公平な形でアンケート画面を出し、回答の負担を少なくすることである程度は、代表性の問題を小さくすることはできます。

2つ目は、1つ目と関連しますが、サンプル数確保の問題です。十分なサンプル数が確保できない場合、サンプルの代表性を担保することはできません。これまでの経験上、アンケートに回答してくれるユーザーは多くて数パーセント程度です。仮に1%だとすると、1,000件のサンプルを集めるためには、100,000の訪問がなければいけません。これだけのユーザーを集めることのできるサイトではないと、アンケートを実施しても意味があまりないでしょう。

3つ目は結果の正確性の問題です。アクセスログ解析によるデータは、有無を言わせない実際にユーザーが取った「行動」の結果です。計測上のエラーは多々起こりますが、基本的には批判のしようがないデータです。しかし、アンケートで取得するデータは、ユーザーが自分で選択した結果です。調査票の設計次第で、ある程度回答をコントロールすることもできます。当然、嘘をつくユーザーも少なからずいます。正確性という点では、行動データには全くかないません。

4つ目はユーザーエクスペリエンス上の問題です。サイトを閲覧している最中にアンケートが出てくることは、少なくとも愉快な経験ではありません。

これらの問題に対する根本的な解決策はないと思いますが、弊害を減らす方法はいくらでもあります。

  • アンケートの出し方を工夫すること
  • 回答の負荷を抑えること
  • サンプル数をできるだけ多く確保すること
  • 調査設計をしっかりすること

などの工夫によって、できるだけアンケートの正確性を確保する努力が必要です。

 

測定プラットフォームとしての自社サイト

まとめると、

自社サイト上で、「接触履歴を取る仕組み」と「アンケートを実施する仕組み」を導入し、それらをアクセス解析ツールと連動させて計測すること

が、クロスチャネルメジャメントの計測ストラテジーのキモとなる部分です。

接触履歴や、アンケートでの回答結果と、コンバージョンを結びつけて、各施策の評価を行います。当然、接触履歴とアンケートの回答結果の紐付けによるデータも重要です。また、アンケートでの回答結果(例えば検討フェーズ)ごとで、どのコンテンツが閲覧されているのかを見ることは今後の改善に大きく役立ちます。

絵空事のように聞こえるかもしれませんが、実は導入実績はいくつもあります。しかし、実際にやってみようとすると、アクセス解析ツール側の都合による障害が想像以上に大きく、かなり無理をした形にせざるをえません。JavaScriptを中心としたWebのテクノロジーと、アクセス解析ツールの仕様を深く理解していないとインプリは難しいでしょう。

以上、かなり長くなりましたが、クロスチャネルメジャメントの考え方について説明してきました。最近、アトリビューション分析を見聞きすることは増えましたが、これは単なるアトリビューション分析とは違います。これまで行なってきていたKGI/KPI設定のフレームワークを拡大したものであって、Webを中心とした施策の効果測定の方法論です。

僕はアトリビューション分析の多くは、広告業界からのポジショニングトークだと思っていますが、このクロスチャネルメジャメントもUXD業界からのポジショニングトークであることには違いがありません(UXDという業界があればですけど)。どうにかして広告の効果を証明しようとする安易なアトリビューション分析と、施策全体でのユーザーエクスペリエンスを計測しようとするクロスチャネルメジャメントは全くことなるものです。(あえて、「安易な」という言葉を使っています。思慮深く考えられたアトリビューション分析は具体的な方法論はどうであれ、基本的な考えはクロスチャネルメジャメントと同じになると思っています)。

今回は、あえて触れていませんですが、探索的なリサーチのアプローチ方法も当然あります。今回、取りあえげた方法は、あくまでも実際に打った施策にたいする効果検証です。効果測定をしながら、いくつも施策を打ち、改善を繰り返していくことで、最適なマーケティング方法に近づけていくという方法です。ユーザーの行動を深く分析することで、探索的に最適なコミュニケーション方法をデータから探していこうという方法とは全く異なります。この探索的なアプローチでは、アトリビューション分析で取り上げられている方法論がよくフィットすると思います。(*これまでの経験上、探索的に何かを探そうとしても何も見つからない、っていうことの方が多かったりもしますが。。。それより、定性調査をやったほうが。。。)

クロスチャネルメジャメントの考え方1 – 基本コンセプト
クロスチャネルメジャメントの考え方2 – ユーザー行動
クロスチャネルメジャメントの考え方3 – 測定プラットフォームとしての自社サイト

クロスチャネルメジャメントの考え方2 – ユーザー行動

前回のエントリ:
クロスチャネルメジャメントの考え方1 – 基本コンセプト

前回のエントリで、「クロスチャネルメジャメントの基本コンセプト」について説明しました。

クロスチャネルメジャメントとは、
「チャネルを横断した施策から自社サイトへとユーザーを集め、セッションを横断して評価することで、マーケティング施策全体のユーザーエクスペリエンスを評価しようとする方法」
であり、具体的には、
「各施策から自社サイトへの流入、自社サイトから各施策への流出を記録し、セッションを横断してトラックする計測手法」
です。
クロスチャネルメジャメントは、ユーザーエクスペリエンスを評価するためのものであるため、まずはユーザー行動を定義する必要があります。今回は、クロスチャネル時代のユーザー行動について、一度整理します。

 

情報収集・探索活動の統合的モデル

ユーザー行動を理解し、施策へと繋げていくためには、ユーザー行動をモデル化することが助けとなります。古くからあるDAGMARやAIDMA、比較的最近のAISASやSIPSなどの消費行動モデルも、ユーザー行動をモデル化したものと考えられます。これらの消費行動モデルを使っても良いのですが、まずは別の視点・もっと高いところから見る視点で考えてみます。
Pervasive Information Architectureでも取り上げられていた「情報収集・探索活動の統合的モデル」(Integrated Model of Information Seeking and Searching)というモデルがあります。これはユーザーの情報収集方法を「Directed(指向的)/Un-directed(非指向的)」、「Active(積極的)/Passive(受動的)」に分けて考え、それらの組み合わせで、ユーザーの情報収集活動を分類しようとするものです。図として表現すると、下のようになります。

Integrated Model of Information Seeking and Searching
http://ptarpp2.uitm.edu.my/silibus/TowardAnIntegratedModel.pdf

まず第1象限(Active/Direct)の「Searching」から見ていきます。これは自ら積極的・自発的に情報を収集し、探す対象のものがおおよそわかっている状態です。検索エンジン上での「検索」や、ECページ、企業ページなどでの情報収集の多くは、「Searching」が当てはまるでしょう。
次に第2象限「Browsing」(Active/Un-directed)ですが、これは自発的に情報を収集しているが、特に探しているものはない状態です。ニュースサイトの閲覧などはこれに当てはまります。
第3象限「Monitoring」(Passive/Directed)は、受動的に何らかの決まった情報を収集している状態です。メールマガジンの購読や、RSSの購読などは、これに含まれます。
最後に第4象限の「Being Aware」(Passive/Un-directed)です。これは、とくに何らかの情報を探してもいない状態で、情報が「入ってくる」状態を指します。友人との会話での話題や、ソーシャルメディア上での会話が、これに含まれると思います。
「Integrated Model of Information Seeking and Searching」の論文によると、最後の「Being Aware」から得る情報が全情報の80%を占めると言われています。これは非常にショッキングな結果です。なぜなら、多くのUXデザイナー(そしてアナリストも!)は「Searching」の行動しか考えていないからです。
よくよく考えてみると、Being Awareから得る情報が多いというのは当然といえば当然で、Web上でさえ、「Browsing」や「Monitoring」で収集する情報のほうが、「Searching」で収集する情報よりも多いことは明白です。ユーザーに情報を届けるという視点で考えると、「Searching」だけを考えていては、全然足りません。4つの象限全てに向けて、最適なコミュニケーションを図らなければなりません。

 

情報収集モデルの適用

この4つの象限による情報収集モデルを、前回作成したクロスチャネルメジャメントの図式に当てはめると下記のようになります。

ユーザーは未検討の状態から、TV広告・口コミ(Being Aware)や、ニュースサイトなどのバナー広告(Browsing)で気づき、「検討フェーズ」に入ります。検索エンジンや比較サイト等で、情報を収集しながら、企業サイトへと訪れ、商品の評価をし、購入します。購入後はソーシャルメディア上で、商品の評価について語り合います(Monitoring)。そのソーシャルメディア上での話題を見た未検討層の人が、その商品の良さに気づきます(Being Aware)。このようにして、ユーザーを取り巻く情報と、ユーザーの検討状況を含めて、ユーザー行動をモデル化します。
当然、全てこのユーザー行動モデルが当てはまるわけではありません。普通にAIDMAやAISASで考えても良いと思います。重要なのは、ユーザーの「検討フェーズ」と「接触メディア(マーケティング施策)」を結びつけて定義することです。これができると、そのメディアで「何をすべきか」が明確になります。

 

クロスチャネルメジャメントにおける顧客育成

ユーザーの検討フェーズと、接触メディア・マーケティング施策を結びつけて考えるという方法は、「顧客を育成する」という考えと一致します。「ナーチャリング」と言ってもいいと思います。「Searching」以外の情報収集は(Being Aware、Browsing、Monitoring)は潜在層に向けたアプローチと考えられます。「Searching」のみニーズが顕在化したユーザーへのアプローチです。これらの情報収集段階に向けたアプローチは、潜在層に向けて何らかの施策を行い、ユーザーを検討フェーズに乗せ、ユーザーを購入へと育成する方法と言えます。
B2B向けマーケティングの文脈で語られることの多い「リードナーチャリング」と近いと考えてもいいと思います。ユーザーの興味や検討フェーズに合わせたコミュニケーションをとって、ユーザーを育成(=態度変容)し、ユーザーを購入へと近づけていくという方法が、このユーザー行動モデルの本質です。

 

Searchingにおける段階

上で、ユーザーの情報収集活動は、「Being Aware」が最も大きく、「Searching」が最も少ないと書きました。それでもやはり、企業にとっては、「Searching」が最も重要な情報収集活動です。なぜなら、「Searching」のユーザーは、既に検討フェーズへと乗ったユーザーだからです。「確度」という観点では、他のユーザーよりも圧倒的に高い確度をもったユーザーだと言えます。検討フェーズへと乗っていただいたユーザーに対して、適切なコミュニケーションを取ることは必須であり、他の施策が様々な都合上、実施できないといしても、これらのユーザーに対するコミュニケーションは実行せねばなりません。
「Searching」の中でも、いくつかの検討フェーズがあります。例えば、「検討中」の段階、「決定後の確認」の段階などが考えられます。これは製品の購買行動モデルによって大きく変わってくるでしょう。ただ、あまり細かくしすぎないことがポイントです。細かく考えようとすると、いくらでも細かく考えられますが、一つ一つのパイが小さくなってしまったり、細かすぎて施策が考えにくくなってしまったり、計測しようにも区別して計測できなくなってしまいます。できるだけシンプルに考えることが重要です。

 

KGIとKPI

ここまで来れば、各施策ごとの目的がはっきりします。どの施策がどの役割を担っており、その施策が果たすべき役割は何なのかが、明確になっているはずです。1つ付け加えるとしたら、それぞれの施策の目的に、「自社サイトを極力絡めるようにする」ということです。当然、優先すべきはユーザーエクスペリエンスですが、自社サイトが計測の中心になっている以上、自社サイトを絡めない限り、計測することができません。プライバシーの問題もあるため、おそらくどんなに技術が進化しても、包括的にデータを取得するには、これしか方法がないと思っています。
それぞれの施策の目的を明確化したあとは、その目的を評価する指標を考えます。基本的な考えは、KGI/KPIの設定に即して考えます。
まずは、施策全体としての評価を考えてみましょう。上記図式の最終的なゴールは「Action」と記されている「コンバージョン」です。全てはコンバージョンを最大化するために、行われている施策です。つまり、施策全体での最終的な評価指標は当然「コンバージョン」となります(それは数であったり、金額であったり、利益高であったりします)。
そして、それぞれの施策はコンバージョン最大化のために行われているため、どの施策も最終的なゴールは自社サイト上でのコンバージョンと結びついていないといけません。よって、すべての評価は「コンバージョン」という軸で共通に評価することができます。
ただ、これはセッションレベルで評価することはできません。なぜなら、それぞれのメディアで役割が異なるからです。「Browsing」や「Being Aware」では、潜在層にアピールすることを目的としているため、検討フェーズが低い人をサイトへ連れてきています。逆に、検討フェーズの低い人を連れてこれていなければ失敗です。よって、これらの施策をセッションベースのCVRやCPAで評価しようとすると、不当に評価が低くなってしまいます。接触履歴を記録して、それぞれの役割に即して評価する必要があります。「認知」が重要な役割のメディアであれば、「ファーストタッチメディア」として機能したかどうかを評価する必要があります。初回訪問に役立ち、最終的にコンバージョンまで到達したのかをトラックして、評価します。この「コンバージョン」を中心とした各施策の評価が、各施策別での「KGI (Key Goal Indicator)」となります。
次に各施策別での評価方法を考えます。それぞれの施策の最終的なゴールは、自社サイト上でのコンバージョンですが、それを達成する手段(=成功要因)は様々です。前回のエントリで書いたように各チャネルは、それぞれ「態度変容の場」です。各施策内で「態度変容が起こっているのかどうか」を評価する必要があります。
バナー広告であれば、「製品・サイトを認知してもらって、クリックしたいと思ってもらう」ことが「達成すべき態度変容」だとすると、まずはクリックしてもらわなくてはならないため、クリック数やCTRが重要な指標となります。これらの各施策の手段を評価する指標を「KPI(Key Performance Indicator)」とし、定期的に評価していきます。

マーケティング施策全体、各施策個別でのユーザー行動が定義でき、目的を設定することができました。その目的に即したKGI/KPIも設定することができました。それでは実際に次回のエントリで、どのようにして、データを取得していくのかを見ていくことにします。

クロスチャネルメジャメントの考え方1 – 基本コンセプト
クロスチャネルメジャメントの考え方2 – ユーザー行動
クロスチャネルメジャメントの考え方3 – 測定プラットフォームとしての自社サイト

クロスチャネルメジャメントの考え方1 – 基本コンセプト

セッションからユーザーへ

前回のエントリの最後に、今後1年間でWebアナリティクス周りにおいて、大きな展開があると書きました。それは、「セッションからユーザーへ」という転回です。

これまで、Webアナリティクスは「セッション」を中心に行われてきました。外部サイト/広告からの流入数も、CVRも基本的には「セッション数」を母数にして算出されます。1回のセッションにおいて、ユーザーがどこから来て、どのように回遊して、コンバージョンへと至ったのか、を分析することがWebアナリティクスの使命でした。なぜ、「ユーザー」ではなく「セッション」が分析の中心となっていのかという理由は、いろいろ考えられますが、大きな所では「解析ツールの技術的要因」と「ユーザーレベル測定の必要性の低さ」が挙げられるでしょう。

しかし、ここ一年ほどの間で、状況は大きく変わってきています。まず、ツールの問題ですが、これはツールに大きな進化があります。Googleアナリティクスはマルチファネルレポートをリリースして、セッションを超えたアトリビューション分析を可能としました。おそらく、ユーザーレベルでの解析は今後どんどん進めていくでしょう。他のツールも同様にユーザーレベルでの分析が拡充していくと思います。

次に必要性の問題ですが、これも状況は大きく変わっています。一つは正確な広告効果測定の必要性です。これまでのCVR, CPAを中心とした分析では刈り取りに適した施策のみ評価されてしまい、それ以外の施策が過小評価されてしまいました。 広告側からの要求も大きいと思いますが、各施策の目的に合わせた分析が求められています。

ユーザーレベルでの分析の必要性という点では、さらに重要なことがあります。 それは複数のチャネル、デバイスを横断した施策がより重要となっているという点です。今や多くのユーザーはスマートフォンを使っています。Facebook、Twitterなどのソーシャルメディアも無視することはできません。今、ビジネスに求められていることは、チャネルを横断したマーケティング施策を実行することです。当然、効果測定も同時に求められます。後で説明することになると思いますが、チャネルを横断するということは、セッションを横断することを意味します。

そこで、本エントリでは、クロスチャネル/クロスセッション時代の効果測定の方法論についての試論をしようと思います。まず、今回は基本コンセプトについて考えてみます。

 

ユーザー行動:クロスチャネルなユーザーの行動

Pervasive Information Architectureという本があります。これはクロスチャネル時代の情報設計について書かれたエポックメイキングな本です。多くのIA系の良書と同様に 哲学的な表現や独特の語彙があるので、全ての人が原書を読むべきとは言いませんが、翻訳本が出てしかるべき本なので、翻訳が出たら、是非一読をお勧めします。

この本の要点を簡単に言うと、チャネルを横断したUX設計、情報設計をしなくてはならない、という点だと思います。これは単なる「クロスメディア」、「クロスデバイス」とは違います。全てのチャネルで一貫した情報構造維持し、最適なコミュニケーションをとることで初めて適切なユーザーエクスペリエンスを提供できるということです。「クロスチャネル」、「クロスメディア」等の違いについては著者らによる下記記事を参照してください。
http://andrearesmini.com/blog/what-is-cross-channel

作り手が望む望まないに関わらず、ユーザーは既に多くのチャネルを横断した行動を取っています。制作側はPCサイトだけ作っていれば良いという時代は終わりました。 あらゆるチャネルを横断したマーケティング施策をしなくてはならない状況になっています。そして、それらの効果測定も当然必要になっていきます。チャネルを跨いだユーザー行動をできるだけ正確に測定する必要があります。

「チャネルを横断すること」、それは「セッションを横断すること」を意味します。次にセッションを横断するユーザー行動を見ていきます。

 

ユーザー行動:クロスセッションなユーザーの行動

ユーザーがWebサイトを利用することは1回限りではありません。最初リスティング広告からサイトへ来て、2日後に自然検索からサイトへ来て会員登録し、その3日後にメルマガ経由でサイトへ来て、コンバージョンする。と、いった行動は普通にあります。

この行動を図式化すると、

リスティング → 自然検索 → メルマガ → CV

となります。

これをセッションベースだけで評価してしまうと、「メルマガ」のみCVでカウントされてしまい、「リスティング」、「自然検索」は評価の対象外となってしまいます。ちゃんと、ファーストタッチメディアとして機能した広告や、「アシスト」した広告も評価してあげましょう。。。というのが、よくある安易なアトリビューション分析の方法です。

これはこれで重要なことです。しかし、「クロスチャネルメジャメント」のアプローチは見方が少し異なります。アトリビューション分析では、「広告」の効果測定という文脈で語られがちですが、「クロスチャネルメジャメント」はあくまでも「ユーザーエクスペリエンスの評価」です。「広告としてCVに貢献したかどうか」ではなく、該当するメディアは「期待したエクスペリエンスを与えることができたのかどうか」を評価します。広告であろうと、ソーシャルメディアであろうと、自社サイトであろうと、すべて意図した「ユーザーエクスペリエンスを提供するための施策」として捉えます(メディアであるとも限りません)。つまり、「あらゆる施策は態度変容の場である」と考えます。

例えば、リスティング広告の目的が「商品を認知してもらい、サイトへと誘導する」のであれば、

「リスティング → 自然検索 → メルマガ → CV」

という行動はリスティング広告が成功したということを意味します。「リスティング広告を閲覧することで、態度変容が起こり、リンクをクリックしてもらった。そして、最終的にはコンバージョンまで到達した。」と考えることができます。これは、リスティング広告の目的と合致します。

評価する対象は、Web上での施策に限定されません。テレビCMや新聞・雑誌広告、店舗でのPOPまで全てを含めたユーザーエクスペリエンスを包括的に設計し、評価していきます。
(クロスチャネル・クロスセッション時代のユーザー行動については、別のエントリで詳しく説明します。)

 

 

自社サイトを測定の中心にする

「クロスチャネル」と「クロスセッション」は別に繋げて考える必要はないのでは?と思う人もいるかもしれません。なぜ、「チャネルを横断することは、セッションを横断することを意味する」のか。それは、自社サイトを「ハブ」として考えるからです。できうる限り、どの施策からも「自社サイト」を経由させるような施策にします。それには、いくつか理由があります。

自社サイトは「刈り取りの場」である

多くの企業にとって、自社サイトは刈り取りの場となっています。ECサイトでは、自社サイトで何かを販売しています。リード獲得系のサイトでは、自社サイトでリードを集めています。メディア系の企業では自社サイトを見てもらうことで、広告収入を得ています。つまり、施策全体での「コンバージョン」が起こる場所は自社サイトであることが多いということです。逆に、施策全体でのコンバージョンを自社サイト内でどうしても定義できない場合は、この「クロスチャネルメジャメント」はうまく機能しません。

自社サイトでは自由に表現することができる

予算や人的リソース、システム上の制限などもありますが、自社サイトでは他のメディアと比較して、圧倒的に高い自由度で施策を打つことができると言えます。もし、サイトに連れてくることさえできれば、あらゆる方法を使って「態度変容」を促すことができます。これはバナー広告、リスティング広告、ソーシャルメディア上での活動では不可能です。これらの媒体では、大きな表現に大きな制限がかけられてしまいます。あらゆるメディアから、態度変容を促すために自社サイトを経由させることは、多くの場合、適切な方法となります。

自社サイトでは自由に計測ができる

そして、計測という文脈で何より重要なことに、自社サイト上ではアクセス解析ツールを中心として、様々な計測が可能となります。各種広告やソーシャルメディア上でも効果測定は可能ですが、やはり計測に制限がつきまといます。自社サイトであれば、技術的・プライバシー的に可能なことであれば、あらゆる計測が可能です。当然、背後にあるCRMや売上データなど、様々なデータとの統合も可能となります。

(自社サイトを中心とした計測方法は別エントリで詳しく説明します)

* ここでいう「自社サイト」とはPC向けのサイトである必要はありません。スマホ向け・フィーチャーホン向けサイトも当然含まれます(フィーチャーホン向けサイトは技術的な制限が大きいので実際は計測が難しいと考えられます)

つまり、「クロスチャネルメジャメント」の方法を簡潔に言うと、

チャネルを横断した施策から自社サイトへとユーザーを集め、セッションを横断して評価することで、マーケティング施策全体のユーザーエクスペリエンスを評価しようとする方法

です。

クロスチャネルメジャメントを図式化すると下のような図になります。

上のグレーのパートは、ユーザーの検討フェーズです。ここでは、(購入)「未検討」から「購買」、「ファン」へと進んでいくように定義しています。

下の「接触チャネル」のパートで、各検討フェーズに即した施策を定義しています。刈り取りの場が自社サイトであるので、どの施策も全て最終的に自社サイトへと誘導します。初期の段階で自社サイトへ誘導する媒体、刈り取りのフェーズで自社サイトへ誘導する媒体があります。逆に自社サイトから誘導する媒体(上の図ではソーシャルメディア)もあります(当然、最終的には自社サイトへと誘導されます)。このようにして、自社サイトを「ハブ」として、各施策をユーザーフェーズごとに定義していきます。

そして、自社サイトへの「行き来」と、「コンバージョン」を全て計測します。これが、クロスチャネルメジャメントの基本的な考え方です。

もう一度、まとめると、

クロスチャネルメジャメントとは、

「チャネルを横断した施策から自社サイトへとユーザーを集め、セッションを横断して評価することで、マーケティング施策全体のユーザーエクスペリエンスを評価しようとする方法」

であり、

具体的には、

「各施策から自社サイトへの流入、自社サイトから各施策への流出を記録し、セッションを横断してトラックする計測手法」

を意味します。

次のエントリから、より具体的な方法について考えます。まず次回は「ユーザー行動」についてさらに詳細に検討します。その次のエントリで、「自社サイトを中心とした計測方法」について詳細を検討します。

クロスチャネルメジャメントの考え方1 – 基本コンセプト
クロスチャネルメジャメントの考え方2 – ユーザー行動
クロスチャネルメジャメントの考え方3 – 測定プラットフォームとしての自社サイト

どのサイトでも利用可能な効果測定指標は可能か

アクセス解析では、初期の段階から「どの指標を見るべきか」という議論はよく行われていました。古くは、「ヒット数からPVへ」、「PVからセッションへ」という議論から、KPI設定についての議論まで、様々な議論がなされてきました。

しかし、時には

  • どのサイトでもこの指標は見ておくべきだ
  • この指標さえ見れば、効果測定ができる

という「共通指標」に関する意見も耳にすることがあります。後者は極端にせよ、前者はわりと普通に言われていることです。例えば、PV/セッション/ユニークユーザーの3つの指標は「基本指標」と呼ばれることも多く、どのサイトでもこれらの指標は見なくてはいけないと真顔で言う人達も少なからずいます。

少し古いですが、2007年にEric Petersonが発表したビジターエンゲージメントを評価する指標は、(いろんな意味で)話題となりました。

http://blog.webanalyticsdemystified.com/weblog/2007/10/how-to-measure-visitor-engagement-redux.html

Ericは、この(複雑で奇怪で滑稽な)数式に指標を当てはめて、サイトへのエンゲージメントを評価する際の共通指標としようというエレガントな考えを発表しました。

最近では、ソーシャルメディア関連で同じような共通指標化への動きが少し見られます。Kloutスコアは既にデファクトスタンダードになっているじゃないか、という意見もあると思いますが、Kloutスコアは、ユーザーの影響力を測るための指標であり、効果測定の指標とは異なります。

ここで、「効果測定」と「ユーザー調査」の違いについて明確化しましょう。「効果測定」とは、何らかのビジネス的な施策に対する評価を測定することです。「ユーザー調査」とは、ターゲットとなるユーザーの意識・行動を明らかに使用とするものです。この2つは同じ「リサーチ」と括られることもありますが、完全に異なる「目的」を持っており、まったく違うものです。

今回は、WebサイトやWebマーケティングにおける「効果測定」において、どのようなサイト・施策でも利用可能な「共通の指標」を作ることは可能なのかを考えます。

効果測定指標策定の方法

まずは、通常、効果測定用の指標を策定する流れを考えます。いわゆるKPI設定の方法です。
いくつかKPI設定の方法はあると思いますが、基本的な考えは共通しています。

1.ビジネスゴールを設定する
Webサイトやマーケティング施策で、達成すべきビジネスゴールを明確に設定します。

2.「成功要因」を特定する
ビジネスゴール達成のために何をすべきかを考え、「成功要因」として洗い出します。

3.KGI/KPIを設定する
ビジネスゴールを直接的に評価する指標を「KGI」とし、成功要因を評価する指標を「KPI」として設定します。

これが通常行われる効果測定用指標策定の方法です。

全てのサイトはユニークである

このようなKPI設定方法を考えると、「共通指標化」は不可能だということが容易にわかると思います。

まず第一に、「ビジネスゴール」が同一であることは、ほとんどありません。それぞれのWebサイトやマーケティング施策によって、ビジネスゴールは異なります。ビジネスゴールが異なれば、当然、KGI/KPIも変わってきます。

仮に、ビジネスゴールが同じだったとしても、実際に取った戦略/戦術(=成功要因)は異なります。同じゴールを目指しても、サイトの作り方であるとか、マーケティング施策の方法は、制作者/マーケターの考えによって変わってきます。同一の施策に落ち着くことは、まず考えられません(パクリでなければ)。

実際、サイトの構成まで他社のサイトをパクったとしても、完全な指標の共通化は難しいでしょう。というのも、企業によって、製品のポジション、組織体・運用体制、予算・事業の重要度、などが異なり、成功要因も大きく変化してしまうからです。

そして、KPI設定において何よりも重要なことは、「合意形成」です。様々なステークホルダーが集まり、この指標を見ることによって評価するという「合意」が取れなければ、KPIとして設定した意味がありません。合意がない状態では、KPIが好転したところで、「だから何?、そんなの知らない」で終わってしまう恐れもあります。

つまり、KPIは事業体に強く依存するものであって、どのサイトでも有効なKPIなど存在するわけがない、と言えます。おそらく、ビジネスゴールはある程度、カテゴライズできるはずで、各カテゴリごとに、KPIの「プロトタイプ」的なものは設定できるでしょう。しかし、実際に適用するには、長い議論と事業に合わせたカスタマイズが不可欠です。

方法論のフレームワーク化

効果測定指標の「共通化」は無理な相談です。サイト・施策によっては、PV/セッションですら、不要な場合も多々あります。ただし、評価方法の方法論・考え方自体は共通化することは可能だと思っています。つまり、フレームワーク化です。

上で挙げたKPIの設定方法もフレームワークの1つと考えることができます。上記のプロセスは、どんなサイト・施策でも有効です。よく言われるPDCAもフレームワークです。ここでは、詳しい説明は控えますが、僕は効果測定周りで、下記のフレームワークをよく利用します(詳しくは、リンク先を参照)。

当然、「フレームワークの共通化」と「測定指標の共通化」は完全に別物です。フレームワークはあくまでも考え方であって、インプリメントは個々の案件に合わせて、行わなければいけません。「考え方の共通化」はできても、「レポートの共通化」はできません。

そして次のステージへ

このブログでは、こんな当たり前の話は、あえてしないようにしていました。もっとマニアックで誰も必要としないようなネタばかり取りあえげてきました。しかし、最近、身近なところから複数の爆弾が降ってきてしまって、「僕は違います」という宣言をした方が良いかなという思いもあり、こんな感じのエントリを書きました。

それと、もう1つ。最近、「KPI設定」の考え方をさらに推し進めたフレームワークを構築する必要性を感じ始めています。今後1年間で、Web Analytics周りで、確実に大きな転回があります。
それは、
「セッションからユーザーへ」
という転回です。

「ヒット数からPVへ」、「PVからセッションへ」という大きな転回と同レベルでの転回が必ず起きます。「セッション」ではなく、「ユーザー」を基本とした測定方法のフレームワーク化が必要になってくると考えています。まだ、具体的な方法論は考えてすらいませんが、今後すぐにでも手をつけなくてはいけないと思っています。

[ga]Googleアナリティクスのキャンペーントラッキングでリファラーまで取る

小ネタです。
どうもGoogleアナリティクスのキャンペーン管理は、よくできているようで、いまいちだったりします。いくつかある不満のうちの1つは、utm_sourceなどのキャンペーンパラメータを使うと、リファラー情報(参照元URL)が取得できないという点が挙げられます。

以前、utm_系のパラメータを短い1つのパラメータで代用する方法 その2という記事で、対処方法の一つのやり方を書きましたが、今回ちょっと別の方法で対処してみます。

方法としては簡単です。
表示されているURLに「utm_source」が含まれていたら、_trackEventを呼び出して、utm_sourceの値とセットで、リファラー情報までイベントとしてデータ取得してしまおうというものです。

■サンプルコード

window.onload = function(){
//キャンペーン時リファラー取得
  var paramReg = /utm_source=[^&]*/;
  if(location.search){
    var utmParam = (location.search).match(paramReg)[0];
    var ref = (document.referrer).replace(/^http(s)?:///, "");
    if(utmParam && ref !=="" ){
      //同一ドメインのリファラーは除外
      var hostName = location.host;
      if(!ref.match(hostName)){
        _gaq.push(['_trackEvent', 'campaignRef', (utmParam.replace(/^utm_source=/, "")), ref]);
      }
    }
  }
}

utm_sourceじゃなくて、utm_contentとセットでデータ取得したいという場合は、3行目と11行目の「utm_source」を「utm_content」に変更すればOKだと思います。
「戻る」ボタンとか使われるとデータが重複して送信されます。なので、指標としては「イベント数」ではなく、「ユニークイベント数」を見るようにしてください。

基本的にキャンペーントラッキングでリファラーを知りたい時は、キャンペーン管理が面倒すぎて、utm_content等でうまくURLとマッチングできる情報を入れられなかった場合か、自動配信系のサービスで、そもそもどこに広告が配信されるか分からない場合かなと思います。
そのような場合は、今回の方法でリファラー情報をサクっと取得しちゃえば良いと思います。「仕様です。」って言って逃げるよりかは。

最適化テストのベストプラクティス

– これまでのエントリ –
A/Bテストの結果をどのように解釈するか?
MVT(多変量テスト: MultiVariate Test)を本当に理解する:Part1
MVTを本当に理解する:Part2 MVTの分析方法
MVTを本当に理解するPart3 : タグチメソッド

4回に渡って最適化テストのデータ分析手法について書いてきましたが、言うまでもなく最適化テストにおいて一番重要なものはテスト設計です。しかし、こう言うこともできるでしょう。

「分析方法を知らずに設計できるわけがない。」

テスト設計をする時には当然、どのように分析するのかを知っておく必要があります。逆に言うと、分析方法がわからないのであれば、その手法は使うべきではないということです。前々回前回のエントリを読んで、何を言っているのか全くわからない、というのであれば、MVTを行うのは止めた方がいいでしょう。自分で計算できないにしても、理屈くらいは抑えておく必要があります。ダメなツールベンダーに乗せられて、タグチメソッドなんて採用したら最悪です(広告代理店もたち悪いですけど)。どうしてもMVTを行う必要があるのであれば、できるだけパターン数を絞った上で、総当り方式のテストを実施すべきです。

今回は、A/Bテスト・MVTのデータ分析方法について理解したという前提で、テスト設計について少し書いていきます。テスト設計は、数学とは違って、コレっていう方法はありません。ただし、おおよそのケースで適用できる大原則のようなものはあると思っています。このような大原則を全部網羅するつもりはないですが、思いついたものをいくつか挙げていこうと思います。

1. それでもやはりA/Bテスト

MVTの有効性は、これまでの記事に書いた通りです。非常に豊富なデータが得られる優れた手法です。しかし、それでもやはり大部分のテストにおいて、A/Bテストの方が望ましいと思います。なぜか。それは「シンプルさ」の一言に尽きます。
「ある事柄を説明するためには、必要以上に多くの実体を仮定するべきでない」
という「オッカムの剃刀」を引くまでもなく、「シンプルさ」に所以する「わかりやすさ」は強力な武器となります。
「わかりやすさ」はチームをドライブします。PDCAを高速化します。逆に、「わかりにくさ」は不信感を産みます。チームを停滞させます。A/Bテストのわかりやすさは、経営層やデザイナーなど、普段分析に携わっていない人にも直感的に理解させることが可能です。PDCAを回すには、彼らにも結果を理解してもらう必要があります。
MVTを利用するのを避けた方が良いというわけではありません。当然、目的によっては、MVTの方が適している場合もあります。大目的で言うと、以下の2つが該当します。

  • ページ内のどの要素がCVに効いているのか知りたい
  • 要素間の交互作用まで考慮したページを作成したい

この2つの目的が無い場合は、わざわざMVTを使う必要はないでしょう。

2.全ては仮説ありき

どのようなテストを行うのかは、仮説を立てた上で検証します。「ボタンが目立っていないのではないだろうか」、「ナビゲーションのテキストがわかりにくいのではないだろうか」などの仮説を立て、オリジナルバージョンと改善バージョンを比べて検証します。
では、どうやって仮説を立てるのか。その第一歩はユーザーを理解することから始まります。ログ分析でザーッとデータを見るだけでは充分とは言えません。「仮説を立てる」という点では、ログ分析は向いている手法とは言えません。可能であれば、何らかの定性調査を行なった方が良いでしょう。単純に身近にいるユーザーに話を聞くだけでも全然違います。
最後にものを言うのは直感です。これまでの経験とユーザー理解、そしてインスピレーション。これらに基づいた直感こそが最終的に優れた仮説を作り出します。データは万能ではありません。ここでは、ユーザー理解の手助けになるくらいにしか役立たないでしょう。

3.ターゲティングとセグメンテーション

ここで言うターゲティングには2段階あります。

  • A.できるだけ公平な実験環境を作るためのターゲティング
  • B.より効率的にCVRを上げるためのセグメント別での出し分け

「A」のターゲティングでは、あくまでもより正確なデータを得るためにターゲティングするのに対して、「B」のターゲティングはより効果を上げるために実施するターゲティングです。
まず、「A」から見ていきます。

A.できるだけ公平な実験環境を作るためのターゲティング

「実験」を行う上では、対象以外の要因はできるだけ同一にすべきと考えます。つまり出来る限り、実験に関係のない要因は除外すべきということです。実際、最適化テストを行う上でどのような外部要因が考えられるかというと、

  • 新規ユーザーと再訪問ユーザー
  • 平日と休日、季節要因
  • キャンペーンや広告などサイト内外での施策

などなど、非常に多くの要因が考えられます。ただし、考え出したらキリが無いので、どこかで割り切りも必要です。再訪問ユーザーは前回アクセス時の印象が影響してしまうため、理想的には除外すべきで、新規ユーザーだけに対してテストを行うべきです。ただ、そこまで厳密にする必要があるかどうかは微妙です。かかる工数ほどの価値はないかもしれません。大きなキャンペーンを行っている時期は避けた方が無難だとは思いますが、それ以外はさほど気にしなくても良いような気がします。

B.より効率的にCVRを上げるためのセグメント別での出し分け

これは「ユーザー行動は特定のセグメントによって異なる」という仮説に基づいています。例えば、ある特定のキーワードでランディングした人に対して、「通常のクリエイティブ」と「キーワードの内容に則したクリエイティブ」の2パターンでテストを行うといった手法です。リコメンデーションに近い考え方です。
検索キーワードの他にも、出稿広告や参照元サイトなどの「外部サイト施策」、ランディングページ・サイト滞在時間などの「サイト内行動」、PC環境や地理データ、過去に入力した個人情報や購入履歴などの「ユーザー属性」などでターゲティングを行います。これらのターゲティングを行うことで、当然テスト設計は複雑になりますが、かなりの効果が期待できます。
(GWOがダメなのは、タグチメソッドを提供していないからではなく、ターゲティング機能を提供していないからです。JSだけでやろうとすると、中々難しいのはわかりますが)

4.コンバージョンに影響のある箇所をテストする

コンバージョンに対して、何も影響を与えない箇所でテストをやっても何の意味もありません。コンバージョンに影響を与える箇所を重点的に改善するようにしましょう(「コンバージョンに影響する要素」について、まとまった記事を昔見た記憶があるのですが、見つからないです。手元にコピーしたものはあるんですけど、そのまま載せるのもどうかと思うので止めときます)。
もし、コンバージョンに影響する箇所が、どこかわからないという場合は、MVTを実施して、影響の大きい箇所を特定するのも一つの手かと思います。

最後は常識的な話だけになってしまいましたが、最適化テストシリーズ5連作は終了します。ネタと余裕があれば、続きを書くこともあるかもしれないですけど、たぶん書かないと思います。きっと。

MVTを本当に理解する Part3 : タグチメソッドについて

タグチメソッド?

「数パターンのテストを行うだけで、数十パターンのテストを行なった時と同等の結果を得られる魔法の手法、それがタグチメソッド!」

MVTツール界隈では、このような無責任な記述が散見されます。全否定したいわけではないですが、タグチメソッドは、少なくとも魔法のツールではありません。品質管理の分野で広く使われている手法です。
MVTで利用される「タグチメソッド」と呼ばれる手法は、「タグチメソッド」の一部である「直交表を利用した実験計画法」のみを指しています。タグチメソッドはどちらかというと、SN比を上げバラツキを抑えることに重点が置かれており、その点はMVTには全く関係ありません。
実は、「直交表を利用した実験計画法」はマーケティングリサーチの世界でも頻繁に利用されています。マーケティングリサーチでは「コンジョイント分析」と呼ばれる手法です。MVTで利用されるテストパターン削減の方法という意味では、コンジョイント分析の方が、タグチメソッドよりも近いと思います。

タグチメソッドは高いツールでしか使えない?

無料で利用できるGWOや、安価なLPOツールではタグチメソッド的な方法を提供していません。だからといって、タグチメソッド的なテストができないというわけではありません。上に書いたように、タグチメソッドと呼ばれるMVT手法は単に直交表を利用した実験計画法でしかありません。直交表を利用して、実験を計画すればいいのです。

まずは、直交表を用意します。Googleで「直交表」と検索すれば、いくつか見つかるはずです。プロラムで作ることもできると思いますが、ちょっと難しいようなので、Webから拾ってくればいいと思います。

直交表には「2水準系」、「3水準系」、「混合型」などがあります。2水準はテストのパターン数が2つの場合(A or B)、3水準は3つ、混合型は2つと3つが両方含まれているものです。
前回取り上げた総当り方式のMVTでは2水準しか扱っていなかったので、今回は3水準の「L9直交表」を利用しましょう。
*本来のタグチメソッドでは、L12、L18、L36が使われるようです。特にL18が推奨されています。

L9直交表は以下のようなものです。

L9 A B C D
テスト1 1 1 1 1
テスト2 1 2 2 2
テスト3 1 3 3 3
テスト4 2 1 2 3
テスト5 2 2 3 1
テスト6 2 3 1 2
テスト7 3 1 3 2
テスト8 3 2 1 3
テスト9 3 3 2 1

L9直交表では、A、B、C、Dの4つのパラメータに対して、それぞれ3つずつのテストを行います。
総当り方式でのテストパターン数は
3 * 3 * 3 * 3 = 81パターン です。
これが、9パターンのテストのみで実現できます。

テストの方法も別に難しくはありません。直交表に書かれているようにテストパターンを準備すればOKです。
例えば、テスト1では、A、B、C、Dで全て1つ目のパターンを用意。テスト2では、Aのみ1つ目のパターンで、B、C、Dは2つ目のパターン。という具合に9つのパターンを用意して、テストを行えばOKです。
自分で直交表さえ用意してしまえば、おそらくどんなツールでもタグチメソッドを実施することができます。あえて、高いツールを使う必要はありません。

分析とデータ解釈の方法

分析方法は、総当り方式で行なった方法と同じです。
CVRは以下の表と考えます。

L9 A B C D CVR
パターン1 1 1 1 1 0.06
パターン2 1 2 2 2 0.06
パターン3 1 3 3 3 0.07
パターン4 2 1 2 3 0.05
パターン5 2 2 3 1 0.04
パターン6 2 3 1 2 0.03
パターン7 3 1 3 2 0.03
パターン8 3 2 1 3 0.05
パターン9 3 3 2 1 0.03

総当り方式のところで行なったように、ダミー変数を用いて集計用の表を作成します。今回は全て3水準ですので、全ての項目で1つ列を消します(消した列が基準値となります)。

L9 a1 a2 b1 b2 c1 c2 d1 d2 CVR
パターン1 1 0 1 0 1 0 1 0 0.06
パターン2 1 0 0 1 0 1 0 1 0.06
パターン3 1 0 0 0 0 0 0 0 0.07
パターン4 0 1 1 0 0 1 0 0 0.05
パターン5 0 1 0 1 0 0 1 0 0.04
パターン6 0 1 0 0 1 0 0 1 0.03
パターン7 0 0 1 0 0 0 0 1 0.03
パターン8 0 0 0 1 1 0 0 0 0.05
パターン9 0 0 0 0 0 1 1 0 0.03

次に、このデータを用いて重回帰分析を行います。
(Rで計算)

> data <- read.delim("clipboard")
> data
  a1 a2 b1 b2 c1 c2 d1 d2  CVR
1  1  0  1  0  1  0  1  0 0.06
2  1  0  0  1  0  1  0  1 0.06
3  1  0  0  0  0  0  0  0 0.07
4  0  1  1  0  0  1  0  0 0.05
5  0  1  0  1  0  0  1  0 0.04
6  0  1  0  0  1  0  0  1 0.03
7  0  0  1  0  0  0  0  1 0.03
8  0  0  0  1  1  0  0  0 0.05
9  0  0  0  0  0  1  1  0 0.03
> res <- lm(CVR~., data=data)
> summary(res)

Call:
lm(formula = CVR ~ ., data = data)

Residuals:
ALL 9 residuals are 0: no residual degrees of freedom!

Coefficients:
              Estimate Std. Error t value Pr(>|t|)
(Intercept)  4.333e-02         NA      NA       NA
a1           2.667e-02         NA      NA       NA
a2           3.333e-03         NA      NA       NA
b1           3.333e-03         NA      NA       NA
b2           6.667e-03         NA      NA       NA
c1          -6.758e-18         NA      NA       NA
c2          -1.804e-18         NA      NA       NA
d1          -1.333e-02         NA      NA       NA
d2          -1.667e-02         NA      NA       NA

Residual standard error: NaN on 0 degrees of freedom
Multiple R-squared:     1,      Adjusted R-squared:   NaN
F-statistic:   NaN on 8 and 0 DF,  p-value: NA

偏回帰係数をまとめると、以下の表になります。
各パラメータのパターン3は基準値ですので、値は「0」となります。

A B C D
パターン1 0.0267 0.0033 -0.0000 -0.0133
パターン2 0.0033 0.0067 -0.0000 -0.0167
パターン3 0 0 0 0

わかりにくいので、グラフ化してみましょう。

このグラフの解釈方法ですが、まず、それぞれのパラメータの傾きを見ます。傾きが大きいものが影響力が大きいと考えられます。A(a1,a2,a3)は傾きが非常に大きいです。これはa1、a2、a3間で差が大きいことを意味します。つまり、このパラメータを変更すると、CVに対する影響が大きいと考えられます。「D」も「A」ほどではないですが、傾きが大きいです。CVに対する影響力はある程度大きいと言えます。
「B」と「C」については傾きが小さいです。つまり、パターンを変えても大きな違いがないということを意味しています。

次に、各パラメータで最も偏回帰係数が高いパターンを抽出します。
ここでは、「a1、b2、c3、d3」が、それぞれ最も偏回帰係数が大きいものです(c3は微妙ですが、数値が高くなっています)。偏回帰係数が高いということは、CVに与える影響が大きいということなので、最も効果が高いものといえます。
よって、

最適なテストパターンの組み合わせは、「a1、b2、c3、d3」

となります。実際、このパターンでのテストは行っていませんが、計算すると、このパターンで実施するのがベストだと結果になります。
これが、タグチメソッド的なテスト手法です。

*前回も少し書きましたが、本来のタグチメソッドでは数量化I類ではなく、分散分析を行います。ただ、今回はMVTの結果データが「0/1」であることと、簡略化のため、数量化I類を採用しています。

タグチメソッド的手法の重大な欠点

少ないテストで、最適なテストパターンの組み合わせがわかるなんて素晴らしい手法です。しかし、ここに落とし穴があります。

前のエントリで書いたMVTでわかることの3つを思い出してみましょう。

  • どのパターンのCVRが高いのか
  • どの要素(パラメータ)がCVRに影響を与えているのか
  • 要素間の交互作用はどれくらい強いのか

まだ3つ目の「要素間の交互作用はどれくらい強いのか」を算出してみませんでした。算出してみましょう。。。。実はできません。なぜなら、この実験設計に交互作用を考慮に入れていないからです。総当り方式の場合、全ての種類のテストを行っているため、いくらでも交互作用を計算することができます。しかし、直交表を用いた場合、事前に設計した組み合わせの分でしか計算することができません。
つまり、タグチメソッド的手法を使うと、3つ目の「要素間の交互作用」を算出することができなくなります。それだけなら、まだ良いのですが、「要素間の交互作用が無い」ことを「前提」としています。「要素間の交互作用」があっては、モデルとして成り立たなくなり、「a1、b2、c3、d3」が最適な組み合わせだと言うことができなくなります。

MVTでは通常1ページ内に、いくつかのパラメータを用意して、各パラメータごとにパターンを用意します。このように、「1ページ内」に置いた場合、「要素間の交互作用が無い」ということが考えられるでしょうか?ページデザインで、各パラメータが独立に存在していることなど、通常は考えられません。トータルとして印象を受取ります。「要素間の交互作用が無い」という前提には無理があります。

*注:
ちなみに、本来のタグチメソッドでは、交互作用がないことを「条件」としています。交互作用があると、工業品として不適格だという考えです。だからといって、交互作用を算出することができないわけではありません。(タグチメソッドではない)実験計画法では直交表に交互作用を割り付けることで交互作用を算出するようにしています。ただし、特に3水準以上になると、交互作用の割り付けも一筋縄ではいかず、非常に難しくなります。例えば、今回のモデルでの交互作用を考えてみると、
a1との2水準の交互作用だけでも、
「a1b1」、「a1b2」、「a1b3」、「a1c1」、「a1c2」、「a1c2」
の6種類あります。これが「a2」「a3」の組み合わせもあり、さらに「a1b1c1」などの3水準もあり、、、、と考えてみると、相当数の交互作用を考慮しなくてはいけなくなります。(組み合わせを計算で出すことができると思いますけど、自信ないので止めときます)
交互作用を考慮に入れて設計するのは、非常に難しく、交互作用を考慮に入れると、結局テストパターンが減ることになるので、直交表を使うメリットも減少します。

それでもタグチメソッドを使いますか?

これが安易にタグチメソッドを使うべきではないという理由です。
たしかに、わずか9パターンのテストで、81パターン分のテストができる優れた手法です。しかし、

「交互作用がないって本当に言い切れますか?」
「そもそも、81パターンものテストをする必要が本当にありますか?」

この点を理解せずに安易にタグチメソッドを用いると、誤ったテスト結果が出てくることになります。
総当り方式のテストを行なった場合、検定さえしっかり行えば、誤った結果が出ることはありません。しかし、タグチメソッド的な手法を使うと、交互作用がある場合、誤った結果が出てきます。MVTを行う場合、交互作用が無いことは通常考えにくいです。であれば、タグチメソッドは、ほぼ確実に誤った結果を算出します。そして、パラメータ間の交互作用について説明をしているツールベンダーは知っている限り一つもありません。ツールの謳い文句に乗って、安易にタグチメソッドを使うと痛い目にあうので気を付けた方が良いと思います。

タグチメソッド的手法が何故まずいのかについては、SiteTunersのTim Ashがもっと詳しく説明しています。ホワイトペーパーを無料でダウンロードすることができるので、時間があれば読んでおくと良いと思います(登録が必要です)。
(僕は彼ほど全否定するつもりはありませんが、、、)

“The Truth About Taguchi: Why Fractional Factorial Multivariate testing is Wrong for Landing Page Optimization” Whitepaper

追記:
ノンパラメトリックな手法であれば、交互作用の問題もあんまり無いと思います。

MVTを本当に理解する:Part2 MVTの分析方法

MVTの結果を分析する

前回、総当り方式MVT(多変量テスト:Multivariate Test)のテスト結果の解釈方法について書きました。しかし、前回のものは、あくまでも結果の解釈方法であって、結果の分析ではありません。MVTをさらに深く分析すると、もっと多くの情報を得ることができます。
前回同様、今回も3つの変動箇所(パラメータ)に対して、2つずつのパターンを準備したテストについて考えます。今回は結果がわかりやすいように、少し恣意的なデータを用意しました。
以下の表は各パターンの組み合わせとCVRをまとめたものです。
サンプル数は全て1,000とします。

パターン名 組み合わせ CVR
パターン1 a1b1c1 11.8%
パターン2 a1b1c2 6.0%
パターン3 a1b2c1 7.4%
パターン4 a1b2c2 3.0%
パターン5 a2b1c1 7.6%
パターン6 a2b1c2 2.9%
パターン7 a2b2c1 6.1%
パターン8 a2b2c2 0.9%

各パラメータを分解してみる

まず、それぞれのパターンでの区間推定をしてみます。

パターン名 下限 CVR 上限
パターン1 9.80% 11.80% 13.80%
パターン2 4.53% 6.00% 7.47%
パターン3 5.78% 7.40% 9.02%
パターン4 1.94% 3.00% 4.06%
パターン5 5.96% 7.60% 9.24%
パターン6 1.86% 2.90% 3.94%
パターン7 4.62% 6.10% 7.58%
パターン8 0.31% 0.90% 1.49%

パターン1のCVRが他よりも高く、有意な差がありあそうです。これで終わっても良いのですが、さらに分析を進めます。
まず、各パターンをパラメータごとに分解してみます。すると、各パラメータ内での平均値は下記表のようになります。

A B C
1 7.05% 7.08% 8.23%
2 4.38% 4.35% 3.20%

これも区間推定を出してみましょう。この場合、それぞれ4種類のパターンをまとめているので、サンプル数は4,000です。

下限 CVR(平均) 上限
a1 6.55% 7.05% 7.55%
a2 3.97% 4.38% 4.78%
b1 6.57% 7.08% 7.58%
b2 3.95% 4.35% 4.75%
c1 7.69% 8.23% 8.76%
c2 2.86% 3.20% 3.54%

A、B、Cいずれも「1」パターンの方が高く、有意な差がありそうです。この表からもパターン1「a1b1c1」が最も効果のある組み合わせだということが言えるでしょう。
詳しい人は既にわかっていると思いますが、MVTはいわゆる「実験計画法」と呼ばれる統計手法の一種と考えられます。実験計画法の手法を使って、さらに深い分析を行うことができます。

どのパラメータがCVに影響を及ぼしているのか

実は、このデータからコンバージョンに対して影響を与えているパラメータは何か特定させることができます。ここでは、「数量化I類」という手法を利用します。

*注:
通常の実験計画法では、ここから「分散分析」を行います。ただ、MVTの場合、結果を示すデータが「CVしたか」、「CVしないか」の「0/1」データ(離散型)となり、正規分布を前提とすることができません。ロジットモデルなどの複雑な分析が必要になってしまうので、ここでは簡易的な分析手法である数量化I類を採用することにします。

上のデータの組み合わせをアリ/ナシの「0」か「1」に置き換えると、以下の表を作成することができます。

a1 a2 b1 b2 c1 c2 cvr
パターン1 1 0 1 0 1 0 11.8%
パターン2 1 0 1 0 0 1 6.0%
パターン3 1 0 0 1 1 0 7.4%
パターン4 1 0 0 1 0 1 3.0%
パターン5 0 1 1 0 1 0 7.6%
パターン6 0 1 1 0 0 1 2.9%
パターン7 0 1 0 1 1 0 6.1%
パターン8 0 1 0 1 0 1 0.9%

ここで、よく考えてみます。
1.CVRはテストパターンによって大きく異なります。
2.各パラメータがコンバージョンに対する影響要因として考えることができそうです。
3.各パラメータの影響力に「誤差」を加えたもので、CVRを導くことができそうです。
4.つまり、各パラメータを「a,b,c」として、それぞれの影響度を「x1,x2,x3」、誤差をEとおくと、
CVR = x1*a+x2*b+x3*c+E
が成立します。
5.パターンが8個あるので、なんとか各影響度を算出することができそうです。

要は重回帰分析のモデルに当てはまることができるということです。
ただ、少しだけ注意が必要です。各パラメータは2つのパターンを持っていて、それぞれ完全に独立しています。例えば、a1パターンではないとき、必ずa2パターンとなります。上の表における、a1の列とa2の列は反対になっているだけで同義のものです。なので、重回帰分析を行うときには片方を除外しなくては計算ができません。1つのパラメータ内に3パターンある場合は1パターンが除外されます。
よって、上の表は以下のように表すことができます。

a1 b1 c1 cvr
パターン1 1 1 1 11.8%
パターン2 1 1 0 6.0%
パターン3 1 0 1 7.4%
パターン4 1 0 0 3.0%
パターン5 0 1 1 7.6%
パターン6 0 1 0 2.9%
パターン7 0 0 1 6.1%
パターン8 0 0 0 0.9%

これで普通に重回帰分析を行います(Rを使用)。

#利用するデータです。
> data
  a1 b1 c1   cvr
1  1  1  1 0.118
2  1  1  0 0.060
3  1  0  1 0.074
4  1  0  0 0.030
5  0  1  1 0.076
6  0  1  0 0.029
7  0  0  1 0.061
8  0  0  0 0.009

#線形回帰を行います。
> res <- lm(cvr~., data=data)
> summary(res)

Call:
lm(formula = cvr ~ ., data = data)

Residuals:
       1        2        3        4        5        6        7        8
 0.00875  0.00100 -0.00800 -0.00175 -0.00650 -0.00325  0.00575  0.00400

Coefficients:
            Estimate Std. Error t value Pr(>|t|)
(Intercept) 0.005000   0.005551   0.901 0.418649
a1          0.026750   0.005551   4.819 0.008529 **
b1          0.027250   0.005551   4.909 0.007992 **
c1          0.050250   0.005551   9.053 0.000825 ***
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 0.00785 on 4 degrees of freedom
Multiple R-squared:  0.97,      Adjusted R-squared: 0.9475
F-statistic: 43.09 on 3 and 4 DF,  p-value: 0.001672

R^2が0.97と、ちょっとやりすぎたくらいビッタリはまったデータになっています。
各パラメータの影響度はCoefficients(偏回帰係数)で見ることができます。

a1 : 0.027
b1 : 0.027
c1 : 0.050

全ての偏回帰係数がプラスになっているので、a,b,cいずれも「1」の方が効果がCVRに対して貢献していると言えます。「2」の方が貢献している場合はマイナスになります。
a1, b1, c1を比較すると、c1が大きな値となっています。つまり、「c」のパラメータがCVRに対して、高い影響力を持っていると解釈することができます。
そのため、効率的にCVRを上げるためには、「c」の部分を優先的に考えた方が良いと言うことができます。

*注:
ここでは簡略化して通常の線形回帰を行いましたが、集計済みの「CVR」を被説明変数として使うのではなく、集計前の「CVしたかどうか」を被説明変数として使うほうが望ましいと思います。「CVしたかどうか」は「0/1」のデータになるので、線形回帰ではなく、ロジスティック回帰を利用します。ツール化する場合などは、ベイジアンフィルタのような機械学習で、都度都度、影響度を更新していくような手法の方が良いと思います。

それぞれの交互作用を知る

これまでは、各要素「a1,a2」、「b1,b2」、「c1,c2」は互いに独立して存在していることを仮定していました。どういうことかというと、各要素間に関連性が無いということを前提としています。
この前提を変更してみて、各要素間で影響を与え合っていると考えてみます。
「a1」、「b1」、「c1」は同じコンセプトのデザインを採用していると考えてみましょう。「a2」、「b2」、「c2」はバラバラのデザインです。であれば、「a1とb1の組み合わせ」、「a1とc1の組み合わせ」、「a1とc1の組み合わせ」は同時に行うことで効果を発揮しているのではないかと考えることもできます。「a1b1」、「a1c1」、「b1c1」の組み合わせに該当する結果を抜き出して、CVRの平均を出してみます。

CVR(平均)
a1b1 8.90%
a1c1 9.60%
b1c1 9.70%

先ほどの結果では、「C」が大きな影響力を持っていたので、c1を含む項目が高い数値になるはずですが、c1を含まない「a1b1」もそれほど大きな違いはありません。もしかすると、「a1b1」の組み合わせがプラスの効果を生んでいるかもしれません。

先ほどと同様に、数量化I類で分析してみます。各要素間の組み合わせも、要素内のパターンと同様に、「0」と「1」で表すことができます。
上のデータに3つの組み合わせを追加したものが下の表です。

a1 b1 c1 a1b1 a1c1 b1c1 cvr
パターン1 1 1 1 1 1 1 11.8%
パターン2 1 1 0 1 0 0 6.0%
パターン3 1 0 1 0 1 0 7.4%
パターン4 1 0 0 0 0 0 3.0%
パターン5 0 1 1 0 0 1 7.6%
パターン6 0 1 0 0 0 0 2.9%
パターン7 0 0 1 0 0 0 6.1%
パターン8 0 0 0 0 0 0 0.9%

このデータを基に重回帰分析を行います。

> data
  a1 b1 c1 a1b1 a1c1 b1c1   cvr
1  1  1  1    1    1    1 0.118
2  1  1  0    1    0    0 0.060
3  1  0  1    0    1    0 0.074
4  1  0  0    0    0    0 0.030
5  0  1  1    0    0    1 0.076
6  0  1  0    0    0    0 0.029
7  0  0  1    0    0    0 0.061
8  0  0  0    0    0    0 0.009
> res <- lm(cvr~., data=data)
> summary(res)

Call:
lm(formula = cvr ~ ., data = data)

Residuals:
        1         2         3         4         5         6         7         8
 0.002375 -0.002375 -0.002375  0.002375 -0.002375  0.002375  0.002375 -0.002375

Coefficients:
            Estimate Std. Error t value Pr(>|t|)
(Intercept) 0.011375   0.006284   1.810    0.321
a1          0.016250   0.008227   1.975    0.298
b1          0.015250   0.008227   1.854    0.315
c1          0.047250   0.008227   5.743    0.110
a1b1        0.019500   0.009500   2.053    0.289
a1c1        0.001500   0.009500   0.158    0.900
b1c1        0.004500   0.009500   0.474    0.718

Residual standard error: 0.006718 on 1 degrees of freedom
Multiple R-squared: 0.9945,     Adjusted R-squared: 0.9615
F-statistic: 30.17 on 6 and 1 DF,  p-value: 0.1385

影響力を示す偏回帰係数は
a1 : 0.01625
b1 : 0.01525
c1 : 0.04725
a1b1 : 0.0195
a1c1 : 0.0015
b1c1 : 0.0045

となります。当然結果は、これまでと同様、「c」の影響力が強いということには、変わりありませんが、「a1b1」の組み合わせも「0.0195」あり、「b」、「c」よりも大きな影響力を持っています(残りの2つの組み合わせの影響力は弱い)。
どういうことかというと、「a1」と「b1」を組み合わせると、スペシャルボーナスとしてCVRが上昇するということです。なので、この2つは同時に表示させることで、より大きな効果が上げられると言えます。
全部の組み合わせについて調べることもできますが、キリがないので、これくらいでやめておいたほうが無難だと思います。
このような組み合わせによる効果を実験計画法では、「交互作用」と呼びます。実はこの「交互作用」こそ重要で、無視できない要因です。これはまた次回書きます。

MVTから何がわかるのか?

まとめると、MVTを分析してわかることは以下の3点です。

  • どのパターンのCVRが高いのか
  • どの要素(パラメータ)がCVRに強い影響を与えているのか
  • 要素間の交互作用はどれくらい強いのか

MVTを実施するには、この3つを抑えておかないと、やる意味が全くありません、とまでは言わないですがもったいないです。ここまで分析して初めてMVTを実施する価値がでます。MVTは単にまとめてテストを行うために実施するのではありません。この3つのデータを得るために行うものです。

ただ、これまでの分析を否定するような言い方になりますが、総当り方式の長所の一つは、このような複雑な分析をしなくても、結果だけで全て判断できるということもあります。今回のテストで言うと、何も考えずとも「パターン1」が最適な組み合わせだということができます。ちゃんと検定さえすれば、結果を見誤ることはありません。しかし、タグチメソッドを使うと、これが簡単に言えなくなってしまいます。
次回、タグチメソッドについて書くことにします。

MVT(多変量テスト: MultiVariate Test)を本当に理解する:Part1

MVT(多変量テスト)とは?

A/BテストよりもMVTの方が一度にたくさんテストできるから、楽でいいじゃん。タグチメソッド使えばテスト回数も抑えられるし。みたいな話を時々、見聞きしますが、これはかなり危険です。「ツールにお任せ」に慣れきってしまっていて、思考能力が減衰しています。MVTはA/Bテストと比較してメリットは多々ありますが、解釈が難しく、しかも間違いやすいという欠陥があります。特にいわゆるタグチメソッドを用いると、危険性は急激に増加します。もちろん、正しく使えば有効な手法です。簡単ではないですが、MVTの基礎から正確に理解して使用するようにしましょう。それをしたくないのであれば、素直にA/Bテストを行なった方が良いと思います。

MVTの定義

A/Bテストは1対1のテストで、MVTは一度にたくさんテストをする。その通りです。シンプルです。ただ、MVTの定義が結構曖昧なので、ここではっきりさせておきます。
MVTはその名前の通り「多変量」でのテストです。つまり一回のテストでパラメータとなる変数が複数あることを示します。
例えば、1ページ内に3つ要素(=パラメータ)があり、その3つが各2パターンずつ切り替わる場合、MVTと呼びます。

これに対して、1ページ内に要素が1つで、それが3パターンある場合は、パラメータは1つのみなので、MVTとは呼ばないことにします。A/Bテストの1種(A/B/Cテスト?)と考えた方が適切です。

後者のパターンもMVTと呼ぶ場合がありますが、あまり適切ではないので、ここではMVTとは言わないようにします。

総当り方式について考える

「タグチメソッド」の話は後回しにして、まず総当り方式のMVTを考えます。ちなみに、別途書きますが、「タグチメソッド」は安易に用いるべきではないと考えています。あの統計の鬼のような企業であるGoogleが提供するGWO(Google Website Optimizer)で、なぜタグチメソッドを提供していないのか、を考えてみる必要があります。

さて、総当り方式の場合、テストパターンはシンプルです。要素が3つあり、各2パターンずつ変化させるというテストについて考えます。テストパターンは
2*2*2 = 8 パターン
のテストが行われることになります。
各組み合わせは以下の通りです。

I II III
パターン1 I-a II-a III-a
パターン2 I-a II-a III-b
パターン3 I-a II-b III-a
パターン4 I-a II-b III-b
パターン5 I-b II-a III-a
パターン6 I-b II-a III-b
パターン7 I-b II-b III-a
パターン8 I-b II-b III-b

だいぶ面倒になってきました。
テスト結果は以下のようになりました。

インプレッション CV回数 CVR
パターン1 1,000 37 3.7%
パターン2 1,000 29 2.9%
パターン3 1,000 98 9.8%
パターン4 1,000 89 8.9%
パターン5 1,000 100 10.0%
パターン6 1,000 88 8.8%
パターン7 1,000 97 9.7%
パターン8 1,000 51 5.1%

「テストパターン5」がCVR10%で一番良かった。テスト終了。よかったです。
とはなりません。
当然検定が必要になります。ただし、1対1の場合と異なって検定には注意が必要です。
カイ二乗検定を行ってみます。

> d
   CV notCV
1  37   963
2  29   971
3  98   902
4  89   911
5 100   900
6  88   912
7  97   903
8  51   949
> chisq.test(d)

        Pearson's Chi-squared test

data:  d
X-squared = 89.7871, df = 7, p-value < 2.2e-16

P値は「2.2e-16」と、ものすごい小さい値になりました。よって、違いがあると認められます。。。。。
何と何が違いがある??????
カイ二乗検定では、どのデータと、どのデータに違いがあるのかは判別することができません(残差分析を行うことによって、簡略的に推定することはできますが、ここでは省きます。残差分析はアンケート分析で良く利用されます)。カイ二乗検定で検定できるのは、あくまでも観測されたデータで違いがあるかどうかです。

データを解釈するには、ちょっと視点を変える必要があります。
全てのパターンを同列に扱うのではなく、

「オリジナルパターン+その他のパターン」

という形で考えてみます。
そして、オリジナルパターンと各パターンを1対1で比較して、どのパターンがオリジナルパターンよりも上回っているのかを考えます。ここでは、パターン1を「オリジナルパターン」として考えます。
面倒なので信頼区間で検定します。各信頼区間を計算すると、以下のようになります。

下限 CVR 上限
オリジナル 2.53% 3.70% 4.87%
パターン2 1.86% 2.90% 3.94%
パターン3 7.96% 9.80% 11.64%
パターン4 7.14% 8.90% 10.66%
パターン5 8.14% 10.00% 11.86%
パターン6 7.04% 8.80% 10.56%
パターン7 7.87% 9.70% 11.53%
パターン8 3.74% 5.10% 6.46%

オリジナルパターンの「上限」よりも高い「下限」を持つパターンは、オリジナルパターンよりも効果が高いと言えそうです。
ここでは、「パターン3,4,5,6,7」がオリジナルパターンを超えています。
次に、オリジナルパターンを超えた5つのパターンのみで、再度テストを行います。一番CVRが高かった「パターン5」をオリジナルパターンとしましょう。
という風にして、繰り返すことで最適なパターンを見つけ出すことができます。うまくいけば2回で終わりますが、何回も繰り返す可能性もあります。
これでテスト終了です。よかったです。

しかし、これでは終わりません。
まだまだ深い分析を行うことができます。
ちょっと長くなったので、その話は次回にします。

A/Bテストの結果をどのように解釈するか?

A/Bテストの実施期間は?

A/Bテストを実施するとき、ほぼ必ずこのような質問を受けます。

「A/Bテストはどのくらいの期間、実施すれば良いのですか?」

これは難しい質問です。なぜなら質問の前提が間違っているからです。A/Bテストの結果が出るかどうかは、「期間」とは関係ありません。関係しているのは、「サンプル数」と「Aパターン/Bパターンの結果の差」です。来訪者を多く集めるサイトでテストを実施するのであれば早く終了させることができます。また、Aパターン/Bパターンで大きな差が早い段階から認められるのであれば、早く終了させることができます。
実施期間について端的に回答するとすると、

「期間は関係ありません、両パターン間に有意差が認められるまでです」

となります。ただ、このような回答をすると、スケジュールも組めないし、馬鹿にしていると思われるので、下のような回答が良いと思います。

「CVが各100件集まるくらいが目安です。1日当たりのCV数は50件程度なので、少し余裕をもって1週間あれば十分です。」

これは全く根拠が無い回答というわけではないです。ログ分析の場合、どうしても計測エラーが出てしまうので、CVが100件程度あった方が安心です。CVRが3%だとすると、テスト回数は33,333回となるので、サンプル数としても十分な数となります。これで差が認められないのであれば、「違いがない」と言い切って問題ないでしょう。

データの解釈方法

A/Bテストの本来の実施期間は、さらっと「両パターン間に有意差が認められるまで」と書きましたが、これはどういうことでしょうか。
具体例を見ていきます。AパターンとBパターンでテストを行いました。
Aパターンのテスト回数は1,000回で、CV数は30回でした。
Bパターンのテスト回数は1,000回で、CV数は35回でした。

AパターンのCVRは3.0%、BパターンのCVRは3.5%。

「なんとBパターンの方が117%も大きい!テストは大成功だ!」

こんなことがよくありますが、本当にこれでいいんでしょうか?
3.0%と3.5%。一見すると、当然3.5%の方が高い数値に見えますが、統計的にはこの段階では何とも言えません。2つのデータに違いがあるかどうかを言うには検定を行う必要があります。通常はカイ二乗検定を行います(サンプル数が少ない場合は「フィッシャーの正確確率検定」が望ましいです)。
カイ二乗検定を行うと、P値は0.614でした。0.05を大きく上回っているので、有意差は認められません(検定については、前のエントリ「 統計学の基礎」を参照)。よって、

「AパターンとBパターンに違いがあるとは言い切れない」

が結論となります。もちろん、違いがないとも言い切れないので、もっとテストを続けれるのがベターですが、時間の問題もあるので、大した違いはないですという結果でOKだと思います。
なので、
「なんとBパターンの方が117%も大きい!テストは大成功だ!」
は大きな間違いです。統計学を知らないと、こんな間違いにも気づくことができません。
大部分のA/Bテストツールには何らかの検定の仕組みが付いています。検定が付いていないツールなんて捨てちまえと言いたいところですが、そういうわけにもいかないこともありますので、必ず自分で検定を行いましょう。検定の仕組みが付いている場合も検定ロジックが明確でない場合も多いので、自分で検定を行なった方が望ましいと思います。

どのようにして結果を伝えるか

一人でニコニコとテストしているのであれば良いですが、チームでテストを運営している場合、結果をチーム内に伝えるのもアナリストの重要な仕事です。しかし、

「カイ二乗検定を行なった結果P値が0.614だったため、両者に有意差は認められません」

と言っても、伝わる人には伝わりますが、統計を何も知らない人には何も伝わりません。なにより直感的ではないです。直感的でわかりやすいというA/Bテストの長所を台無しにしてしまいます。
では、どのようにして伝えるべきでしょうか。
まずは検定を諦めることです。検定はどうしてもわかりにくいです。説明し出したら、検定のロジックの説明から始まり、正規分布を前提としていいのかどうか、など収拾がつかなくなってしまいます。ただ、検定を行わないと、有意差があるかどうかの説明ができません。代替案として、「区間推定」を用います(区間推定についても、前のエントリ「 統計学の基礎」を参照)。
上のA/Bパターンの取りうる値は以下のようになります。

下限 CVR 上限
Aパターン 1.94% 3.00% 4.06%
Bパターン 2.36% 3.50% 4.64%

両パターンの取りうる範囲をグラフ化すると、下のようになります。
線の長さが取りうる範囲(信頼度95%)で、大きい部分は2/3程度を占める範囲です。

これを見ると、Aパターン、BパターンのCVRが取りうる範囲がかなり被っていることがわかります。範囲が被っているということは、どちらのCVRの方が高くなるのかわからないということです。よって、この結果には有意差が無いと言うことができます。

今度は有意差があるパターンを見ていきます。
Aパターンは同じ「テスト:1000回、CV:30回」で、Bパターンのみ「テスト:1000回、CV:70回」に変えます。
これで区間推定を行うと、以下のようになります。

下限 CVR 上限
Aパターン 1.94% 3.00% 4.06%
B’パターン 5.42% 7.00% 8.58%

この場合、Aパターンの上限はBパターンの下限よりも下回っています。つまり、取りうる範囲に「被り」がありません。よって、AパターンとBパターンに有意差が認められるということができます。
(ちなみに、区間推定を用いる場合、カイ二乗検定よりも検定力は落ちるはずです。つまり有意差が出にくくなります)

区間推定の場合、グラフで範囲を示すことも可能で、結果が明確でわかりやすいというメリットがあります。大抵の場合、結果を伝えるには区間推定で十分だと思います。

いや、でも面倒でしょ?

区間推定の計算自体は、さほど難しくないですが、毎回毎回計算しているのはちょっと面倒です。Excelで上みたいなグラフ出すこともできないですし。毎回毎回面倒な計算をしないために、計算を自動で行うツールを作成しました。

A/Bテスト データ分析 A/B test Interpreter

ここで、オリジナルパターンとテストパターンのインプレッション数(テスト回数)とCV回数を入力して、「結果を表示する」をクリックすると、信頼区間が表示されます。その後、「グラフを表示する」をクリックすると、上のような箱ひげ図が表示されます。
また、URLでデータを指定できるようにもしています。
http://web-analytics-or-die.org/abtest/ の後に、「#!/」を付けて、

  • オリジナルパターンのインプレッション数
  • オリジナルパターンのCV回数
  • テストパターンのインプレッション数
  • テストパターンのCV回数

の順に「-」で区切ってデータを並べてください。
上で書いた一回目のテストの場合、URLは
http://web-analytics-or-die.org/abtest/#!/1000-30-1000-35/
となります。
二回目のテストの場合は
http://web-analytics-or-die.org/abtest/#!/1000-30-1000-70/
です。

これを使うとかなり簡単に区間推定を行うことができると思います!