ニガくて難しいアクセス解析を、たっぷりのミルクでふわふわの贅沢ラテ的な仕上がりに

Google Analyticsみたいなのを自分で作ろうと思ったけど考えただけで挫折したメモ

GAの全体の流れはこのようになってますね。この中で2、3、4はユーザには見えません。

  1. アクセストラッキング(JSタグ)
  2. 生ログを保存
  3. 保存されたデータを統計情報に
  4. コンバージョン情報を計算
  5. 統計情報を表示

こういうアクセス解析ツールを自前で作るとしたら、アプローチは逆になります。

  1. 解析画面に表示する要素を決める
  2. 表示に必要な情報の計算方法を決める
  3. 表示に必要な、取得すべき情報を決める
  4. 情報を取得する手段を決める

GAは、タグと表示のカスタマイズだけできるようになってます。
途中の計算を全部気にしなくて良くて、googleクオリティでやってくれると期待してるからみんな使っています。ただ、あたりまえのことすぎて誰も話題にしませんが、ここは実はとんでもないことです。

GAとなると全世界に数千万、数億あるサイトに貼ってあると想定すると、1サイト100ページ、平均50pv/dayだとすると、50x億で50億、100億以上のログが発生してることになります。
この時点でga.jsが呼ばれる回数が100億回で、全世界で同じURLなので、その負荷に耐えうるサーバーが必要になってくる。実際はCDNとか使ってるんだろうけど。
また、twitter.comに入ってるだけで億を軽く超えるので、実際の負荷はそれ以上になるはず。桁が違うかもしれない。それでいて、レスポンス速度もストレスにならないようにしないといけないから、googleへの負担と期待はさらにさらに高まります。

で、JSを読んだあとは実際のログをDBに保存しないといけない。JSがimgビーコンをサーバにリクエストしてるが、そのビーコンが呼ばれた回数とか呼ばれた内容に応じてDBのレコードが増え続ける。これがJSのリクエスト回数とイコールになるし、タグをカスタマイズしてたりイベントトラッキングしていればさらに増える。この時点で少なく見積もって1日200億レコードはいってるはず。これはFacebookの1日のイベント数と同じくらい。だとするとGAはもっと多いのかも。

Facebookの新しいリアルタイム解析のシステムでは、HBaseで1日200億件のイベントを処理しているそうです。
via :Facebookの新しいリアルタイム解析システムとは? - nokunoの日記

ただ、GAはログそのものはユーザから取得できないし見ることもできない代わりに、統計情報になっています。だからAPIで使える。その統計情報を作る際に、サイトごとに一定期間における生ログを計算しているんだね。それがリアルタイムアクセスとGA上に表示されるまでの時差になる。
これが2009年以前は24時間かかったのが、いまでは数時間~数十分くらいになってるわけです。計算速度が数倍になっただけじゃない。扱うデータは毎日増えるから、実際は数十倍~数百倍かそれ以上になってるはず。
これ、DB視点でいうと、何ペタバイトなの?っていう話になって、それを全世界で2年分かそれ以上保存しますっていうんだから、ディスク容量がまず桁違い。この時点で自分で構築しようとは思いません。

ただ、これが自社だけで使うアクセス解析ツールなら、生ログを直接計算すればいいから、ほぼリアルタイムで状況を見れる。これがApacheのWebalizerとか、インストール型のアクセス解析ツールになりますよ、と。そういうこと。

ツールとしてはとんでもない高性能なんだけど、使う人のニーズはまた別で、やっと表示した情報について「あれが足りない」「これが足りない」と言っては、エクセルでクロス集計してみたりAPIたたいてみたりと色々やっています。そこは解析じゃなくて分析の領域ですね。

話は戻って、自分で作ることを考える

  1. アクセストラッキング(JSタグ)
  2. 生ログを保存
  3. 保存されたデータを統計情報に
  4. コンバージョン情報を計算
  5. 統計情報を表示

まず、アクセス解析屋がやりたがるのは1だと思います。_gaq._push("_trackPageview")みたいなメソッドを用意して、自前で作ったからRyownet._trackPV();みたいにかっこつけたがるよね。実際ここはGAを丸パクリしてメソッドだけ定義すればいいと思う。方針としては、とにかくJSで投げる。ということ。
2は、投げられたデータを受ける部分。コンバージョンのトラックが実際のビジネスのマネーと同じ価値を持つとしたら、200億球投げられたボールを1度たりとも落とすことは許されない、そういう世界です。DB設計の話。
で、3。DBから一定期間で区切ってデータを取り出して、集計して、おそらく別のDBに入れるところ。数百万件のログを計算するところだから、ここは実はそんなに難しくない。
4は、統計情報とは別に、管理画面でコンバージョンページを設定されていたら、それにマッチするかを判定する計算。この時点で生ログは捨ててもいいんじゃないかな。
で、5。実際のGAの画面になります。ここも、ただグラフとか表を出すだけだとショボイので、ユーザが使いやすいように設計するのが大事。

Web解析Hacksという本では、3の計算方法や上記の考え方を提示してくれるけど、おそらく考えないといけないことはそれだけじゃないよね、と思ったのが本エントリのきっかけでした。

結論

  • 自前で作るもんじゃない。
  • データの流れを意識することで、ga.jsでやりたいことが見えてくる(これは後でまとめようかな)

Home > 07.実践編 > Google Analyticsみたいなのを自分で作ろうと思ったけど考えただけで挫折したメモ

このページの上へ