Category: Web分析一般

Pjaxとは？

Pjaxとは、ごく単純化して言うと、Ajaxでコンテンツの一部だけ変更しているはずなのに、URLまでちゃんと変わっているっていうものです。
詳しくは↓で説明されています。
[JavaScript][pjax]pjax こそが pushState + Ajax の本命

Pjaxの何が嬉しいかというと、大きく2つあります。
1つは「戻る」ボタンが利用できることです。
Ajaxでページ内遷移を繰り返しているときに、戻るボタンを押してしまうと、ページごと戻ってしまいます。Pjaxを利用すると、Ajaxのアクションレベルで戻るボタンを使って戻ることができます。
2つ目は、ソーシャル関連ツールの利用しやすさです。Ajaxでページ内の一部を変更した状態のままイイネ！を押したり、はてブしたりしようとしても、URL単位で登録されてしまうので、うまくできません。Pjaxを利用すると、URLまで変更されるので、ソーシャル対応がしやすくなります。

Pjaxサイトの構築

ということで、Pjaxでテストサイトを簡単に作ってみました。
http://vivid-mist-690.heroku.com/

グローバルナビの「navi 2」～「navi 5」までのリンクがPjaxリクエスト用のリンクです。
例えば、「navi 2」をクリックすると、ボディ部がAjaxで変化すると思います。URLを見てみると、「http://vivid-mist-690.heroku.com/:data2」に変わっています。戻るボタンを押すと、元にいたページに戻ることができます。

サーバーはsinatra+herokuで構築しています。無駄にHTML5で構築しています。Pjaxの処理には、pjax用のjQueryプラグイン: jquery-pjaxを利用しています。
HTMLは↓のサイトのものをHaml化して利用させていただきました。
ありがとうございます。
http://www.finefinefine.jp/web/kiji545/

ソースコードはgithubに保存しています。
https://github.com/yosimox/pjax_test

ちなみにIEでは動きません。最新のOperaかFirefoxかChromeを利用してみてください。

Pjaxサイトのログ解析

通常、Ajaxのログ解析を行う場合は、Ajaxアクションに対して、カスタムイベントを発生させることでトラックします。
Google Analyticsの場合、aタグのオンクリックイベントに以下のようなコードをバインドします。
_gaq.push([‘_trackEvent’, ‘foo’, ‘hoge’, ‘bar]’);

Ajaxではカスタムイベントでデータを取得することが普通ですが、Pjaxの場合はイベントよりも通常のページとしてカウントする方が良いと思います。というのも、
・IE等、Pjaxが利用できないブラウザがあり、その場合は通常のページリクエストとなる。
・URLが変わるので、ページが変わると捉えた方が望ましい。

逆にページとして、カウントしたくないような小さなページ内変化はPjaxリクエストをせず、通常のAjaxイベントとして処理させるべきだと思います。

GAを利用する場合、実装はさほど難しくありません。というのも、jQueryプラグイン「jquery-pjax」に既にGAのサポートがされているからです。単純にPjaxリクエストが成功した時の、コールバック関数の中で、_gaq.push([‘_trackPageview’]);を動作させています。（161行目）
もし、カスタム変数を設定したいのであれば、その前あたりに書いておけばOKです。

どうせ、jQueryを使っているんだし、外部リンククリックの取得も合わせて設定してしまいましょう。
一つ注意する必要があるのは、Pjaxで変化した中身のリンククリックも対象としたい場合、通常の下記のような方法ではうまくバインドできません。

解決策としては、jquery-pjaxのコールバック関数の中にclickイベントをバインドするか、”click”の代わりに”live”を利用するかです。liveの方が楽にできると思います。
かなり簡単にですが、こんな感じで書いてみました。

サンプルサイトのボディ部にYahoo!と書かれているリンクがあると思います。このリンクをクリックすると、トラックイベントが発生して、GAにデータが送信されます。内部リンクは送信しないようにセットしています。
グローバルナビ（navi 2など）をクリックして、ボディ部を変更しても外部リンククリックの取得は正常に行われていると思います。

Pjaxサイトの分析サイドからの利点

Pjaxの一番の利点はユーザーエクスペリエンスの向上ですが、分析サイドでも利点はありそうです。特に、URLが完全に「一意」であるため、
「ユーザーの関心の高さ」と「PVの多さ」
がほぼ一致するということが大きいです。（もちろんナビゲーションの問題もありますが）。通常のAjaxではクリック単位でイベントを計測することになるので、他のページとの比較が難しくなります。また、通常のページビューとしてカウントできることで、ページ遷移を追うことがより容易になります（ページ遷移についてはGAよりもSiteCatalystの方でメリットが大きそう）。

IEはIE9でも対応していないというPjaxの酷い欠点もありますが、対応していなければ通常のページリクエストになるだけで、分析サイドからはあまり関係がないのかなと思います。ある程度大きな規模のサイトでPjaxを使っているのはgitHubくらいしか知らないですけど、今後Pjaxはかなり熱いんじゃないでしょうか。

さりげなく、こんなコースを受講していました。
カナダのUBC (The University of British Columbia) と アメリカのWAA (Web Analytics Association)がコラボして提供しているオンラインのWeb Analyticsについてのコースです。
UBC Award of Achievement in Web Analytics

下の４つのモジュールで構成されています。それぞれ1ヶ月くらいのコースです。

• Introduction to Web Analytics
• Web Analytics for Site Optimization
• Measuring Marketing Campaigns Online
• Creating and Managing the Analytical Business Culture

結構人気があるみたいで、コースが埋まっていたりして、なかなか都合良く受講できなかったりします。
それもあり、結局全部終わるまで1年ちょっとくらいかかっちゃいました。

コースの感想

内容自体は基本的なことから基本的なことまで、基本的な内容をみたいな感じです。
最初のIntroduction to Web Analytics は基本的なところをまんべんなくみたいな感じなんですけど、他のコースも基本的な内容しかないような。。。
一部マニアックな内容が急に入り込んだりしてきますが（どうやってデータ取得するんだろうっていうような間接効果の分析方法とか。。。。）
４つのコース全てで、どのツールを使うとかは全然関係なく、分析の考え方が中心のカリキュラムとなっています。

教材は複数の人が作っているので、バラエティ豊富な反面、同じ内容の繰り返しがあったり、ちょっと整合性合わないなっていうところがあったりします。
あと、Tutorによって評価の基準が全然違います。ひどいくらい。基本的にゆるい先生が多いんですけど、おかしなくらい低い評価を出す人もいました。一人だけ。コースを落とすほどじゃないですけど。

当然、教材も英語だし、英語で文章を提出しなくてはいけないので、英語力がないときついです。そして仕事が忙しいタイミングと重なると地獄です（さらに引っ越しが重なったりしたので悪夢でした。。。）
でも英語の勉強にはなるんじゃないですかね。きっと。

あ、なんか悪いことばっか書いちゃいましたけど、全然悪いコースじゃないですよ！
Web Analyticsの多くのパートをカバーしているので、普段ではあまり関わっていない分野も勉強できたりします。教材の質はまちまちですけど、結構良いものも多いです。
掲示板みたいなものが用意されていて、生徒から活発に書き込みがあり、結構勉強になったりします。

普段からガリガリWeb Analyticsを実践している人にとっては当然の内容ばっかりなんですけど、そうでない人にとっては役に立つ内容ばかりだと思います。
費用も結構かかりますので、特におすすめはしませんけど、なんかネタとして楽しい感じなので、やってみるのも良いんじゃないですかね。
普通にWAAのテストを受けた方が良いような気もしますが。。。あっちも結構高いですけど。

ちょっと所用で、KPIレポート用のダッシュボードを調べてました。
かっこよかったり、良さそうなのがあったりだったので、まとめてみました。
Web Analytics用に作っていないものも含まれています。

http://matt-smedley.com/web-analytics-framework
上記のブログで紹介されていましたが、おそらくstratigent社が作ったものだと思われます。ゴールの評価も明確でトレンドもわかりやすい。
フォーマットの中にレコメンドアクションを含めているのが素晴らしいです。

http://www.nabler.com/services/web-analytics-dashboard.asp
これも結構普通で、わかりやすく作っています。
これくらい指標が絞れると、かなり見やすくなります。

http://blog.davidfeldt.com/2007/12/10/the-art-and-science-of-dashboards/
ちょっと趣向を変えて。
Excelとかの紙ベースではなく、ソフトウェアベースでのダッシュボードであれば、こんなものありかなと。
インパクトはかなりあります。詳しくはクリックしてネみたいな感じ。

http://numbermonger.com/
折れ線ブラフのうねり具合が素敵です。達成度を示すバーは、こんな感じでもいいですね。

http://quince.infragistics.com/Patterns/Dashboard.aspx
これも似たような感じで、もう少し詳しいものです。
サーバーとかの負荷を監視するダッシュボードなので、トレンド系はないですけど、ちょっと参考にはなりそうです。

http://www.dashboardinsight.com/dashboards/screenshots/the-business-intelligence-guru-us-unemployment-dashboard.aspx

ちょっと細かいですけど、じっくり読めば結構わかりやすい感じにはなっています。ここまで細かくすると、ダッシュボードとしてはどうなんだろうとは思いますけど。

http://www.w3support.net/index.php?db=su&id=84847

Excelで作ったにしてはかっこいいですね。
やっぱExcel2007以降だと結構変わりますね。
弊社はいまだ2003なんで。。。

http://dashboardguy.blogspot.com/2008/06/excel-template-for-dashboards.html
なんだか、わかりやすいようで、あんまりわかりやすくない感じです。
ちょっと同じようなものが並び過ぎるとわかりにくくなりますね。
上手くカテゴライズされているので、カテゴリーごとの違いを明確にした方が良いかもしれないです。

http://cursoexcelbh.wordpress.com/dashboard/

これも上の方で出てきたサーバー監視系のダッシュボードに近いです。
Excelで作るの大変そうだなー。

http://www.georgesbudget.com/exceltemplates/excel-budget-spreadsheet-checkbook-register.html
マクロで自動集計できるみたいな感じですね。わからないですけど。
シンプルで良いと思います。

http://www.kaushik.net/avinash/2008/04/the-action-dashboard-an-alternative-to-crappy-dashboards.html
最後はおなじみのAvinashのダッシュボード。
やっぱり、ダッシュボードでもちゃんと文章で説明するという姿勢が大事だと思います。このAvinashのエントリも必読。
もう一つ、↓のダッシュボード系のエントリも読む価値あります。
http://www.kaushik.net/avinash/2007/03/five-rules-for-high-impact-web-analytics-dashboards.html

フェイスブックインパクトを読みました。一応。
特に感想はないですが、一つだけ。
最後の高広さんの章で、ソーシャルメディアの「ソーシャル」について説明しようとしています。
社会の最小単位＝「家族」なんて、サッチャーのようなことを仰っておりましたが、うまく説明しきれずに、尻つぼみで終わっているような印象を受けました。

このブログは、ウェブ分析縛りで書いていたのですが、今日はちょっとだけ脱線して（広い意味での分析っていうことで）、ソーシャルメディアにおける「ソーシャル」について考えてみたいと思います。

高広さんも書いているように、社会学の中でも「社会」の定義には相当に議論があります。というよりも、「社会」をどう定義するかによって、その人の社会学のスタンスが決まると言った方が良いのかもしれません。込み入った話に立ち入るとボロが出るので、ここまでにしておいて、僕の考える「ソーシャル」について書いてみます。

「社会（ソサイエティ）」と似た概念で、「世界（ワールド）」という概念があります。世界とは何を意味しているのでしょうか。ウィトゲンシュタインは論理哲学論考の最初のパートで、世界についてこう語っています。

1 世界とは、起きていることすべてである。
1.1 世界は事実の全体であり，ものの全体ではない。
1.11 世界は事実によって、そしてそれらが事実のすべてであることによって、規定されている。
1.12 なぜならば、事実の全体はなにが起きているかを規定し、そしてまた、なにが起きていないかをも規定するからである。
1.13 論理空間の中にある事実、それが世界である。
1.2 世界は事実へ分解される。
1.21 その他すべてを変えずに、ひとつひとつが起きることもできるし、起きないこともできる。

そして、こう締めくくります。

7. 語りえぬことについては，沈黙するしかない。

世界は事実の全てであって、世界の外側については我々は何も知ることはできない。そして、事実とは論理空間の中にあるもの。つまり、我々の思考の限界が世界の限界であるということです。
すなわち、「世界」とは、ある個人が想像しうる全ての事実として考えられます。「事実」は、物理的に存在しているかどうかは問題ではありません。たとえば、空想の世界であっても、その人が事実として受け入れているものであれば、それは世界の一部となります。逆に、実際に地球上に存在していたとしても、その人が全く知らなければ、それは世界の外側にあるものとなります。

では、社会とは何か？「世界」とは想像しうる全ての事実であることに対し、「社会」とは想像しうるコミュニケーション可能な集団として考えます。重要なのは「想像しうる」という点です。実際にコミュニケーションが取れるかどうかは問題としません。ある集団に対して、コミュニケーションが取れると判断できるならば、その人はその集団と同一の社会に属していると考えられます。古くから、「国民国家」が社会の代表格として存在してこれたのは、コミュニケーションを可能とさせる共通言語の存在、マスメディアの存在が強く影響しています。
そういう意味では、僕の考える「社会」は、ベネディクト・アンダーソンの「国民国家」論と同じで、「想像の共同体」を指します。「共同体（コミュニティ）」は恒常的にコミュニケーションを取っている集団です。その一方、「想像の共同体」である社会は、直接的、双方的なコミュニケーションは取らないとしても、自分をその社会の中の存在として置き換え可能であれば、社会の成員として考えられます。
例えば、大企業であれば、部署の違う社員同士で直接的なコミュニケーションを取ることは少ないかもしれないですが可能です。よって、企業は「社会」として考えられます。企業の中で、同じプロジェクトメンバーであれば、恒常的にコミュニケーションを取るので、「共同体」として考えられます。

ようやくフェイスブックの話に入ります。フェイスブックでは、「friends」や「Like！」で繋がった個人・企業は同一の共同体（コミュニティ）として考えられます。そういう意味では、フェイスブックにおける「ソーシャルグラフ」の「ソーシャル」は、「社会」というよりは「コミュニティ」の形容詞として捉えられます。そして、全てのソーシャルグラフの総体がフェイスブックという「社会」と考えます。
しかし、全てのフェイスブック利用者にとって、フェイスブック全体が一つの「社会」とは限りません。フェイスブックは基本的に「テキスト中心」のコミュニケーションメディアであるため、言語がわからなければ、社会として「想像」しなくなる人もいるでしょう。英語を見たくもないという人にとっては、英語利用者は社会の外側にあります。テキストだけではなく、画像や動画もあるため、話は単純ではないですが。いずれにせよ、同じ「社会」の一員かどうかは、言語の影響も大き関わります。

そして、何より重要なことに、フェイスブックでは、ソーシャルグラフが可視化されます。ソーシャルグラフを見ることによって、その人が自分と同じ「社会」の成員かどうか判断されます。つまり、フェイスブック上ではソーシャルグラフこそが本人となります。名前は本人を示す記号にすぎません。ソーシャルグラフが本人です。もちろん、これを可能にするのは実名での登録があってこそであることは間違いありませんが。

キルケゴールの「死に至る病」での冒頭の有名な一節、

人間は精神である。精神とは何であるのか。精神とは自己である。自己とは何であるか。自己とは自己自身に関わる一つの関係である。

フェイスブックでは、このキルケゴールの抽象的な議論が、目に見えるソーシャルグラフとして可視化されます。「関係」こそがフェイスブックの本質であり、ソーシャルメディアの「ソーシャル」たるゆえんです。

マーケティング的に考えると、フェイスブックをはじめとしたソーシャルメディアでは、まず「想像の共同体」である社会の一員となる必要があります。それには、当然、フェイスブックなどユーザーと同じプラットフォーム上に参加し、コミュニケーション可能な言語（＝ローカルな言語）で展開する必要があり、さらに企業の存在を知ってもらう必要があります。しかし、想像の共同体のままでは、ビジネスになりません。ビジネスへと繋げるためには、ユーザーの共同体の一員になる必要があります。ファンページで「いいね！」を押してもらい、恒常的なコミュニケーションを取れる状態にし、ユーザーとコミュニケーションを取りづける状態へと進めることが求められます。企業がユーザーのコミュニティの一員となれば、ユーザーは彼自身の別のコミュニティに対し、その企業の製品を薦めてくれることでしょう。もちろん、全て好意的な方向ではないとは思いますが。要するに、企業（または製品・ブランド）自身がユーザーのソーシャルグラフの一員として、「関係」を作ることが重要となります。なぜなら、ソーシャルグラフこそがフェイスブック上での本人であり、「関係」こそがフェイスブックの本質であるからです。いかに強固な「関係」を作るのかが、ソーシャルメディアマーケティングの役割となります。

最後は、無理矢理マーケティングに結びつけてみましたが、結論としてはむちゃくちゃ平凡です。実際、実務としてSMMをする時は、こんな抽象的な議論は大して役に立たず、地味で面倒な運用をコツコツやることが成功に繋がるんですけどね。

意識データと行動データ 1
意識データと行動データ 2

意識データは何の役に立つのか：効果測定

ここまで、（量的な）意識データは学問としての厳密さには欠けるものの、ビジネスとして、「役に立つ」データではあると書いてきました。では、何の役に立つのでしょうか？「効果測定」と「ユーザー調査」に分けて考えてみたいと思います。
現場では、よく「効果測定」と「ユーザー調査」が混同されています。この2つは調査対象が全く異なります。「効果測定」は、何らかの施策を行った時、効果があったのかどうかを測定する方法です。「ユーザー調査」は、ターゲットとなるユーザーを調査することです。効果測定は「施策」に対する調査であり、ユーザー調査は、「ターゲットユーザー」に対する調査です。
まず、効果測定における意識データの有用性について考えます。ここではWebサイトに絞って考えます。効果測定における「効果」とは何に対する効果か。それは施策の目的に対する効果です。効果測定は施策の目的を測定し、評価することです。施策の目的はそれぞれ異なります。例えば、ECサイトの場合、商品を販売することが目的なため、販売額を測定し評価することが効果測定となります。サイトへつれてくること「だけ」が目的のネットADの場合、サイトへの流入数やCTRが評価対象となります。ECサイトなど、施策の目的が「行動」へと直接結びつく場合、行動データが非常に役に立ちます。しかし、施策の目的が行動へと結びつかないことが往々にしてあります。
Webサイトに限らず、マーケティング施策の役割として、最も包括的な概念として考えうるのは、「態度変容」です。商品について「知らない状態」から「知っている状態」への態度変容、「興味のない状態」から「興味をもった段階」への態度変容、「興味があるだけの状態」から「欲しいという状態」への態度変容、「欲しい」から実際に「購入する」への態度変容。あらゆるマーケティング施策は態度変容を起こすために行われていると言ってもいいくらいです。
上の例はAIDMAプロセスに沿って書いていますが、このプロセスに限ってみると「行動」へと繋がっているのは、最後の購入（Action）だけです。それ以外の態度変容は全て意識の中で起こっています。もちろんAIDMAプロセスがマーケティング施策の全てではなく、行動を起こすことがマーケティング施策のゴールとなることもあります。ただ、マーケティング施策のゴールの大部分は「意識の中」で起こるものであることには変わりありません。
意識の中で起こった態度変容を測るための最も一般的な方法は意識データを取得することです。量的調査の場合、大部分はアンケートになるでしょう。意識の変化をうまく行動データへと落とし込ませるというやり方もあります。例えば、一時期流行った「続きはWEBで」はその代表例でしょう。しかし、このやり方には無理があります。第一に実際に行動するのは態度変容が起こったユーザーのうち、ごく少数です。それでは施策が過小評価されてしまいます。第二に、ユーザーに無駄な負担をかけてしまいます。態度変容を起こすために施策を行うのではなく、効果測定をするために施策を行うはナンセンスです。やはり意識下での態度変容を測定するには、意識データを取得するしか方法はありません。

意識データは何の役に立つのか：ユーザー調査

ユーザー調査を行って、何か新しい発見をしたい場合は質的調査を行った方が間違いなく良い結果がでます。ただ、なんとなくアタリをつけたい場合、報告するためにデータが必要な場合など、量的データが必要になることがあります。そのような場合にも（量的な）意識データが必要とされます。そもそも行動データは取れる範囲が圧倒的に狭いため、必要な情報が無いという場合がぼとんどです。例えば、Webサイトに必要な機能は何か知りたいという場合、現在提供中の機能についてはアクセスログから類推することができますが、まだ提供していない機能については、行動データを取得することは当然不可能です。過去の行動について知りたいという場合でも、行動データを取得することはほとんど不可能ですが、アンケートであれば過去の行動について訊くことができます。ユーザーについての（量的な）データが必要な場合、意識データを使わない手はありません。

なぜ今あえて意識データか？

いや、みんなあまりにもClickstreamデータに依存しすぎじゃない？ってことです。アクセスログによる行動データが強力なのはわかっていることですが、クリックストリームに依存しすぎていて、それ以外の手法はないことになっていませんか？
Avinashはそこの所が非常によくわかっていて、Trinity Strategyを提唱しています。Avinashにとって、”Behavior”（Clickstream）は必要なデータの1/3でしかありません（OutcomesはClickstreamの可能性も大いにありますが）。”Experience”では、Customer SatisfactionやVOCなど記載されており、Surveyを重視する姿勢を見せています。Clickstreamデータはあくまでも調査・評価の一面に過ぎず、目的に応じて、調査・評価手法は使い分けるべきです。
そこまではわかっている。じゃ、実際にどうデータをとればいいのさ？っていう意見は多いと思います。Webでは行動データの取得の方が圧倒的に容易です。気軽にアンケートを行うことはできないかもしれません。いやいや、そんなことありません。気軽に行えばいいんです。そのやり方については、またどこかで（業務上、書いていいのかどうかわかりませんが。。。）。

前回の続き
意識データと行動データ 1

それでもあえて意識データを擁護する

このように時代は明らかに行動データへと傾きつつ有り、行動データによって成果もあげつつあります。しかし、ここでは、あえて意識データを擁護したいと思います。
まずは、意識データへの不信への回答から始めたいと思います。
一つ目の疑問：「人の意識を数量化することができるのか？」
答え。できません。全てのユーザー調査は恣意的にならざるを得ないと思います。学問的な誠実さから考えると、明らかに失格です。僕は学生時代は社会学のエスノメソドロジーという分野を学んでいました。エスノメソドロジーについては、詳しく述べることはしませんが、エスノメソドロジーでは「実践の厳密な記述」を目指します。自ら調査主体の構成員となり、内側の視点から社会の構築を記述します。このことによって学問としての真摯さを保とうとします。
このように、意識を数量化することは学問的には無理があります。しかし、それが本当に役に立たないのかというと疑問です。マーケティングでは学問的な厳密さよりも、「役に立つかどうか」の方が重要です。学問的な厳密さには欠けるものの、アンケートデータは役に立つ程度のデータを出すことは可能です。そのためには、無理のない調査設計を行うことと、結果の解釈は有意性検定に基づいて行うことが必要です。これにより、ある程度の信頼性は保障されます。ビジネスにおいては「ある程度」で十分だったりします。
2つ目の疑問：「人は自分の意識を言語化することができるのか？」。答え、ほぼ無理です。質的調査では、これに対する回答として2つの方法があります。1つは他者が人の意識を解釈する。2つ目は言語化するスキルを持った人自らが調査対象となり、記述することです。1つ目の方法がエスノグラフィーであり、2つ目の方法が先ほど述べたエスノメソドロジーです。
問題は量的データです。量的調査では質的調査のような解決方法は適用できません。しかし、ここでも回答は１つ目と同じです。ある程度正しければ良いのです。役に立つ程度の信頼性はあります。

量的データと質的データ

これまで、あえて量的データと質的データの両方を扱ってきましたが、ここで一旦整理したいと思います。なぜかマーケティングの世界では意味不明な定量データ、定性データという言葉で呼ばれることが多いですが。
この2つのデータの違いは明白です。数学として取り扱えるか否かです。「テキスト」それ自体では、質的データですが、テキストマイニングを行い、数値化すると量的データへとなります。
量的データと質的データには4つの点で大きな違いがあります。

• 抽象性
• コンテキスト
• 解釈の自由度
• データの代表性

量的データは抽象性が高く、コンテキストが希薄で、解釈の幅が狭く、データの代表性が高いです。質的データは、全てその逆です。簡潔に書くと、量的データには有無を言わせない数字のチカラがあり、質的データは、いかようにも解釈できる、という具合です。
しかし、一方では量的データからは発想の飛躍がしにくいということも言えます。これはデータの性質以前にデータ収集の段階で、決められた枠内でしかデータが収集できないということからも生じます。つまり、量的データは基本的に「仮説検証型」のアプローチであり、データから「探索的に」何かを発見することは難しいと言わざるを得ません。データマイニングは探索型のアプローチとも言えますが、これは小さな仮説検証を積み重ねるという意味での探索型調査であって、本当の意味の探索型アプローチをしようとすると、いくら時間があっても足りません。データの代表性の問題は常に残りますが、新たな発見や新しい発想を生み出すための調査としては質的データに頼る他ありません。（データの代表性については、GTA:グラウンデッド・セオリー・アプローチのやり方はうまくやっていると思います。問題の解消はできていませんけど。なんかWikiPediaの説明は、かなり偏っていますが。。。）
質的データにも当然、意識データと行動データがあります。しかし、質的データにおいては両者に大きな違いはありません。なぜなら、それらの違いよりも「解釈」の違いの方が圧倒的に大きな影響力を持つからです。ユーザーテストによる「観察データ」は、行動データであり、デプスインタビューによるインタビューは意識データです。エスノグラフィーによる参与観察はインタビューを通して、意識を探り、観察を通して行動を理解します。エスノメソドロジーについては、行動なのか意識なのかは既に重要ではありません。どの種類の調査にとってもデータの種類よりも解釈のほうが遥かに重要です。

まだ続きます。

意識データと行動データ 3

意識データと行動データ

マーケティングリサーチで用いられるデータには意識データと行動データの2種類のデータがあります。意識データとはユーザーが考えていることをデータ化したもので、行動データはユーザーが行動した結果をデータ化したものです。よく混同されるのですが、定量データ（量的データ）と定性データ（質的データ）とは別物です。意識データにも量的、質的データの両方があり、行動データにも量的、質的データの両方があります。あくまでもデータとなる対象が、意識か行動結果かの違いです。他にもデモグラフィック属性データなどもありますが、ここでは割愛します。
ここ最近この2つのデータについて、あれこれと考えていたのですが、まだ考えがまとまっていません。まとまってはいないのですが、考えている途中結果をここに書いてみようと思います。

行動データの優位性

近年のマーケティングデータ分析における大きな転回として、意識データから行動データへ、という点が挙げられます。以前はそもそも行動データ（量的）を取得することはほとんど不可能でした。マーケティングで利用するユーザー調査データの大多数がアンケートで取得された意識データでした。しかし、POSシステムによって状況は一転します。POSによって、「いつ、どの商品が、どんな価格で、どんな人に対して、いくつ売れたか」がわかるようになりました。人がある時点で「考えていた」情報よりも、実際にとった「行動」の方が圧倒的な説得力を持って迎え入れられます。POSデータを基にした仕入れは当たり前のように行われるに至りました。
Webの登場も行動データへの転回に大きく貢献します。Webではアクセスログを通して、ユーザーの「行動」が詳しくわかります。ユーザーが、どこから来て、どのページを見て、購入してくれたのかどうかが簡単にわかります。ユーザーの行動結果こそが真理であり、行動結果を改善するために何をすれば良いのか、がマーケティングとなってきています。
ここにおいて、マーケティングとマーケティングリサーチの垣根が低くなります。つまり、マーケティング施策とマーケティングリサーチが、同時に行われるようになります。A/Bテストや、MVTなどの実験調査は、まさしくマーケティングとリサーチが同時に行われる手法です。新たなマーケティング施策を行い、次の施策へのリサーチも同時に行う。マーケティングとリサーチが同時に行われることで素早い改善が可能となります。これも結果へと直線的に結びつく行動データが容易に取得できて初めて成り立つ手法です。

意識データの劣勢

利用されるデータが行動データへと大きく傾いているのは、行動データが取れるようになったことだけが原因ではありません。意識データへの不信がその根底にあります。その根本的な不信は以下の2点です。

• 人の意識を数量化することができるのか？
• 人は自分の意識を言語化することができるのか？

最初の要因は、意識データというよりも量的データに対する疑問です。行動データが取得される前は、量的データといえば、人口統計データか、アンケートによって作成される意識データでした。アンケートにおける設問は全て設問作成者による恣意的なものであり、事前に作成された仮説を検証するために作られます。仮説を検証するために有利に調査を設計することから逃れられません。また、アンケートの回答も恣意的となります。例えば、5段階尺度でのアンケートで、3段階目と4段階目の境目の解釈は人によって、大きく異なります。それを同一の尺度で語っても良いのかという疑問があります。人口統計データでも、アンケートでも同様ですが、何らかの事象を数量化するとき、必ず「定義」が必要となります。定義は量的データを作成したものによって恣意的に行われざるをえません。
2つ目の要因はより根本的です。自分は自分のことをどれだけ知っているのかという問いへと繋がります。特に未来のことについては、自分自身でも全くわかりません。コンビニに買い物へ行く前と、実際に買ったものを比べてみると、全然違う買い物をしているということも往々にしてありえます。過去に行ったことに対する意識については、まだ妥当性は高いですが、記憶は常に捏造されます。記憶とは現在の意識に基づいて再構成されるものです。過去に取った行動と現在の状況が異なるとき、過去にとった行動を書き換えてしまいます。

長いので続きます。
意識データと行動データ 2

ruby+mongoDBでアクセス解析ツールを作ってみて、アクセス解析ツールの仕組みがよく理解できました。アクセス解析ツールの説明をしている本やWebサイトなどよくありますが、多くは表層的な解説だけで本質的なところは解説できていません。というか、おそらく理解すらしていないと思います。
ちょっと技術よりになって難しいかもしれませんが、ここでは本質的な理解ができるような解説をしたいと思います。本質的な理解をすることで、各解析ツールがなぜああいう動作をしているのかを理解することができると思います。そして、結局は自分で作った方がいいやって思うと思います。

アクセス解析ツールのTPPモデル

アクセス解析ツールは3つの階層によって成り立っています。
1つ目は、データを取得する層（トラッキング層）
2つ目は、データを処理し、DBに格納する層（プロセッシング層）
3つ目の層は、データをUI上に表示する層（プレゼンテーション層）です。
このアクセス解析ツールの3階層モデルを、僕は勝手にTPPモデルと呼んでいます。
全てのアクセス解析ツールはこの3層モデルで理解することができます。

トラッキング層

トラッキング層はアクセスログを取得する仕組みを提供します。
よく言われるように、アクセス解析ツールはトラッキング層によって3つに分類されます。

• サーバーログ型
• パケットキャプチャー型
• JavaScript型（ビーコン型）

サーバーログ型はWebサーバーが吐き出したログデータを利用して解析を行います。アクセス解析ツール自体はトラッキング層を提供しておらず、Webサーバーがトラッキング層を担当します。ツールによっては、ApacheやIIS用のモジュールを提供して、Webサーバーに組み込んだ形でトラッキング機能を追加するものもあります。モバイル系の分析で用いられることが多いです。

2つ目のパケットキャプチャー型はWebサーバーの通信を監視して、通信したパケットを傍受したデータを解析します。トラッキング専用の「箱」が必要となります。

3つ目のJavaScript型が現在主流となっているトラッキング方法です。ページにアクセスする度に、Webページ上にごく小さなgif画像（ビーコン）を読み込んで、その画像のログデータを解析します。
JavaScript型の優れている点は、JavaScriptを利用して、自由にカスタマイズしたデータを取得することが出来る点です。JavaScriptでできることであれば、ほとんどどんなデータも取得することができます。

取得できるデータ量としては、圧倒的にJavaScript型が優っており、今後導入するのであれば、JavaScript型一択ですが、他の方法にも利点があります。
まず、サーバーログ型ですが、Webサーバーはデフォルトの状態でアクセスログを吐き出しています。そのため、分析を始める前の段階からデータが揃っていることになります。よって、過去に遡って解析することが可能です。また、データが自社環境の外側にでないので、セキュリティ上望ましいと考えられることも多いです。実は、サーバーログ型も工夫次第では、多岐に渡ったデータを取ることも可能です。

次にパケットキャプチャー型ですが、規模が大きくなるとTCO（トータルコストオブオーナーシップ）が他のツールよりも優れている場合が多いです。あとは、特にないかな。。。

後で、詳しく書きますが、アクセス解析ツールをこの3つに分類するだけでは不十分です。プロセッシング層とプレゼンテーション層における処理内容も各ツールで大きくことなります。TPPモデルで理解することで初めて、アクセス解析ツールを理解できるようになります。

プロセッシング層

2つ目の層はプロセッシング層です。ここは多くのツールにとって、ユーザー側に見える部分ではないので、あまり意識されませんが、アクセス解析ツールのキモとなる部分です。

どのようなことをするのかというと、ログデータを利用しやすい形に変換して、DBに流し込むという作業を行います。ここでどのように処理して、どのような形式でDBに入れるのかによって、アクセス解析ツールの性質が大きく変わります。

プレゼンテーション層

3つ目の層はプレゼンテーション層です。ここでは処理済みのデータを集計して、表やグラフとしてブラウザ上に表示させたり、CSVとしてダウンロードさせたりします。
この層がそれぞれの解析ツールの見せ場となります。どうでもいい素敵なグラフや、かっこいいだけで使いにくいUIなど、多くのツールベンダーはこぞってプレゼンしてきます。全力で無視しましょう。

どこで集計をするのか？

トラッキング層はデータを収集するだけなので、集計は含まれていません。集計は多かれ少なかれ、プロセッシング層とプレゼンテーション層の2つの層で行っています。このどちらの層で主に集計を行うのかでツールの性質が変わってきます。

SiteCatalystなどリアルタイム計測が可能なツールはプレゼンテーション層における集計を重視しています。おそらくプロセッシング層では、ほとんど集計作業を行わずにデータを変形させてDBに格納しているだけのものと思われます。

WebTrendsは逆にプロセッシング層でかなりの集計を行っていて、プレゼンテーション層では集計済みのデータを加工しているというような位置づけだと思われます。日次程度で、プロセッシング層における集計作業をバッチ処理させて、プレゼンテーション層に受渡します。そのため、リアルタイムでのデータ反映は不可能です。

当然、プレゼンテーション層での集計の方がオンデマンドでの集計ができるため、ユーザーにとっては望ましいものとなります。ただし、ユーザーからリクエストがあるたびに毎回集計しなおさなければならないため、サーバーに負荷がかかり、集計に時間がかかります。この負荷を下げるために3つの工夫をしています。
1つはキャッシュ処理。1度行ったクエリはキャッシュとして保存しておいて、同じクエリを行なった場合はキャッシュ側からデータが送信されます。
2つ目はデータ型の工夫。例えばSiteCatalystでは滞在時間を正確な秒として保存していません。「1分～3分の間」のような形にして保存しています（そのため平均滞在時間は推定値となっています）。その他にもDBに格納するデータ形式を工夫して集計量を少なくする工夫を取り入れています。
3つ目はトラッキング層の重視。そもそもサーバー側で集計しなくても良いように、トラッキング層で細かい設定をしてデータを取得することを要求します。そのため、SiteCatalystを使う場合は事前の解析設計が非常に重要になり、計測タグ設計が複雑になります。そしてアナリストはエンジニアじゃないのにと思いながら、ひーひー言います。

一方、プロセッシング層における集計を重視する場合は、集計時にデータの加工ができるため、タグ設計にそれほど悩まなくても良いという利点があります。たとえば、WebTrendsでは集計時に正規表現でコンテンツグループを設定することができます。SiteCatalystやGoogle Analyticsではコンテンツグループの設定はトラッキング層で行わなくてはいけません。集計の柔軟性という意味ではプロセッシング層を重視した方が望ましいことも多くあります。当然、プロセッシング層における設定作業が複雑になり、エンジニアはひーひー言います。

Google Analyticsに関していうと、SiteCatalystとWebTrendsの中間程度だと思います。プロセッシング層における集計の柔軟性は全く無いですが、UI上で効果的な集計ができるためにプロセッシング層である程度の加工を行っていると考えられます。このおかげで、特徴的なアドバンストセグメントとカスタムレポートが可能になっています。その一方で、リアルタイム性が犠牲になっています。

ただ、Google Analyticsもデータの持ち方の工夫や、サーバーの増強で、リアルタイムとまでは言わないですが、かなり早く計測結果が出てくるようになりました。SiteCatalystもVer15でデータの持ち方を工夫して、UI上での集計が多くできるようになるようです（GAのパクリ）。WebTrendsについては、新しいものは知りません。。。。

自家製ツールは？

僕が作っているruby+mongoDBによる解析ツールについていうと、プロセッシング層の極端な重視という特徴があります。というか、プレゼンテーション層は他のツールに任せるという位置づけです。プロセッシング層で強力なバッチ処理を行うことで、既存のツールでは出すことができないデータも集計できるようにしています。
ちなみにトラッキング層についていうと、今のところサーバーログだけですが、画期的なアイデアを思いついたので、トラッキング層で収集するデータも増やすようにする予定です。

$where句を使うと、処理は遅いけど色んなクエリをかけることができます。
という備忘録です。
下のdataというようなデータの場合、

MongoDBのShell上で、下のようなクエリを書くと、
page[0]が”/”で、page[1]が”/index2.html”
というデータが含まれているデータを全て抜いてくることができます。

SQLより柔軟で素敵！
おそいけど。

そして、これさえできれば、
1ページ目に「/」を見て、「/index2.html」に遷移した人に絞った
ページの滞在時間も計算できたり！
こういう行動した人のリファラーを出せたり！
色々細かい分析ができます！面倒なのでしませんが！