アクセス解析ツールの仕組み(TPPモデル)


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

Leave a Reply