|
|
webalizerでアクセス解析
|
Webアクセス解析とはWebalizer日本語版の導入Webalizerの基本設定httpdログの構造を理解するApacheでログを振り分ける検索文字列の日本語化統計データの見方について解析データの最適化と分析法解析スケジュールの設定デフォルト以外のアクセス解析 |
"月の統計"データの見方とポイントWebブラウザ から Webalizer の解析結果のページにアクセスして最初に表示されるページは、過去一年間の統計データを月ごとに集計したものです。 Webalizerは数値だけではなく、色分けされたグラフでデータを表示します。 ですので、個々のデータの意味はよくわからなくても眺めているだけでなんとなく雰囲気はおわかりになると思います。 もちろん、サイトのアクセスアップにつなげるためには、これらのデータの意味をきちんと理解しなければならないことはいうまでもありません。
Webalizerの年間利用統計のページ(グラフ) 詳細な数値データはグラフの下に掲載されています。 この 赤 く囲んであるパラメータをそれぞれ分析することで、 コンテンツ の大まかなアクセスの状態を把握することができるようになります。 "Hits"〜ログに記録されたすべてのアクセス数 |
||||||||
この
お便利サーバー.com
のアクセス解析結果を公開中ですのでご覧ください。
お便利サーバー.com
検索ロボット
|
全部のログデータの集計ということは、実際に コンテンツ が要求されたわけではなく、ただ パケット が送られてきた数字もカウントされますし、存在しない URI への要求に対してエラーで応えた場合もカウントされます。 つまりこの数字は、 ・コンテンツの全体的な露出度の指標 ・他の統計データを分析する場合の分母としての数値 という二つの意味を持つ数字です。 Webalizerではこの数値を修正するオプションはありません。 よく、ホームページの人気の度合いを示す場合に 「月間○○万ヒット」 という場合はこの数値のことを指します。 |
||||||||
|
例えば
"Hits"
の値を増やしたければ、10倍くらいになら簡単に増やせるということです。
例えばトップページに大きな写真を貼っているなら、これを縦横5分割の細切れにしてテーブルにレイアウトすれば、あっという間に25倍の "Hits" が稼げるというわけですね。 |
ただこの説明だけでもうお解りと思いますが、例えば文字データだけの HTML ファイルへの要求の場合は 1ヒット ですが、アイコンやサムネール画像が100枚貼り付けられたHTMLファイルへの要求があった場合は、同じ1ページでも 101ヒット と集計されます。 そしてこの曖昧な数字にエラーなどの「意味のない数」を加えたものが "Hits" ですから、この値だけで人気度を推し量ることがいかに「意味のないこと」かはお分かりだと思います。 "Files"〜正常に送られたファイルの数HTTP リクエストに対して正常に出力できたファイルの数を示します。 つまり "Hits" から、ただの動作確認 パケット やエラーとして処理された ログ データを除いた数ということになります。 つまりこの二つの差が大きい場合には、 ・意味のないリクエストの割合が多い ・エラーの割合が多い ということになります。 また、この値は "Hits" と同じく、たくさんの画像ファイルが添付されたページへの要求に対しては大きな数値がカウントされますから、この値だけで人気度を推し量るのはよくありません。 Webalizerではこの数値を修正するオプションはありません。 "Pages"〜正常に送られたページの数HTTP リクエストに対して正常に出力できたページの数を示します。 ホームページのアクセス数として使われる ページビュー(PV) と呼ばれる指標は、一般にこの値を指します。
Webalizer
はアクセス解析の実行の際に、設定ファイルの中の
"PageType"
ディレクティブ
従って、 "Hits" や "Files" と比較すると、かなり高い精度で コンテンツ の人気度を表すことができます。 また、 "Files" の値を "Pages" で割れば、そのコンテンツの 1ページの表示に必要な平均ファイル数 を求めることができます。 "Visits"〜訪問したクライアントの数
"VisitTimeout"
ディレクティブ
実際のところ、この 「30分を一回の訪問とみなす」 という基準は、 コンテンツ の性格によっては長すぎるかもしれませんし、短すぎるかもしれません。 しかし現実問題としてはこの時間を正確に求めることはできませんし、他のコンテンツとの比較を行う場合にこの 「30分」 という数値が異なってしまうと、比較の基準値そのものが疑わしくなっていまいますから、安易に変更することはお勧めしません。 一般に、 "Pages" を "Visits" で割った数値は 平均ページ閲覧数 と呼ばれ、 「クライアントが訪問して去るまでに閲覧したページ数」 を表すといわれています。 アクセス解析の一般論として、 「平均ページ閲覧数」が少ない場合は、コンテンツが来訪者の興味を惹く内容になっていない という解説がなされているケースが多いのですが、それは必ずしも正しい分析ではありません。 例えばページ構造がわかりやすいコンテンツであれば、来訪者が目的とするページまで最短のステップでたどり着くので「平均ページ閲覧数」は少なくなります。 逆にやたら深い階層構造だったり、目的地がわかり難いページ構造だったりすると、訪問者は目指すページにたどりつくまでサイト内をうろうろさまようことになりますから、「平均ページ閲覧数」は見かけ上多くなります。 という訳ですから、大事なのは「平均ページ閲覧数」の絶対的な値ではなく、その 変化 を読み解くことにあります。 例えば、ページの内容そのものは変わっていないに、構造やメニューレイアウトを変更して「平均ページ閲覧数」が大きく上がるようであれば「訪問者に余計な手間をかけさせるようになってしまった」と考えることができます。 |
||||||||
| 初めてそのコンテンツに訪れた人は、コンテンツの構造がまだよくわかっていないため、比較的多くのページを開くことが多いわけですね。 |
また例えば "Visits" の数は横ばいなのに、「平均ページ閲覧数」が徐々に下がっている場合は「常連の閲覧者は確保できたが新しい訪問者を呼び込めなくなっている」、ということを意味しているのかもしれません。 これはアクセス解析に関して常にいえることですが、解析の結果得られる様々な数値は、コンテンツの内容と構造と質によって解釈を変えなければなりません。 ただ少なくとも "Visits" の数字が下降する傾向にあるときは、 「新規の常連の獲得数より、既存の常連の退去数が多くなった。」 ということを意味するのは間違いありません。 |
||||||||
この
お便利サーバー.com
のアクセス解析結果を公開中ですのでご覧ください。
お便利サーバー.com
検索ロボット
|
それは例えば同じテーマでありながら自分のコンテンツより優れたライバルサイトが出現したとか、そのテーマ自身が陳腐化して情報の価値が失われつつあるとか、そういう理由が考えられるわけです。
このように、
"Pages"
と
"Visits"
は、アクセス解析において非常に重要な意味を持ちますから、ログデータの収集方法
"Sites"〜新規クライアントの推定数新規にアクセスのあった クライアント からの訪問数を表します。 |
||||||||
| 実は、この数値の詳しい求め方はわかりません。ま、知らなくてもどうということはありませんが。 |
要するに、過去にアクセスのなかった IPアドレス からの ログ に基づいた指標です。 しかし、日本国内向けの コンテンツ 運営では、この数値は何の意味も持たないことがお解りでしょうか?。
日本のインターネット利用ユーザーの大部分は、非固定のIPアドレスで接続契約を行っています
|
||||||||
|
|
つまり「同じIPアドレスからの接続は同じクライアントからの接続とみなす」という前提そのものが現実と合っていないわけですから、その結果にも何ら信頼が置けないというわけです。 という理由から、この値をアクセス解析の材料にする意味はありませんので無視してかまいません。 この "Sites" の値が意味を持つのは、潤沢なグローバルIPアドレスを所有していて、クライアントに固定のグローバルIPアドレスを供給している 米国 内からのアクセスに限られます。 Webalizer は米国生まれですので、米国以外の多くの国がグローバルIPアドレスを動的にやりくりしていて数の少なさを補っているということを考慮していないのだと思われます。 というわけですから、よく、 「"Sites"の値が減少を始めたら、新規クライアントの獲得が滞り始めた証拠。」 という解説を見かけますが、これをそのまま鵜呑みにしてはいけないということはお解りと思います。 "KBytes"〜サーバーから送り出したデータ容量クライアント からの要求に対して Webサーバー から送信したデータ容量の合計を表します。単位は KB です。
これが、自宅で契約しているインターネットの「上り」通信速度によって配信可能な容量
しかし、ここで表記される容量はあくまで「累積値」です。 コンテンツ へのアクセスは時間によって非常に変動が大きいのですが、自宅の通信速度はほぼ一定ですので、実際には後ほど説明する「時間帯ごとの "KBytes" 」を解析することになります。
|
||||||||
"月の統計"の詳細データの見方とポイントWebブラウザ から Webalizer の解析結果のページにアクセスして最初に表示されるページから、 "月" 以下に表示される任意のリンクをクリックすると、月ごとの統計データ一覧と更に詳細な解析データが表示されます。 矢印で示しているのは、上で説明した一覧表のデータがそのまま転記されているだけのフィールドです。
(1)〜(4)
のフィールドは解析結果の集計値です。その内容については
(5) の 「一時間あたりのヒット数」 は、その月の "Hits" の値の一時間あたりの平均値と、その月の任意の一時間の中で最も大きかった値を示します。 (6) の 「一日あたりのKBytes数」 は、その月の "KBytes" の値の一時間あたりの平均値と、その月の任意の一時間の中で最も大きかった値を示します。
|
|||||||||
"レスポンスコードごとのヒット数"について"月の統計"の詳細データから少し下にスクロールしたところに掲載されているのが "レスポンスコードごとのヒット数" です。
これは、
レスポンスコードは3桁の数字で表され、非常にたくさんの種類がありますが、最初の桁の数字がその大まかな処理内容を表します。 1xx:(Informational)〜処理を継続リクエストに対して処理が可能であること、あるいは処理が実行されたことを示します。その処理とは プロトコル の変更などの「手続き」に関するもので、実際のデータの送信に関しては他のステータスコードが当てられます。 2xx:(Successful)〜処理に成功リクエストに対して処理が正常に行われたことを意味します。通常このコードの中では、「リクエストに対して サーバー から普通にデータ送信を行うことができた」ということを表す "200:(OK)" が最も多いのが普通です。 上の例では200番台でもうひと種類 "206:(Partial Content)" が少しばかり記録されていますが、これは「リクエスト(GET メソッド )を部分的に受け入れた」ということを示します。これは例えば応答処理が終了する前に クライアント 側で受信を中断したようなケースとなります。 3xx:(Redirection)〜不完全ながら処理に成功クライアント からのリクエストが不完全で、リクエストに答えるには更に必要な作業がある(あった)ことを示します。少し意味がわかり難いでしょうから、上の例で4つのログが記録されている "301:(Moved Permanently)" について説明してみましょう。 |
|||||||||
この
お便利サーバー.com
のアクセス解析結果を公開中ですのでご覧ください。
お便利サーバー.com
検索ロボット
|
例えばクライアント側が
http://www.obenri.com/_webalizer/
でリクエストすべきところを、最後のスラッシュ "/" を付け忘れて、
http://www.obenri.com/_webalizer
とリクエストしたとします。 こういう場合、本来ならそういう名前のファイルは存在しないためのエラーになってしまうところですが、 Apache は末尾に "/" を補ってリクエストに答えようとします。もちろんこの場合は結果としてきちんと応答できることになります。つまり、 「クライアントからのリクエストに忠実ではなかったが、ちょっと工夫して正常に処理できた。」 というわけです。 |
||||||||
| クライアントが プロキシサーバー を利用している場合でも、プロキシサーバー上のコンテンツキャッシュが利用されれば同じステータスコード "304" が記録されます。 |
もう一つの "304:(Not Modified)" は、一般に非常に数が多いステータスコードです。 これはクライアント側のパソコンに コンテンツ の キャッシュ データがあり、そのデータと サーバー 上のデータの タイムスタンプ が一致したために「サーバー上のデータが変更されていなかった(Not Modified)。」と判定されたことを意味します。 こういう場合パソコンはサーバーからのデータ送信を受けることなくキャッシュデータをそのまま利用しますから、この流れをサーバー側からみれば、 「リクエストどおりにデータを送信することはなかったが、別の方法で結果的にうまく対応できた。」 ということになり、このステータスコードが記録されるわけです。 つまりこの "3xx:(Redirection)" は、世間的な表現で言えば 「結果オーライ」 というべきステータスコードと理解すればよいでしょう。 4xx:(Client Error)〜リクエストのエラークライアント 側からのリクエスト内容に誤りがあり、リクエストに対してエラー処理を行った場合のステータスコードです。 "400":(Bad Request) は、無効なリクエストや サーバー 側が仕様として対応する手段を持たない場合のコードで、通常は僅かに記録されるだけですからあまり気にする必要はありません。 最も多いのは「リクエスト先の URI が存在しなかった」ということを表す、 "404":(Not Found) です。 もちろんクライアント側の URL のタイプミスなどの、「サーバー側には責任のないエラー」も幾分ありますが、例えば自分の コンテンツ 内でページ移動するためのリンクが間違っているとか、コンテンツ構造を大幅に変更した結果、検索エンジンへ登録内容やクライアントのパソコンの中のブックマークが正常なリンク先を示さなくなったとか、実際にはサイト管理者のミスや運用上の不可抗力などで発生する数のほうが多いはずです。 従って、コンテンツのリニューアルなどを行っていないにも係わらず、この "404":(Not Found) の数値が "200:(OK)" に比較して大きい場合には、コンテンツ内のリンク状態を再チェックする必要があるでしょう。 例えば、 "404":(Not Found) ÷ "200:(OK)" の値が 0.05(5%) だとすると、あなたのコンテンツを閲覧しているユーザーは、20クリックに1クリックは「ページが見つかりません」を見ることになる、あるいはページ上で写真等のデータを表示すべきところの20個に1個が × になる、ということを表していますから、ユーザーにかなりのストレスを与えていることになるはずだからです。 また、 CGI を多用するページで注意をしたいのは "403":(Forbidden) です。これは主にCGIの設置に必要なファイルやディレクトリの パーミッション に誤りがある場合に記録されるステータスコードです。 世の中には、パーミッションで制限をかけているディレクトリに無理やり入ってみようとする悪い人もいますから、CGIを設置すると幾分このステータスコードが記録されるようになるのが普通です。 ただ、あまりにも数が多いときにはCGIの設置の仕方そのものに問題がある可能性がありますのでチェックが必要となります。 閲覧のために認証が必要なディレクトリのあるコンテンツを運用している場合、認証がうまくいかなかったときは上の例のように "401":(Unauthorized) が記録されます。
上の例はApacheのユーザー認証の実験
|
||||||||
|
クラッキングを試してまで欲しいと思うネット上の
「宝物」
って、いったい何でしょうか。
私にはよくわかりません(←ウソツキ)。 |
もちろんユーザーの単純なタイプミスということも考えられますが、いかにも「宝物」が隠してありそうなコンテンツの場合には結構な数の "401":(Unauthorized) が記録されるはずです。 このように "4xx" は、クライアント側の責任とコンテンツ側の不首尾、どちらの場合にでも記録されるステータスコードです。 場合によっては、 ログ ファイルを閲覧して原因を探し、対処しなければならないことがありますので、この数値の増減には特に注意を払ってください。 5xx:(Server Error)〜サーバーのエラークライアント からのリクエストには何の問題もないのに、 サーバー 側の都合で正常な応答ができなかった場合に記録されるステータスコードです。 |
||||||||
この
お便利サーバー.com
のアクセス解析結果を公開中ですのでご覧ください。
お便利サーバー.com
検索ロボット
|
上の例では
"5xx:(Server Error)"
のステータスコードは記録されていませんが、
CGI
などの
サーバーサイドアプリケーション
を利用するときに、
スクリプト
の書式や文法に誤りがあったり、実行属性
通常運用される コンテンツ では、 "5xx:(Server Error)" の中で記録されるステータスコードはほぼ間違いなく "500(Internal Server Error)" なります。 この場合はもう完全に コンテンツ 側に原因があるわけですから、少しでもこのステータスコードが記録された場合には早急に対処しなければなりません。
|
||||||||
"日ごとの統計"データの見方とポイント"レスポンスコードごとのヒット数" のすぐ下に掲載されているのが "日ごとの統計" のグラフと集計表です。 これは、このページの最初に説明した、 "Hits" 、 "Files" 、 "Pages" 、 "Visits" 、 "Sites" 、 "KBytes" の各データを、一日毎に集計したものです。 各データの右側の "%" は、現在までに集計されたその月のデータ数に対する割合を示します。 |
|||||||||
| ご覧の通り、お便利サーバー.comは完全に「平日型」のコンテンツですね。 |
この統計データを参照することにより、運営中の コンテンツ が平日型なのか休日型なのかを知ることができますし、日にち単位でのアクセス状況の増減を知ることもできます。
|
||||||||
"時間ごとの統計"データの見方とポイント"日ごとの統計" のすぐ下に掲載されているのが "時間ごとの統計" のグラフと集計表です。 これは、このページの最初に説明した、 "Hits" 、 "Files" 、 "Pages" 、 "KBytes" の各データを、その月のすべてのデータを時間帯ごとに集計したものです。 各データの右側の "%" は、24時間を100%とした各時間のデータ量の割合を示します。 |
|||||||||
|
ご覧の通り、お便利サーバー.comは完全に「勤務時間・授業時間型」のコンテンツですね。
昼休みに一度アクセスが落ちるのが興味深いです。 「お昼ごはんでも食べながらのんびりと眺める。」という訳にはいかないのでしょうね。こういう「くどい」サイトの場合。 |
この統計データを参照することにより、運営中の コンテンツ が昼型なのか夜型なのかを知ることができます。 また、このページの始めのほうで少し触れましたが、コンテンツに人気が出て閲覧者が増えてくると、アクセスが集中する時間帯にはかなりのデータ量を WAN 空間に送り出さなければならなくなります。 例えば実質的な最大上り通信速度が1 Mbps の ADSL の場合、この数値を KB に換算すると 125KB/秒 となります。 そしてある時間帯の "KBytes" の値が 180MB/時 だとすると、 180,000(KB)/3600(秒)=50KB/秒 となりますから、 HTTP アクセスのピーク時には、全通信量の 50(KB/秒)/125(KB/秒)×100=40% が利用されるということになります。 というわけですから、この%が100に近づくに従って、コンテンツを閲覧しているクライアント側では「このサイトは表示が遅いなあ。」という時間帯が発生することになります。 もしもHTTPによるサービスを重視するのであれば、こういう状態になってきたら FTTH への契約変更を考えなければならないかもしれません。
|
|
|
検索文字列の日本語化
<<Previous
|
Next>>
解析データの最適化と分析法
|
| このサイトは既に更新を終了していますが、今のところ店じまいの予定はありません。 リンクフリー ですので、趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。 |
| ”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。 |