ruby+MongoDBで、ログ解析システムを着々と作っておりますが、集計用のスクリプトを書く前に、必要な分析方法について整理します。
おおよそのアクセスログ分析は、うまくデータを変換すれば、一般的なデータマイニングの手法や、多変量解析の手法を応用できると考えています。ただし、一つだけ分析できない重要なことがあります。
それは「サイトの導線」を評価することです。
アクセスログ（というより行動ログ）の特性として、全てのヒットに対して、時間情報を持っているという点が挙げられます。そして、時間の前後関係が重要な意味を持っています。
つまり、一つのデータセット（セッション、もしくはUU)の中に、時系列情報が内包されており、さらにデータ全体の中に時系列情報が含まれているという2重構造になっています。
よく為替や経済データなどで使われる時系列分析では全く対応ができません。
あえて、難しく書きましたが、言いたいことは単純で、
・セッションレベルで、ユーザーがどんな順序でページを見ているのかが重要
・全体レベルで、日別・週別などのトレンドデータも重要
というだけです。
そして、「サイトの導線」を評価するうえで、前者の情報が特に重要だということです。
後者だけであれば、既存の時系列分析もある程度応用できると思います。
ただし、一般的なウェブアナリストにとっては、このようなことを意識する必要性はほとんどないです。というのも、大抵の解析ツールで意識せずとも両方のデータを抽出できてしまうからです。
（その一方で、データマイニング系の分析は全くといっていいほど、できないですが。。。）
ということで、自分でログ解析システムを作っちゃえと考えているような、ちょっとおかしな人のため（主に自分のため）にサイト導線の評価方法についてまとめます。
■データの準備
まずはセッションレベルで、分析できるようにデータの下ごしらえが必要です。
Apacheログのデータをセッションキー（IP+UserAgent)でまとめて、以下のような形式でDB上に保存しています。
cookieでセッション・UUの管理を行っている場合は、cookieをセッションキーとして方が当然良いと思います。
（MongoDBを利用しているので、データ形式はJSONです）
{
“_id” : 【ObjectId】,
“ip_ua” : [【セッションキーの配列】],
“page” : [【ページの配列】 ],
“refer” : [【リファラーの配列】 ],
“time” : [【時間の配列】]
}
”_id”以外のプロパティについては、”time”でソートして、時間順に並び替えています。
たとえば、
トップページ（/) → 会社情報ページ (/about/) → 製品ページ (/product/)
という順番で閲覧したセッションは以下のように保存されます。
{
“_id” : “xxxxxxx”,
“page” : [“/”, “/about/”, “/product/”],
“refer” : [“google.com”, “”, “”],
“time” : [“11:01:10”, “11:01:30”, “11:02:15” ]
}
データ圧縮のため、サイト内のリファラーは削除しています。
“page”だけデータを抜き出すと、SiteCatalystのフルパスレポートと同様なデータになります。
リファラー情報、時間情報も同列で保存しているので、入口別のリファラーや、各ページの滞在時間も取得することができます。当然、セッションの滞在時間も計算できます。
ちなみに、フルパスレポートは組み合わせの爆発が起こるので、パターン数としては膨大なものになります。100ページしかないサイトの場合でも数万パターンに上ることもあります。
それでも、あえて言いますが、生データの状態で上位10パーセント程度は読み込んだほうが良いと思います。実際のユーザーの動きを読み込んで、いかに当初想定していたユーザーシナリオ通りにユーザーが動いていないということを認識すべきです。大体のユーザーの流れがわかった上で、分析を行うと、分析が深まります。
■基本的な分析：ページレベル
ページレベルで分析を行う際には、まず前後ページの分析を行うことが第1歩です。
それぞれのページで
・該当ページを閲覧する前にどのページを見ていたか？（前ページ）
・該当ページの次にどのページを閲覧したか？（次ページ）
の2つを明らかにすることが目的です。
主要なインデックスページや、ランディングページを対象とします。
前ページは、サイト内とサイト外の2つのパターンがあり、基本的な考え方としては、
- 該当ページが、セッションの「入口」となった場合は、リファラーを見て、サイト外からの流入として、計測する
- 「入口」以外の場合は、ページの閲覧順序を見て、前ページを計測する
という2段階の計測が必要です。全てリファラーだけで完結させようとすると、痛い目に合いますので注意しましょう（理由は今度書きます）。
次ページについては、
- 該当ページがセッションの「最後のページ」となった場合は、そのページで「離脱」とみなす
- それ以外は、閲覧順序の次ページを計測する
というパターンになります。もし、JavaScriptで外部リンクのクリックを取得している場合は、離脱の内訳として利用しても良いと思います（数値の辻褄を合わせることは難しいですが）。
アウトプットイメージはこのようになります。
シンプルでわかりやすいモデルとなるので、あまり詳しくない人に対しても有効です。
ポイントとしては、このモデルに対して、「フィルター」をかけることができるようにすることが重要です。ランディングページを分析する場合は、「入口ページ」となった場合のみのデータは是非みたいところです。当然ユーザーのセグメント（新規・再訪など）ごとにデータが見れると素敵です。
■基本的な分析：セッションレベル
セッションレベルでの分析で、特に重要なものは事前に設定した直線的なシナリオに対しての検証です。入力フォーム関連の導線分析でよく使われます。いわゆるコンバージョンファネルです。
これもシンプルでわかりやすいモデルですが、集計方法に注意が必要です。
集計方法は2通りあります。
A. 単純に各ページのセッション数を測定
B. ページ閲覧順序を考慮して測定
Aの方法を採用する場合は、測定対象とするページが、完全に直線的なナビゲーション構成になっている必要があります。測定途中のページで、対象ページ以外から多くの流入がある場合は、計測の意味が全くなくなります。
Bの方法は、対象ページをチェックポイントとして指定し、指定したとおりの「順序」で通過した場合のみ、計測するという方法です。通常はこちらの集計方法を採用します。
「順序」というのがポイントで、同じ順序であれば、間に別のページを通っていても良いという考え方です。
たとえば、チェックポイントを
A → B → C → D
とした場合、
A → B → X → C → A → X
という場合には
A → Bと、B → C という遷移のみ有効としてカウントされます。
B → A → C
という場合は、指定した順序通りになっていないので、全てカウントされません。
B → A → C → B
という場合には、A → Bへは指定順序通りなのでカウントされます。
一見、シンプルでわかりやすいのですが、数値を正確に説明しようとすると苦労するという、ありがちがな分析方法ではあります。
■ 導線分析の応用に向けて
ここまでは、多くの解析ツールで既に実装されており、今更な感じがあります。ただ、結果のわかりやすさと、分析の意味を考えると、どうしても必要な機能になります。というか、これだけで十分といえば十分です。
でも、ここではやめません。次回以降、別の分析方法について考えます。ここから先は、詳しくない人に説明しても全く理解されません。完全に自己満足の世界です。
