想要進行網站資料的分析，就先知道網站資料是怎麼來的。
用戶在存取網路的時候，會向伺服器發送服務的請求。傳送的請求，就被伺服器以一條單獨記錄的方式記錄在伺服器的日誌中，這就是最原始的網站資料日誌。
先看apache的日誌
10.1.1.95 - user [18/Mar/2005:12:21:42 +0800] “GET /stats/awstats.pl?config=user HTTP/1.1″ 200 899 “http://10.1.1.1/pv/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)”
以上是一條apache的標準日誌。
這行內容由9項構成，上面的例子中有兩項空白，但整行內容仍舊分成了9項。
· 第一項資訊是遠端主機的位址。也就是訪客本機器的ip。伺服器就是根據這個IP給訪客回覆的訊息的。
· 第二項是空白，以一個「-」佔位符取代。實際上絕大多數時候這一項都是如此。這個位置用於記錄瀏覽者的標識，這不只是瀏覽者的登入名字，而是瀏覽者的email地址或其他唯一識別碼。這個資訊由identd返回，或直接由瀏覽器返回。很早的時候，這個位置往往會記錄瀏覽者的email地址。然而，由於有人用它來收集郵件地址和發送垃圾郵件，所以它未能保留多久，很久之前市場上幾乎所有的瀏覽器就取消了這項功能。因此，到了今天，我們在日誌記錄的第二項看到email地址的機會已經微乎其微了。
· 第三項也是user。這個位置用來記錄瀏覽者進行身份驗證時提供的名字。當然，如果網站的某些內容要求使用者進行身份驗證，那麼這項資訊是不會空白的。但是，對於大多數不要求登入驗證的網站來說，日誌檔案的大多數記錄中這一項仍舊是空白的。
· 日誌記錄的第四項是請求的時間。這個資訊用方括號包圍，而且採用所謂的「公共日誌格式」或「標準英文格式」。因此，上例日誌記錄表示請求的時間是2005年3月18日12:21:42。時間資訊最後的”+0800″表示伺服器所處時區位於世界標準時間之後的8小時，事實上國內伺服器的時間都是+8000。
· 日誌記錄的第五項資訊或許是整個日誌記錄中最有用的信息，它告訴我們伺服器收到的是一個什麼樣的請求。此項資訊的典型格式是「方法資源協定」。
在上例中，方法是GET，其他常可能出現的方法還有POST和HEAD。另外還有不少可能出現的合法方法，但主要就是這三種。
資源是指瀏覽者向伺服器請求的文檔，或URL。在這個範例中，瀏覽者請求的是「/stats/awstats.pl？config=user 」。
協定通常是HTTP，後面再加上版本號碼。
· 日誌記錄的第六項資訊是狀態代碼。它告訴我們請求是否成功，或遇到了什麼樣的錯誤。大多數時候，這項值是200，它表示伺服器已經成功地回應瀏覽器的請求，一切正常。一般地說，以2開頭的狀態代碼表示成功，以3開頭的狀態代碼表示由於各種不同的原因用戶請求被重定向到了其他位置，以4開頭的狀態代碼表示客戶端存在某種錯誤，以5開頭的狀態代碼表示伺服器遇到了某個錯誤。
· 日誌記錄的第七項表示傳送給客戶端的總位元組數。它告訴我們傳輸是否被打斷（即，該數值是否和檔案的大小相同）。把日誌記錄中的這些值加起來就可以得知伺服器在一天、一週或一月內發送了多少資料。
· 日誌記錄的第八項記錄的是客戶在提出請求時所在的目錄或URL。這次的是「http://10.1.1.1/pv/」即10.1.1.1的pv目錄下的首頁。大多數情況下，首頁會是在httpd.conf中DocumentRoot 指令後面規定的那些類型和名字的web檔案。
· 日誌記錄的第九項表示客戶端的詳細資訊。
上面是apache日誌的記錄的解釋。
那麼換成是IIS的日誌呢，記錄也大同小異，只是由identd返回的登入身份驗證，由於一直是空的，變成了發送或者接受的cookie內容，還有多了一些協議的子狀態的內容。
從上面可以看到，我們所有分析的大部分資料都可以得到了，但是還是有一些問題，用戶點擊瀏覽器上的前進和後退按鈕，客戶端的瀏覽器是先讀取快取的，只有在快取找不到的情況下，才重新向伺服器請求，所以伺服器是否能記下使用者點擊了後退或是前進之後的頁面，完全看頁面的寫法和本機的狀態。
採用原始日誌進行分析的，一些分的很小的ifram等的頁面會被分別請求，導致打開一個頁面的請求數並不一定是1，這也是原始日誌的一些弊端。
同時，這些記錄主要是為了追蹤伺服器狀態和伺服器安全的，還有一些資料沒有被記錄下來。
· 頁面的之間的關係沒有被記錄下來，使用者到底是從那個頁面訪問哪個頁面的關係沒有。
· 不能區分出一個使用者來的某一次造訪來，尤其是對不需要就能造訪的網站。
· 不能記錄頁面的操作，尤其是點擊的操作。
於是一些網站製作了自己的記錄方法，一般是用JS或一個一像素圖片的請求去記錄這些些資訊。
這樣有幾個資訊又被記錄下來了，訪問的來源頁面refer，session的編號，cookie的編號，以及點擊所產生的資料。而這些資料可以直接記錄進資料庫裡面。
採用這樣的方式，的確降低了分析的難度，並且增加了可分析的信息，但是確是犧牲了一定的準確性。可謂有得有失。
· 首先是可記錄的數據，由於是在客戶端產生的，所有凡是出現伺服器錯誤的情況，數據100%會遺失，伺服器根本沒有相應，怎麼能出數據呢！而且，由於需要啟動了js才能呢高進行資料的傳送，所有資料也會有一定的遺失，一般，伺服器狀態不差的情況下，98%的準確率是可以接受的。
· 來源頁面的資料還是會遺失，由於頁間跳轉與協定的關係，來源頁面中有一定的量會出現遺失的問題，比較麻煩的是https的頁面由於是採用加密的協定進行傳輸的，無論採用什麼方法，到http的頁面都會遺失。
· 受頁面語言和協議的影響比較大，頁面上的調用，Ajax，js什麼的都可能影響的記錄的準確性。
· 最後是所有頁面都要加上程式碼，別小看這點，如果是頁面多的話，這點上還真是個問題，那個頁面如果是忘記了，都會去整體的數據產生影響。
· 找不到機器的IP，這點上的IP和日誌上IP有一些區別，在某些多機器共用IP的情況下，記錄的不是用戶最終機器上的IP而是互聯網接入路由上的IP 。
綜合以上，網站分析上面，由於資料的取得方式和網站本身的程序方式的關係比較複雜，所以在分析網站資料的時候，需要比較謹慎，資料中的故障和陷阱隨時都可能發生。
文章來源：蘭思的記錄本