網(wǎng)站分析:網(wǎng)站數(shù)據(jù)是怎么來的?

想要進(jìn)行網(wǎng)站數(shù)據(jù)的分析，就先要知道網(wǎng)站數(shù)據(jù)是怎么來的。

用戶在訪問互聯(lián)網(wǎng)的時候，會向服務(wù)器發(fā)送服務(wù)的請求。發(fā)送的請求，就被服務(wù)器以一條單獨記錄的方式記錄在服務(wù)器的日志中，這就是最原始的網(wǎng)站數(shù)據(jù)日志。

先看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的標(biāo)準(zhǔn)日志。

這行內(nèi)容由9項構(gòu)成，上面的例子中有兩項空白，但整行內(nèi)容仍舊分成了9項。

· 第一項信息是遠(yuǎn)程主機的地址。也就是訪問者本機器的IP。服務(wù)器就是根據(jù)這個IP給訪問者發(fā)回復(fù)的信息的。

· 第二項是空白，用一個”-”占位符替代。實際上絕大多數(shù)時候這一項都是如此。這個位置用于記錄瀏覽者的標(biāo)識，這不只是瀏覽者的登錄名字，而是瀏覽者的 email地址或者其他唯一標(biāo)識符。這個信息由identd返回，或者直接由瀏覽器返回。很早的時候，這個位置往往記錄著瀏覽者的email地址。然而，由于有人用它來收集郵件地址和發(fā)送垃圾郵件，所以它未能保留多久，很久之前市場上幾乎所有的瀏覽器就取消了這項功能。因此，到了今天，我們在日志記錄的第二項看到email地址的機會已經(jīng)微乎其微了。

· 第三項也是user。這個位置用于記錄瀏覽者進(jìn)行身份驗證時提供的名字。當(dāng)然，如果網(wǎng)站的某些內(nèi)容要求用戶進(jìn)行身份驗證，那么這項信息是不會空白的。但是，對于大多數(shù)不要求登錄驗證的網(wǎng)站來說，日志文件的大多數(shù)記錄中這一項仍舊是空白的。

· 日志記錄的第四項是請求的時間。這個信息用方括號包圍，而且采用所謂的”公共日志格式”或”標(biāo)準(zhǔn)英文格式”。因此，上例日志記錄表示請求的時間是2005年3月18日12:21:42。時間信息最后的”+0800″表示服務(wù)器所處時區(qū)位于世界標(biāo)準(zhǔn)時間之后的8小時，事實上國內(nèi)服務(wù)器的時間都是+8000。

· 日志記錄的第五項信息或許是整個日志記錄中最有用的信息，它告訴我們服務(wù)器收到的是一個什么樣的請求。該項信息的典型格式是”方法 資源 協(xié)議”。

在上例中，方法是GET，其他經(jīng)?？赡艹霈F(xiàn)的方法還有POST和HEAD。此外還有不少可能出現(xiàn)的合法方法，但主要就是這三種。

資源是指瀏覽者向服務(wù)器請求的文檔，或URL。在這個例子中，瀏覽者請求的是”/stats/awstats.pl?config=user “。

協(xié)議通常是HTTP，后面再加上版本號。

· 日志記錄的第六項信息是狀態(tài)代碼。它告訴我們請求是否成功，或者遇到了什么樣的錯誤。大多數(shù)時候，這項值是200，它表示服務(wù)器已經(jīng)成功地響應(yīng)瀏覽器的請求，一切正常。一般地說，以2開頭的狀態(tài)代碼表示成功，以3開頭的狀態(tài)代碼表示由于各種不同的原因用戶請求被重定向到了其他位置，以4開頭的狀態(tài)代碼表示客戶端存在某種錯誤，以5開頭的狀態(tài)代碼表示服務(wù)器遇到了某個錯誤。

· 日志記錄的第七項表示發(fā)送給客戶端的總字節(jié)數(shù)。它告訴我們傳輸是否被打斷（即，該數(shù)值是否和文件的大小相同）。把日志記錄中的這些值加起來就可以得知服務(wù)器在一天、一周或者一月內(nèi)發(fā)送了多少數(shù)據(jù)。

· 日志記錄的第八項記錄的是客戶在提出請求時所在的目錄或URL。這次的是”http://10.1.1.1/pv/”即10.1.1.1的pv目錄下的首頁。大多數(shù)情況下，首頁會是在httpd.conf中DocumentRoot 指令后面規(guī)定的那些類型和名字的web文件。

· 日志記錄的第九項表示客戶端的詳細(xì)信息。

上面是apache日志的記錄的解釋。

那么換成是IIS的日志呢！　記錄也大同小異，只是由identd返回的登錄身份驗證，由于一直是空的，變成了發(fā)送或者接受的cookie內(nèi)容，還有多了一些協(xié)議的子狀態(tài)的內(nèi)容。

從上面可以看到，我們所有分析的大部分?jǐn)?shù)據(jù)都可以得到了，但是還是有一些問題，用戶點擊瀏覽器上的前進(jìn)和后退按鈕，客戶端的瀏覽器是先讀取緩存的，只有在緩存找不到的情況下，才重新向服務(wù)器請求，所以服務(wù)器是否能記下用戶點擊了后退或者前進(jìn)之后的頁面，完全看頁面的寫法和本機的狀態(tài)。

采用原始日志進(jìn)行分析的，一些分的很小的ifram等的頁面會被分別請求，導(dǎo)致打開一個頁面的請求數(shù)并不一定是１，這也是原始日志的一些弊端。

同時，這些記錄主要是為了跟蹤服務(wù)器狀態(tài)和服務(wù)器安全的，還有一些數(shù)據(jù)沒有被記錄下來。

· 頁面的之間的關(guān)系沒有被記錄下來，用戶到底是從那個頁面訪問哪個頁面的關(guān)系沒有。

· 不能區(qū)分出一個用戶來的某一次訪問來，尤其是對不需要就能訪問的網(wǎng)站。

· 不能記錄頁面的操作，尤其是點擊的操作。

于是一些網(wǎng)站制作了自己的記錄方法，一般是用JS或者一個一像素圖片的請求去記錄這些些信息。

這樣有幾個信息又被記錄下來了，訪問的來源頁面refer，session的編號，cookie的編號，以及點擊所產(chǎn)生的數(shù)據(jù)。并且這些數(shù)據(jù)可以被直接記錄進(jìn)數(shù)據(jù)庫里面。

采用這樣的方式，的確降低了分析的難度，并且增加了可分析的信息，但是確是犧牲了一定的準(zhǔn)確性?？芍^是有得有失。

· 首先是可記錄的數(shù)據(jù)，由于是在客戶端產(chǎn)生的，所有凡是出現(xiàn)服務(wù)器錯誤的情況，數(shù)據(jù)100%會丟失，服務(wù)器根本沒有相應(yīng)，怎么能出數(shù)據(jù)呢！并且，由于需要啟動了js才能呢高進(jìn)行數(shù)據(jù)的傳送，所有數(shù)據(jù)也會有一定的丟失，一般，服務(wù)器狀態(tài)不差的情況下，98%的準(zhǔn)確率是可以被接受的。

· 來源頁面的數(shù)據(jù)還是會丟失，由于頁面間跳轉(zhuǎn)和協(xié)議的關(guān)系，來源頁面中有一定的量會出現(xiàn)丟失的問題，　比較麻煩的是https的頁面由于是采用加密的協(xié)議進(jìn)行傳輸?shù)?，無論采用什么方法，到http的頁面上都會丟失。

· 受頁面語言和協(xié)議的影響比較大，頁面上的調(diào)用，ajax，js什么的都可能影響的記錄的準(zhǔn)確性。

· 最后是所有頁面都要加上代碼，別小看這點，如果是頁面多的話，這點上還真是個問題，那個頁面如果是忘記了，都會去整體的數(shù)據(jù)產(chǎn)生影響。

· 找不到機器的IP，這點上的IP和日志上IP有一些區(qū)別，在某些多機器共用IP的情況下，記錄的不是用戶最終機器上的IP而是互聯(lián)網(wǎng)接入路由上的IP。

綜合以上，網(wǎng)站分析上面，由于數(shù)據(jù)的取得方式和網(wǎng)站本身的程序方式的關(guān)系比較復(fù)雜，所以在分析網(wǎng)站數(shù)據(jù)的時候，需要比較謹(jǐn)慎，數(shù)據(jù)中的故障和陷阱隨時都可能發(fā)生。