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

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

用戶在訪問互聯(lián)網(wǎng)的時(shí)候，會(huì)向服務(wù)器發(fā)送服務(wù)的請(qǐng)求。發(fā)送的請(qǐng)求，就被服務(wù)器以一條單獨(dú)記錄的方式記錄在服務(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項(xiàng)構(gòu)成，上面的例子中有兩項(xiàng)空白，但整行內(nèi)容仍舊分成了9項(xiàng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· 不能記錄頁面的操作，尤其是點(diǎn)擊的操作。

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

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

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

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

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

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

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

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

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