みなさん、こんにちは！　ニコライです。

今回はWebサーバの生ログを使ってアクセス解析を行う場合の注意点をまとめてみました。我々Webアナリストがアクセス解析をする場合、お客様がお使いの解析ツールを使わせて頂くか（アカウントを発行して頂きツールにアクセスする）、またはWebサーバの生ログをお預かりして解析するか（生ログを自社に持ち帰り、手持ちのツールで解析する）の2つに分かれます。最近は専ら前者のパターン（特にGoogleAnalyticsとSiteCatalystが多い）がほとんどなのですが、後者の生ログ式でご依頼頂くこともあります。官公庁系のお客様や、アクセス情報を社内のサーバにストックしておきたい業種（金融など）のお客様は、特に生ログでのご依頼が多いようです。また業界問わず、お持ちの解析ツールではできないような深掘りがしたいといった理由で、生ログを持ち込まれるお客様もおられます。

生ログによる解析処理は、お客様のツールを使う場合と比べて、作業を進めるうえでの注意すべきポイントが異なります。それは、生ログそのものがそもそも解析可能な状態にあるのかを確認するところから始めなければならないため、"データを読み解いて示唆を出す"という本来の作業に至るまでの工程が別途必要になるためです。そして、この事前確認が意外に重要だったりするのです。実際、生ログの状態によっては、最悪まったく解析できないということもあることから、こういったリスク要因を理解しないまま営業トークだけが先行してしまうとトラブルのもととなります。

今回は、生ログを使ったアクセス解析プロジェクトを失敗させないために、Webアナリストに求められるチェックリストを12項目にわたってまとめてみました。ターゲットとしている読者は新人Webアナリストですが、自力で生ログ解析にトライしようとされているWeb担当者様にも参考にして頂ければ幸いです。「要点だけつまみ読みしたい！」という方は、各見出しと概要だけ見て下さい。

12のチェックリスト

①解析対象期間の生ログが残っているか？
②ログのオーバーフローが起きていないか？
③解析に必要な情報が記録されているか？
④解析可能なログ形式になっているか？
⑤クライアントのIPアドレスが正しく記録されているか？
⑥解析対象のアクセス情報を抽出できるか？
⑦SSLログ内の個人情報はマスキングしているか？
⑧生ログの受け渡し方法と工数はどの程度か？
⑨Cookie情報が生ログに記録されているか？ (アトリビューション分析に必須)
⑩SetCookieが記録されているか？ (アトリビューション分析に必須)
⑪サーバサイドでCookieを発行しているか？ (アトリビューション分析に必須)
⑫Cookieの有効期間が適切か？ (アトリビューション分析に必須)

①解析対象期間の生ログが残っているか？

【概要】
「Webサイトがあるなら、生ログもある」とは言い切れません。解析に必要な期間の生ログが存在するのかを確認する必要があります。

【詳細】
アクセス解析の要件をもとに集計期間を定めたら、その期間のログが残っているか、情シス部門などに確認しましょう。「Webサイトができて5年になるから、5年分のログはあるだろう」などと早合点してはいけません。企業のログ運用ポリシーによっては、必要な期間のログが入手できない可能性も考えられることから、これらを事前に確認しておくことが重要です。ポリシーは企業様によって様々で、「Webサイト創設以来ずっとログを残しています」という場合や、「最新の3か月分以外は破棄します」という場合もあります。まずはお客様のポリシーを確認し、解析要件を満たせるか否かを判断する必要があります。

【確認方法】
情シス部門に、解析対象期間のログが残っているか確認する。

【対策】
もし社内にログが残っておらず、且つ中長期的な視点でアクセス解析のプロジェクトを進めていこうとするなら、情シス部門にかけあって、ログの運用ポリシーを見直してもらうということも必要になるでしょう。
情シス部門には、"生ログ＝マーケティングデータ"という認識がないことが多く、それ故に、サーバ運用の一環としてログのポリシーが定められていることが専らです。なぜログデータが必要なのか、ポリシーをどう変更してほしいのか（3か月保持→1年保持に変更する など）を伝えたうえで、ポリシーの見直し(*1)を打診しましょう。

(*1) 「たかだか保存期間を変えるだけで、"ポリシー見直し"なんて大仰な」と感じられる方もいるかもしれませんが、ログデータのファイルサイズは非常に大きいことから、変更による影響を調査したり、バックアップのオペレーションを見直したりといった作業が発生することがあります。単にサーバの設定をチョチョっと変えるだけでOKというわけにはいきません。あくまでもWebサイトの規模やサーバ構成によりますが、ポリシーの見直しには時間を要する可能性があるため、変更の必要がある場合は早めに情シス部門へ打診するようにしましょう。

②ログのオーバーフローが起きていないか？

【概要】
サーバ環境によっては、解析対象期間のログファイルにデータの欠落が発生している可能性があります。データに不備がないかどうか、それによって解析に影響を与えないかどうかを確認する必要があります。

【詳細】
アクセス解析に必要な期間の生ログが残っていたとしても、まだ安心はできません。特定の期間のログ情報が抜け落ちていないか（ログデータに欠落がないこと）を確認する必要があります。お客様のサーバ環境によってはログのオーバーフローが発生するケースがあり、これが原因でログの一部が欠落してしまいます。オーバーフローとは、ログが記録されているハードディスク容量の逼迫が原因でログの一部が記録されなくなる現象を指します。オーバーフローが発生すると、ログデータが虫食いのような状態になってしまうことから、欠落している部位やその大きさによって、目的としていた解析ができなくなる恐れがあります。ここでは、とあるお客様（仮にA社とします）での事例をもとに、具体的な症状について説明します。

オーバーフローが発生していたA社様の事例

Webサーバのアクセスログは、1つのログファイルに数か月分ものログを記録するようなことはせず、管理者が定めた集計期間単位にアーカイブされていきます。この設定値の一般的な閾値は、「1日」と設定されることが多いようです。つまり、「1か月分の生ログがある」といった場合、「1日分のアクセスが記録されたログファイルが30日分ある（30個のログファイルがある）」という状態が一般的だと思われます。A社様では、この集計期間を1週間とされていましたが、Webサーバのハードディスクは1週間分のログを1度にため込んでおけるほどの空き容量がなかったようで、週の後半（水曜日の午後くらいから）はログデータが溢れてしまい記録が残らないという状態になっていました。



図のグレーアウトされているエリアが、ログが欠落している部分です。A社様では過去10年分の生ログがストックされていましたが、上記のように虫食い状態のログしか残っていませんでした。こうしてみると、A社様のログは本来の50%程度しか記録が残っていない状態でした。せっかく長期間にわたるデータを蓄積しているのに、非常にもったいないことだと思います。

ちなみにA社様でサーバ管理をしている現場の担当者は、この問題に以前から気づいていたようですが、抜本的な解決策は検討してこなかったようです。これも前述の通り、「生ログはマーケティングに活用できる会社の資産」という認識が得られていないことが原因だと思われますので、情シスの部門もマーケティング活動に巻き込んで、彼らの協力を得られるチーム体制を作ることが必要でしょう。

私は、情シス部門のマーケティングに対する認識が足りない点について、「しっかりしろ」とか「勉強不足だからダメだ」と言いたいのではありません。マーケ、情シスそれぞれの強みを持ち寄ってもっと協業してほしいと思います。生ログ分析に限らず、昨今のデジタルマーケティングは、マーケティングと技術の両方に対する知識が不可欠ですので、ぜひ両者はもっと社内でコラボしてほしいなと思います。

【確認方法】
下記の2ステップで確認を行います。
STEP1
お客様からログファイルをお預かりしたら、まずは1ログファイルあたりの集計期間を確認します。ファイル名などから、集計期間がわかるはずです。1日単位なのか、1週間単位なのか（あるいはそれ以外か）はお客様の環境によって異なります。
STEP2
最もファイルサイズの大きいログファイルをテキストエディタで開き、先頭と末尾の行に記録されているログの日時が、STEP1の集計期間と齟齬がないことを確認します。例えば、1ログファイルが1日分のログなら24時間分のログが記録されていなければなりません。先頭行の日時が1/1 0:00なら、末尾の日時は1/1 23:59ぎりぎりまでログが残っていることを確認しましょう。このとき、ログファイル先頭行が0:00から始まるとは限りません。企業様によってはAM9:00から翌AM8:59までという場合もありますので、注意が必要です。また、アクセス数が少ないサイトでは、ログファイルの切れ目となっている時間帯のアクセス数が少なく、オーバーフローなのか、そもそもアクセスがないのか判断が付きにくい場合があります。このときは複数のログファイルを確認することで見極めましょう。

【対策】
仮にオーバーフローが発生している場合でも、アクセス解析の要件によっては、欠落部分を無視して「エイッヤー！」で解析できてしまう場合もあります。例えば、ユーザビリティチェックという観点からログ解析を行う場合です（ログだけではなくヒューリスティックと併せてやりますけどね）。使い勝手を評価するという意味で、ユーザ動線やリンクの押下状況などを見る場合なら、多少ログが欠落していても示唆を導くことができるでしょう。

しかし、プロモーションの効果測定を解析要件としている場合は、欠落のある生ログを使うことはできません。「テレビCMを大量投下した○月○日からのアクセスの推移を見たい」といった場合、対象の日がログから欠落していたら、目的のデータを集計することができないためです。オーバーフローがある場合に解析作業を進められるか否かは、欠落の範囲や大きさと解析要件を照らし合わせて、解析可否の判断をする必要があります。尚、オーバーフローの問題を根本的に解決するためには、ログ運用ポリシーの見直しが必要となります。①の【対策】で記載したように、情シス部門との調整を進めましょう。

③解析に必要な情報が記録されているか？

【概要】
生ログがあるからといって解析ができるとは限りません。IPアドレスやリファラーなど、アクセス解析に必要な情報が生ログに記録されていることを確認する必要があります。

【詳細】

生ログがありさえすれば解析できるわけではない

巷で見かけるアクセス解析ツールの比較表には、タグビーコン型に対する生ログ型ツールのメリットとして、"過去に遡って解析できます"というフレーズを見かけることがあります。GoogleAnalyticsに代表されるタグビーコン型のツールは、タグを貼りつけた時点から解析データの蓄積が始まるのに対して、生ログ型ツールはすでに蓄積されているログを投入するだけで集計結果が得られることから、"過去に遡っての解析"が可能と言えます。

しかし、蓄積されている生ログをアクセス解析に利用できるか否かは、"解析に必要な項目がログに記録されていること"が大前提となります。"生ログさえあれば、解析できるわけではない"ということを、我々アナリストはしっかりと理解しておく必要があります。

アクセス解析をするうえで最低限必要な情報

下記の6項目は、アクセス解析をするうえで最低限ログに記録されていなければならない情報です。
1. クライアントのIPアドレス　~　ユーザエージェントと合わせてセッションの特定に必要
2. リクエストされた時刻　~　リクエストされた順序を知るのに必要
3. リクエスト内容　~　アクセスしたページやパラメータを知るのに必要
4. HTTPのステータスコード　~　リダイレクトや404を解析から除外するのに必要
5. リファラー　~　参照元を知るのに必要
6. クライアントのUser-Agent　~　IPアドレスと合わせてセッションの特定の必要

ちなみにApacheサーバのインストール直後の状態だと、上記項目の1～4までしかロギングされないことから、アクセス解析らしいことはさっぱりできません。「6個のうち4個もログにあるなら、御の字じゃない？」などと考えてはいけません。項目6のユーザエージェントはセッションの特定に用いるものですので、これがないとセッションに付随する解析は一切できなくなります。来訪数（セッション数）、直帰率、コンバージョン数、CVR、サイト内動線　といった指標が解析できません。また、項目5がないことで流入元（ダイレクトアクセスや検索サイト経由など）や検索キーワードを特定する術がなくなります。従って、項目1～4だけで分析できるのはページビューだけで集計可能な指標に限定されます。つまり、「アクセス数の多いページ一覧」程度しかありません。　ね？　御の字じゃないでしょ？

Apacheのコンバインド形式なら最低限の解析が可能

私がここでお伝えしたいのは、「あらゆる情報が生ログに記録されているわけではない」ということです。解析に必要な情報が、ログにきちんと記録されているかを確認する必要があります。幸いにもApacheサーバの場合、前述した解析に必要な項目を全て備えたログ形式というものが存在します。「コンバインド形式」と呼ばれる形式で、httpd.confに標準で定義されています。（ログの書式が定義されてあるだけで、それがデフォルトで有効になっているわけではありませんので注意）

▼コモン形式と呼ばれる書式（デフォルトはこっち。これだと解析不可）

（左から順番に　　IPアドレス、リモートログ名、クライアントのユーザ名、リクエスト時刻、リクエスト内容、ステータスコード、データ転送量）

▼コンバインド形式と呼ばれる書式（設定でこっちに変えられる。これなら解析可能）

（左から順番に　　IPアドレス、リモートログ名、クライアントのユーザ名、リクエスト時刻、リクエスト内容、ステータスコード、データ転送量、リファラー、ユーザエージェント）

※ちなみにパラメータの定義はApacheのWebサイトにてご確認ください。お客様のログが当該形式であるか、またはこれに準じた形式であること（必要な項目が記録されていること）を確認しましょう。通常のアクセス解析であれば、コンバインド形式のログで事足りるはずです。

解析要件によっては、コンバインド形式でもNG

解析要件によっては上記のログ形式でも不十分な場合があるので、そのときはログフォーマットを変更する必要があります。具体的には下記のようなケースです。

▼フィーチャーフォンを解析対象とする場合
携帯電話からインターネット接続する場合、同一セッション内であってもIPアドレスが変動するため、IPアドレス＋ユーザエージェントでセッションを特定することができません。そこでこれらに代わるセッション識別のためのキーが必要となります。一般的にこのキーとして、「個体識別番号」又は「セッションID」が用いられます。前者は端末個々に割り振られている番号であり、後者はリクエストURLにパラメータとして付与される識別情報のようなものです。フィーチャーフォンを解析対象とする場合は、これらの情報がログに記録されている必要があります。

▼スマートフォンを解析対象とする場合
これもフィーチャフォンのケースと同様に、IPアドレス＋ユーザエージェントによるセッション特定が困難であるため、セッションを識別するキーとしてCookieが必要となります。Cookieについては、本記事の「⑨ Cookie情報が生ログに記録されているか？」以降に詳細を記述していますので、そちらもご覧ください。

▼GoogleAnalyticsと同様の指標を解析する場合
GoogleAnalyticsが提供している指標の一部（画面解像度や画面の色など）は生ログ上に残らないため、特別な実装をしない限り解析することはできません。GoogleAnalyticsは、これらのクライアント情報をJavaScript内で収集したうえで、アクセス情報と共にGoogleサーバへ送信しています。生ログで同じことを実現しようとするなら、GAと同じようにJavaScriptでクライアント情報を収集し、1ピクセルの画像データのリクエストパラメータに乗せて、ログに記録するという実装を施す必要があります。（かける労力に対して、得られるものが小さい気がしますが・・・）

【確認方法】
情シス部門に対して、「御社の生ログはコンバインド形式ですか？」と聞くのが手っ取り早くてよいでしょう。仮に独自フォーマットの場合は、フォーマットの書式情報とサンプルログ（生ログから数行を切り取ったもの）を入手し、解析に必要な情報が含まれていることを確認しましょう。

【対策】
お客様の生ログが解析要件を満たしていない場合、「要件をログに合わせる」か「ログを要件に合わせる」かの判断が必要です。お客様と調整をしましょう。後者の場合はログフォーマットを変更する必要があるので、情シス部門と調整する必要があります。ログフォーマットの変更は、前述のオーバーフローが発生する可能性があるため、ログボリューム増加分を試算したり、経過を観察することも必要です。また、フォーマット変更が完成してから生ログの蓄積が始まるので、どのくらいログをストックしてから分析を進めるのか、お客様と調整しましょう。

④解析可能なログ形式になっているか？

【概要】
お客様の生ログが、常にスタンダードな形式であるとは限りません。アクセス解析ツールが読み取れる形式になっていることを確認する必要があります。

【詳細】
アクセス解析に必要な項目がログに記録されていたとしても、その書式によっては解析ツールで読み取れない場合もあります。解析ツールがきちんとパースできる形式になっているかを確認しておきましょう。解析ツールによって読み取りの可否は異なりますが、主に下記の点に注意したほうがよいでしょう。

▼独自フォーマットではないか？
コンバインド形式などのスタンダードなフォーマットから遠く離れた、完全に「わが道をゆく」タイプの生ログも存在します。このようなログの場合は、実際に解析ツールに投入してみて、きちんと読み込めるか否かを確認する必要があるでしょう。

▼IPアドレスが名前解決されていないか？
Webサーバの設定によっては、IPアドレスがドメイン名に名前解決されている場合があります。利用している解析ツールが、当該形式のログを読み込めるか確認しておきましょう。ツールによっては、IPアドレスの形式（xxx.xxx.xxx.xxx）になっていないと、うまく読み込めなかったり、セッションを特定できない可能性があります。また、IPアドレスはアクセスの除外（社内アクセスの除外 / ロボット・スパイダーの除外）に利用されることから、これらの除外処理に支障がないことも確認する必要があります。

▼IPアドレスがIPv6になっていないか？
お客様の環境によっては、生ログ内のIPアドレスがIPv6の書式になっていたり、IPv4と混在しているケースもあります。解析ツールによっては、IPv6のフォーマットに対応していないものもありますので、ログの状態を確認するとともに、ツールで処理可能かを確認しておきましょう。

▼デリミタを含む項目がダブルクォーテーションで囲まれているか？
ログのフォーマットで最も気を付けなければならないポイントが、これ（ダブルクォーテーションで囲む）だと思います。生ログにはIPアドレスやリファラーなど様々な情報が記録されていますが、これらを識別するために、半角スペースの区切り文字（デリミタ）が使用されています。このデリミタがあることで、解析ツールは「レコード左端から○番目のカラムはリファラー」といったことを識別することができます。ただ、ログの出力項目の中には、このデリミタを文字列として含むものがあることから、「区切り文字としてのスペース」なのか、「単なる情報としてのスペース」なのかを区別する必要があります。この制御に用いるのがダブルクォーテーションです。下記図のように、ダブルクォーテーションで囲むことで一つのカラムであることを示しています。



コンバインド形式のログフォーマットを見ると、リファラーやユーザエージェントがダブルクォーテーションで囲まれていることがわかります。

尚、生ログにCookieの出力を追加するような場合も、ダブルクォーテーションで囲む必要があります。

【確認方法】
最も確実な確認方法は、実際に生ログをお預かりして解析ツールに投入してみることです。要点は目検でおさえつつも、1日分程度の生ログをお預かりして、実際に解析可能か検証してみましょう。

【対策】
解析ツールに投入できない場合、生ログそのものを多少加工すれば済む場合もあります（文字列の置換で済むケースなど）。ログフォーマットのどの部分がボトルネックになっているかを調べたうえで、対策を講じましょう。生ログの加工で対応できない場合は、ログフォーマットの変更を行う必要があります。

⑤クライアントのIPアドレスが正しく記録されているか？

【概要】
生ログに記録されているIPアドレスが、社内環境のアドレスではなく、クライアントのIPアドレスになっていることを確認する必要があります。

【詳細】
お客様のネットワーク環境において、負荷分散のためにロードバランサーなどを導入していると、生ログに記録されているIPアドレスが、これらの機器のIPアドレスになっていることがあります。クライアント（ユーザ様）のIPアドレスではなく、社内のIPに置き換わってしまうため、セッションを特定することができなくなります。きちんとクライアントのIPアドレスが記録されているか否かを事前に確認しておく必要があるでしょう。仮にセッションの特定をCookieで行う場合であっても（セッションの特定にIPアドレスを使わない場合でも）、生ログのIPアドレスはクライアントのもの反映している必要があります。それは下記の目的にIPアドレスを利用するためのです。

・ 社内又は関連会社からのアクセス除外
・ アクセス元地域の分析（解析要件による）
・ アクセス元企業の特定（解析要件による。BtoBサイトで分析することが多い）
・ ロボット/スパイダーの排除（ユーザエージェントだけでなく、IPで除外するケースもある）

【確認方法】
一日分程度の生ログをお預かりして、IPアドレス部分をざっと眺めてみましょう。記録されているIPアドレスの種類がユニークで2,3種類しかない場合、または特定のIPアドレスからのリクエストが異常に多い（ログの1/3程度のリクエストが同じIPからのリクエスト等）場合、クライアントのIPアドレスが正しく記録されていない可能性があります。怪しいIPアドレスをピックアップし、情シス部門に尋ねてみましょう。

【対策】
Apacheサーバを利用している場合、IPアドレスのロギングパラメータとして、「%h」ではなく「%{X-Forwarded-For}i」を利用することで、クライアントのIPが記録できる可能性があります。情シス担当者に「X-Forwarded-Forを試してくれ」と伝えてみましょう。たぶん、これでわかってくれるはず。

⑥解析対象のアクセス情報を抽出できるか？

【概要】
解析対象となるWebサイト以外のアクセスが、生ログに混在している可能性があります。ログから、解析対象となるドメインの情報が抽出できることを確認する必要があります。

【詳細】
非常に稀なケースですが、お客様が複数のWebサイトを管理なさっている場合、サーバの設定によっては、複数の異なるWebサイトのアクセス情報が1つの生ログに集約されていることがあります。



上記の例では、サイトＡとＢのリクエストを切り分けることができないため、あらゆる指標を正しく集計することができません。このような事態を避けるためには、「1つの生ログファイルに1つのドメインのみ記録されている」状態にするか、または「リクエスト情報にドメイン名を含んでいる」状態にする必要があるでしょう。この問題は一見して気づきにくいことから、アナリスト自身も見過ごしてしまうことがあります（大概は分析の途中で気づいて青くなるのですが・・・）。"納品直前に気づいて炎上"的な事態にならないよう、生ログの受領時点でお客様に確認しておく必要があります。

【確認方法】
お預かりする生ログファイルは、解析対象のドメインしか含まれていないことを確認するか、または生ログ内にドメイン情報が含まれていることを確認しましょう。

【対策】
仮に複数サイトのアクセス情報が1つのログファイルに混在しており、解析対象のアクセスだけを抽出できない場合は、ログの運用ポリシーから見直す必要があります。情シス部門との調整が必要です。

⑦SSLログ内の個人情報はマスキングしているか？

【概要】
SSLログにはアクセス解析に不要な個人情報が含まれている可能性があります。このような情報は予め隠蔽処理をしてもらうなど、お客様の社外へ出さない工夫が必要です。

【詳細】
お問い合わせフォームやショッピングカートシステム等の決済機能を持つWebサイトでは、SSLログ内にコンバージョンしたユーザの個人情報が記録されていることがあります(*1)。これらの個人情報は、氏名やメールアドレス、TEL等を含んでいることが多く（コマースサイトの場合はクレジットカード番号まで含まれる可能性がある）、極めてプライバシーレベルの高い情報といえます。通常のアクセス解析では、このような個人情報は分析に必要ありませんので、ハイリスクな情報をお客様からお預かりしない（お客様の社外に持ち出さない/持ち出させない）ようにするべきです。弊社を含め、お客様の生ログをお預かりする企業は、相応の情報管理体制を敷いているため、容易く情報が漏えいすることなどはないでしょうが、万が一を防ぐためにも、そもそもハイリスクな情報はお客様からお預かりしないに限ります。
(*1)～SSLログ内に記録されているか否かは、ログ運用ポリシーによって異なるため、すべての企業様のログに個人情報があるわけではありません。

【確認方法】
事前検証のためのログをお預かりする前に、個人情報をマスキング処理（ログから抹消するか、*******などの文字で塗りつぶし処理をする）してもらうようお客様へお伝えしましょう。昨今は社会全体に個人情報保護の考えが浸透しているため、こういったことに無頓着な方はほとんどおられないと思います。しかし、"生ログの中にそういった個人情報が含まれる場合がある"ということをご存じない方はいらっしゃるので、その点をしっかりお伝えし、どのようなリスクが想定されるのか、それを防ぐためにどうすればよいのか（マスキングしてほしい旨）をしっかり説明してご理解頂く必要があるでしょう。

【対策】
お客様の社外に持ち出さない/持ち出させないことが第一義ですので、生ログをお預かりする前にしっかりとマスキングについてご説明しておく必要があります。「サンプルで1日分の生ログをお預かりしたら、個人情報がバッチリ入っていました。」といった事態にならないようにしましょう。

まれにお客様から「マスキングは御社でお願いします」と言われることもありますが、個人情報を社外に出さないことが肝要ですので、丁重にお断りしましょう。マスキング処理そのものは非常に簡単なので、やって差し上げたい気持ちはありますが、お客様社内でマスキング処理を完結してもらうことに意味があります。

⑧生ログの受け渡し方法と工数はどの程度か？

【概要】
生ログの受け渡しには、思った以上に手間と時間を要するものです。レポートの納期にクリティカルな影響を与える可能性があることから、リスク要因や工数を見積もっておく必要があります。

【詳細】

生ログの受け渡しは意外と時間がかかるもの

解析対象となるWebサイトの規模によって、生ログのファイルサイズは簡単に受け渡しができないくらいに大きくなることがあります。メールに添付できてしまうほどの大きさ（2,3MB程度）であれば、大きな問題はありませんが、メディアに焼くのも一苦労な場合は生ログを受領するだけで、数人日も工数を取られてしまう場合があり、これによって分析に充てられる時間が短くなってしまう恐れがあります。

私が関与した案件で、最も大きな生ログをお預かりしたケースは、全体のボリュームが100GBを超えていたことがあります。当然、オンラインでやり取りできるサイズではありませんので、お客様のサーバがある場所までお伺いしてデータ抽出を行いました。これほどサイズが大きい生ログを取り扱うことは稀だと思いますが、数GB単位のログであっても、簡単にオンラインで済ませることはできないため、データの受け渡しだけでお時間を要してしまうことになるでしょう。

ファイルサイズを試算して工数を予見しよう

受け渡しの手間は、生ログのファイルサイズに比例して大きくなるため、事前にファイルサイズの予測ができていれば、「ある程度の手間がかかるな」ということが予見できるはずです。下記の算出式は、WebサイトのPV数から生ログのサイズをシミュレーションするためのものです。



「①ログ1行当たりのサイズ」は、コンバインド形式のログ形式を基準にした場合の、1レコード当たりの大まかなサイズを表しています。350byteをMB単位にしているため、小数点の数値となっています。
「②1PV当たりのリクエスト数」は、画像を含んだリクエスト総数を算出するためのものです。生ログには".html"以外にも".jpg"や".gif"などのリクエストも記録されることから、PVと掛け合わせるにあたり、画像も集計に含めています。
「③Webサイト全体のPV数」は、その名の通りページビュー数を指しています。ヒット数やセッション数ではないので、そこだけ注意が必要です。
「④ロボット等の割増分」は、ロボットのリクエストを加味したものです。一般的なPV数はロボットを除外したものを指しますが、生ログにはそれらのアクセスも含まれるため、集計に含めています。

尚、集計結果は非圧縮状態のログサイズとなります。gzipで圧縮すれば、1/15程度のサイズにまで縮小できることから、実際の受け渡し時にやりとりするサイズは、圧縮時の数値となるでしょう。

上記の式を用いて、数パターンのログサイズを算出してみたものが下記になります。

1万PV ・・・ 圧縮時 - 4MB
5万PV ・・・ 圧縮時 - 21MB
10万PV ・・・ 圧縮時 - 42MB
100万PV ・・・ 圧縮時 - 420MB
500万PV ・・・ 圧縮時 - 2.1GB
1000万PV ・・・ 圧縮時 - 4.2GB

試算結果はログフォーマットや画像の含有数によっても変わってくるため、実際には2~3倍の開きが生じることがあります。上記計算式の目的は、ファイルサイズを精緻に予測することではなく、「メールで送れるレベルか / 焼いて郵送できるレベルか / 取りに行くようなレベルか」ということをざっくり見極めるためのものです。その前提でご利用下さい。

【確認方法】
事前の確認方法は上述の通り。

【対策】
生ログの受け渡しに手間取ることが予想される場合は、解析要件を詰める段階から並行して生ログの手配をしておくなど、納期への影響を小さくするようにしましょう。

⑨Cookie情報が生ログに記録されているか？ (アトリビューション分析に必須)

【概要】
ユニークユーザを長期間に渡ってトラッキングするためには、Cookieが不可欠です。WebサーバがCookieを発行していることと、それが生ログに記録されているかを確認する必要があります。

【詳細】

アトリビューション分析にはCookieが不可欠

さてここからは、特にアトリビューション分析を行う際に必須となるポイントについて説明します。
アトリビューション分析とは、流入元別にコンバージョンへの貢献度を調べる分析手法で、間接効果分析ともいわれることがあります。一般的なアクセス解析では、セッション単位での分析となるため、コンバージョンに至った対象セッションの流入元は評価できても、その来訪者が初めてWebサイトへ訪れた流入元を評価することはできませんでした。そこで個々のセッションに対して、ユニークユーザという一本の串を通すことで、初回来訪からコンバージョンに至るまでの流入元を評価しようというのがアトリビューション分析の基本コンセプトです。

生ログかビーコン型かといった集計方式に関わらず、アトリビューション分析を行うためには、個々のセッションをユニークユーザ（正確にはユニークブラウザですが、以降ユニークユーザと記述します）に対して正確に紐づける作業が必要となります。この際のキーとなるのがCookieです。アクセス解析ツールによっては、Cookie情報がなくても、IPアドレスとユーザエージェントをもとにユニークユーザを識別するものもありますが、高い精度を実現するためにはCookieが不可欠です。なぜなら長期のスパンで見た場合、IPアドレスとユニークユーザは変動する可能性があるため、ユニークユーザを識別する情報として適していないからです。固定IP契約を結んでいない限りIPアドレスは変動しますし、ブラウザのバージョンアップがあればユーザエージェントは変わってしまいます（IEからChromeに変えるケースはCookieでも識別不可。あくまでも同一ブラウザでのバージョンアップに言及しています）。ユニークユーザに力点を置かない分析であれば、IPアドレスとユニークユーザの情報で十分ですが、アトリビューション分析などを行う場合には、これらの識別情報に代わるもの（Cookie）が必要となるのです。



また、サードパーティ製のCookie（オンライン広告の第三者配信に代表されるようなCookie）は、アンチウイルス系のソフトウェアに削除されてしまったり、そもそもブラウザが受け入れてくれない（サードパーティCookieに限って弾く設定になっていることもある）可能性があるため、ユニークユーザの識別には適していません。そのため、Cookieはサードパーティ製ではなく、トラッキング対象となるWebサイトが発行するファーストパーティCookieであることが望ましいでしょう。

Cookieをログに記録すべし

せっかくCookieを発行していたとしても、デフォルト設定のままでは生ログにCookieが出力されることはありません。管理者が「Cookieを出力する」と明示的に設定してあげる必要があります。Apacheを例にするなら、下記のようなログフォーマットに変更すれば、Cookieをログに記録することができます。

赤字の部分がCookie出力に関するパラメータです。

生ログを使ったアトリビューション分析を実施する必要があるときは、「Cookieが発行されていること」と「Cookieが生ログに出力されていること」の2点を確認する必要があります。

【確認方法】
確認するポイントは2つあります。①「そもそもCookieを発行しているか否か」、②「Cookieの値がログに出力されるようになっているか」の2点です。①については情シス部門に直接聞いてもよいですが、実際にWebサイトにアクセスしてみて、Cookieがブラウザに保存されているかを確認してみるのが、手っ取り早くてよいでしょう。②については、生ログを実際に見せて頂くか、またはログ出力の設定フォーマットを確認する必要があります。

【対策】
Cookieをそもそも発行していない場合は、Webサーバ側でCookieを発行するように変更する必要があります。また、生ログにCookieが記録されていない場合も、ログ運用ポリシーの見直しが必要となるため、①の【対策】で記載したように、情シス部門との調整を進めましょう。

ちなみにCookieを吐くように設定変更することは、大した手間ではないのですが、Cookieを生ログ出力するように変更するほうは些か手間がかかります。Webサイトのアクセス規模にもよりますが、Cookieを出力することで生ログのファイルサイズが肥大してしまい、前述したオーバーフローが発生する可能性があることから、ファイルサイズのシミュレーションなどをしなければならないためです。準備には少々時間がかかるので、確認作業はできるだけ前倒しで進めることが望ましいでしょう。また、上述の変更を行う場合、過去のログに対して影響を与えることはできません。つまり、変更を加えた時点から蓄積した生ログがアトリビューション分析に利用できるのであり、それより過去の生ログにはCookie情報を反映させることはできません。この制約をしっかりと踏まえたうえで、お客様と解析要件の調整をする必要があります。

⑩SetCookieが記録されているか？ (アトリビューション分析に必須)

【概要】
Cookieを用いてセッション/ユニークユーザの識別をする場合、「初回来訪時の最初のアクセス」や「各セッションの来訪回数」を識別ための情報（SetCookie）を、生ログに記録する必要があります。

【詳細】

SetCookieとはなにか？

SetCookieとは、Webサイト来訪者のブラウザに対してサーバサイドからCookieを発行した際に、サーバからのレスポンスヘッダで返されるCookie情報のことを指します。誤解を恐れずにもっと簡単に言うなら、Cookieが付与された時のみ発生するイベントのようなものと言えます（正確な表現ではないかもしれませんが・・・・）。Webサイトに紐づくCookieをすでに持っているブラウザに対して、WebサーバがCookieを発行することはないので、「Cookieが付与されるタイミング」というのは初めてWebサイトに来訪したときの最初のリクエストを表しています（有効期限切れやユーザによる操作でCookieが削除された場合も、新規来訪とみなされます）。この"最初のリクエスト"でサーバから返される情報がSetCookieです。

尚、「Cookieをブラウザにセットする」という意味で、「setCookieする」と言われる場合もありますが、ここでは「Cookie付与時にサーバから返される情報」という意味で記載しています。また、ここでの記述はApacheにおいてmod_usertrackモジュールでCookieを発行することを前提にしています。Java（Servlet/JSP）やPHPでの挙動は未検証なので、これらの環境では違った動作になるかもしれませんが、ご了承下さい。

さて、話を戻します！　SetCookieをロギングする理由は、「一番最初のリクエストを識別できるようにする」ことと、「来訪回数を識別できるようにする」ことの2点につきます。まずは前者の「一番最初のリクエストを識別できるようにする」について説明します。

SetCookieが必要な理由　No1「一番最初のリクエストを識別できるようにする」

下記の図をご覧ください。


「α」はCookieを保持していない状態でのリクエスト（つまり初回来訪における最初のリクエスト）を表しています。Cookieを持っていないため、"/index.html"のリクエスト時にCookieが送信されることはありません。サーバサイドではクライアントがCookieを保持していないことを判定し、Cookieを発行します。上記の例では、「UserTrackCD」という名称のCookieを発行しています。

「β」はCookieを保持している状態でのリクエスト（つまり2回目以降のリクエスト）を表しています。Cookieが消失または削除しない限り、この状態が継続します。"/index.html"をリクエストするにあたりクライアントサイドで保持しているCookieをサーバ側へ送信します。サーバサイドでは、クライアントがすでにCookieを保持していることを判定し、Cookieの再発行は行いません。

この「α」と「β」のリクエストを生ログで見ると下記のようになります。
▼ログフォーマット

▼「α」のログ

▼「β」のログ

ログフォーマットでは「"%{cookie}i"」のパラメータにより、リクエストヘッダのCookieを出力するように指定していますが、これだと最初のリクエスト「α」にCookieの値が記録されていないことがわかります。この状態だと、最初のリクエストと2回目以降のリクエストを紐づけることができないため、初回来訪時の入り口ページや流入元などを計測することができません。最初のリクエストにおいてもCookie値をログに記録するためには、レスポンスヘッダにあるSetCookieの情報を出力する必要があります。

SetCookieをロギングすると下記のようなログになります。

▼ログフォーマット

▼「α」のログ

▼「β」のログ

「"%{cookie}i"」がリクエストヘッダのCookie情報を出力するパラメータであるのに対して、「"%{Set-Cookie}o"」はレスポンスヘッダのCookie情報を出力するためのものです。SetCookieのログは、Cookieが発行されたタイミングのみ記録されるものですので、βのログにはSetCookieが記録されていないことがわかります。このようにSetCookieをロギングすることで、ユニークユーザに紐づく最初のリクエストを識別できるようになります。

SetCookieが必要な理由　No2「来訪回数を識別できるようにする」

SetCookieはCookieが発行されたタイミングでのみログに記録されることから、その特性を生かして、ユニークユーザに紐づくセッションの来訪回数を特定することができるようになります。ちょうど下記のようなイメージです。


SetCookieが記録されているセッションを起点にして、それ以外のセッションについて来訪回数を案分できていることがわかると思います。
尚、「わざわざSetCookieなんて使わなくても、ログに最初に登場したセッションを初回来訪とすればいいのでは？」とお考えになる方もいるかもしれません。実際、多くのアクセス解析ツールが、ログ内で最初に登場したセッション（ユニークユーザ単位で）を新規セッションとして集計しています。しかし、アトリビューション分析においては、ユーザの態度変容やWebサイト来訪のきっかけ/タイミングを知ることが重要ですので、初回来訪のタイミングを高精度に判定する必要があるでしょう。下記図のように、ログに最初に登場したセッションを初回とみなしてしまうようでは、有効な示唆を導くことが難しくなります。


ここにあげたポイントは非常に細かな内容ではありますが、アトリビューション分析を行うにあたっては不可欠な要素と言えます。

補足

ApacheにおいてCookieをロギングするためのパラメータは、下記の3種類があります。
%{cookie}n ～　mod_usertrackが内部的に出力するもので、リクエスト/レスポンスとは無関係に出力されます。
%{cookie}i　～　リクエストヘッダのCookieを出力します。（上記解説で使用）
%{cookie}o　～　レスポンスヘッダのCookieを出力します。（上記解説で使用）

前述の解説で、敢えて「%{cookie}n」には触れませんでした。理由は、「%{cookie}n」が最初のリクエストを識別するのには有効でも、来訪回数を識別するのには使えないためです。結局、レスポンスヘッダのSetCookieをロギングしないと問題を解消することができないことから、「%{cookie}n」を使う意味がないため、解説から端折りました。

【確認方法】
生ログにSetCookieが記録されているか（そのようなフォーマットになっているか）を確認する必要があります。情シス部門に依頼してログフォーマットを教えてもらいましょう。下記の書式は一例ですが、Apacheなら「"%{Set-Cookie}o"」があれば、Set-Cookieがロギングされていると判断できます。

ApacheサーバでSetCookieを記録している例

【対策】
SetCookieがログに記録されていない場合は、ログフォーマットを変更する必要があります。情シス部門と調整しましょう。

⑪サーバサイドでCookieを発行しているか？ (アトリビューション分析に必須)

【概要】
初回リクエストや来訪回数を識別するために不可欠なSetCookieをログに記録するためには、サーバサイドでCookieを発行していなければなりません。Cookieの発行場所を確認する必要があります。

【詳細】
Webサイト来訪者のブラウザに対して、Cookieを発行する方法は主に2通りあります。サーバサイド（Webサーバ側）でCookieを発行する方法と、クライアントサイド（JavaScript）で発行する方法です。前項のポイント⑩で、初回来訪を識別するためには、SetCookieというイベントを生ログに記録する必要があることをお話ししましたが、このSetCookieはサーバサイドでCookieを発行しないとログに残すことができません。ApacheでSetCookieをロギングする例を挙げると、httpd.confのLogFormatには「"%{Set-Cookie}o"」のように記載します。当該パラメータは"レスポンスヘッダのSet-Cookieをロギングする"という意味ですので、サーバからの応答としてSetCookieがなければ、ログに記録されません。つまり、JavaScriptなどを使って、クライアントサイドでCookieを発行した場合は、LogFormatのパラメータでログに残すことはできないのです。

【確認方法】
Cookieの発行がサーバサイドなのか、クライアントサイドなのか情シス部門に確認しましょう。または、ログファイルが閲覧できる状態であれば、SetCookieの情報が残っているか確認するとよいでしょう。ちなみにSetCookieの情報は下記のような形でログに残っています。

▼ログフォーマット

▼初回来訪時のログ（SetCookieされる）

▼2回目以降来訪時のログ（SetCookieはされない）

上記ログの赤字部分（Apache=となっている部分）がSetCookieの情報です。ちなみに初回来訪ではサーバサイドで「Apache」という名称のCookieが発行され、クライアントサイドでGoogleAnalytics用のCookieが発行されています。GoogleAnalytics側は「__utma」や「__utmb」といった名前のCookieを発行します。これらのCookieはブラウザのオプション画面から確認することができます。

ただ、上記のログをご覧頂くとわかるように、SetCookieでは「Apache」のCookie情報しか残っていません。クライアントサイドで発行されたCookieはログに出力されないことがわかると思います。2回目以降来訪時のログでは、リクエストヘッダ部のCookie情報として「Apache」と「__utma」等が送信されています。
SetCookieがログに残っているかを確認するには、Cookie名称/path/有効期間で検索をかけてあげます。上記のログなら、「Apache=.*; path=/; expires=」という正規表現にヒットするレコードを検索すればよいですね。ログ内に"Set-Cookie"という文字列が残るわけではありませんので、これで検索してもノーヒットです。注意しましょう。

※ 上記のログはローカルネットワーク内に構築したApacheサーバへの接続検証ログです。お客様の生ログではございません。

【対策】
もし既存のCookieがクライアントサイドで発行したものの場合は、サーバサイドのCookieに切り替えてもらうか、または解析専用に新しいCookieを発行してもらう（無論サーバサイドで）必要があります。既存のCookieをサーバサイドに切り替える方法は検証に時間を要する可能性が高いので、新規にCookieを発行するほうが色んな意味で無難です。情シス部門と調整を進めましょう。

⑫Cookieの有効期間が適切か？ (アトリビューション分析に必須)

【概要】
ユニークユーザを長期間に渡ってトラッキングするためには、Cookieの有効期間を適切に設定する必要があります。解析対象の商材に適した長さに設定されていることを確認しておきましょう。

【詳細】
Cookieには必ず有効期間があり、当該期間を過ぎるか、またはユーザ自身やシステムが削除するまでCookieは存続し続けます。Cookieが存続している間は、ユニークユーザを識別するためのキーがブラウザに紐づいていますが、Cookieの消滅と同時にこのキーはなくなります。Webサイトに再来訪することで再度Cookieが発行されますが、基本的に同じ値のキーが発行されることはなく、また消滅前後のキーを紐づけておくことはできないため、これらは別々のユーザとして扱われます。



ユニークユーザを特定するためのキーがサクサク変わってしまっては問題なので、長期のスパンでユニークユーザをトラッキングし続けるには、一定の長さの有効期間をもったCookieを発行する必要があるのです。また、容易に削除されない（アンチウイルス系のソフトウェアに削除されない）という意味でもファーストパーティCookieのほうが行動トラッキングに適していると言えます。

有効期間の適正値については、Webサイトで取り扱っている「商材の検討～購買までの期間よりも長いこと」が要件になると思われます。不動産や自動車といった単価が高く、検討期間が長い商材の有効期間が2,3カ月では正確なトラッキングはできません。1~2年程度の長さにするのが妥当でしょう。では、逆の発想で目いっぱい有効期限を引き延ばした（有効期限30年などの）Cookieは有効かというと、技術的には可能でも、解析の示唆を得るという観点からは好ましくありません。妥当な検討期間（ここでは1~2年）を超えて再来訪した場合は、そのユーザを既存と捉えるのではなく、新規として扱うほうが示唆を得やすいためです。例えば、10年前にWebサイトを見たことがあるユーザが再来訪した場合、既存と考えるよりも新規と捉えるほうが自然です。

このように無暗矢鱈と長い有効期間にするのではなく、商材の検討期間に合わせた長さを検討する必要があります。（「検討期間の短い商材だから有効期間が短くてよい」とは限りません。当該記事の中だけでは書ききれないので、詳細を知りたい方はお問い合わせください）

尚、サーバサイドで発行しているCookieの有効期間は、発行日からの時限性となっており、再来訪によって自動的に期限が更新されるということはありません。GoogleAnalyticsのCookieは、再来訪時点でCookieが更新され、有効期限が延長される仕組みとなっていることから、どんな場合も「Cookieの有効期間は更新される」という誤解がありますが、これはGoogleAnalyticsに限った仕様ですので注意しましょう。それにしても、勉強すればするほど、GoogleAnalyticsって、よくできたツールだと実感できます。

【確認方法】
Cookieの有効期間を確認するには、ブラウザに保存されているCookie情報を参照しましょう。有効期限が確認できるはずです。

ブラウザによって参照方法は異なりますが、保存されているCookie情報を閲覧することができます。上記は私のプライベートサイトで発行しているGoogleAnalyticsのCookieを参照した画面ショットです。有効期限が2年になっているのが読み取れます。

【対策】
有効期間が短い場合は、Webサーバ側での設定変更が必要となります。解析対象となるWebサイトに適した有効期間を定義した上で、情シス部門と調整して有効期間を変更してもらいましょう。

最後に・・・・

本記事では技術的な観点から、Webアナリストに求められる事前確認のポイントを整理しました。
生ログのアクセス解析に取り組もうとされている方にとって、多少なりとも参考になれば幸いです。

※上記内容の無断転用掲載・酷似記事の出稿はお断りいたします。
※上記を引用する場合は、出典元の明記「（株）Nexal提供」をお願い致します。
※生ログを使ったアクセス解析のご依頼については、問い合わせフォームよりご連絡ください。
（ニコライは日本語が堪能です。英語でお問い合わせ頂く必要はありません！）