熱線電話：13121318867

登錄
首頁精彩閱讀網站數據是如何記錄的_數據分析師
網站數據是如何記錄的_數據分析師
2015-01-15
收藏

網站數據是如何記錄的_數據分析師


想要進行網站數據的分析，就先要知道網站數據是怎么來的。
 
用戶在訪問互聯網的時候，會向服務器發送服務的請求。發送的請求，就被服務器以一條單獨記錄的方式記錄在服務器的日志中，這就是最原始的網站數據日志。

 
先看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，其他經?？赡艹霈F的方法還有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等的頁面會被分別請求，導致打開一個頁面的請求數并不一定是１，這也是原始日志的一些弊端。
 
同時，這些記錄主要是為了跟蹤服務器狀態和服務器安全的，還有一些數據沒有被記錄下來。
·      頁面的之間的關系沒有被記錄下來，用戶到底是從那個頁面訪問哪個頁面的關系沒有。
·      不能區分出一個用戶來的某一次訪問來，尤其是對不需要就能訪問的網站。
·      不能記錄頁面的操作，尤其是點擊的操作。
 
于是一些網站制作了自己的記錄方法，一般是用JS或者一個一像素圖片的請求去記錄這些些信息。
 
這樣有幾個信息又被記錄下來了，訪問的來源頁面refer，session的編號，cookie的編號，以及點擊所產生的數據。并且這些數據可以被直接記錄進數據庫里面。
 
采用這樣的方式，的確降低了分析的難度，并且增加了可分析的信息，但是確是犧牲了一定的準確性?？芍^是有得有失。
 
·      首先是可記錄的數據，由于是在客戶端產生的，所有凡是出現服務器錯誤的情況，數據100%會丟失，服務器根本沒有相應，怎么能出數據呢！并且，由于需要啟動了js才能呢高進行數據的傳送，所有數據也會有一定的丟失，一般，服務器狀態不差的情況下，98%的準確率是可以被接受的。

·      來源頁面的數據還是會丟失，由于頁面間跳轉和協議的關系，來源頁面中有一定的量會出現丟失的問題，　比較麻煩的是https的頁面由于是采用加密的協議進行傳輸的，無論采用什么方法，到http的頁面上都會丟失。

·      受頁面語言和協議的影響比較大，頁面上的調用，ajax，js什么的都可能影響的記錄的準確性。

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

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

綜合以上，網站分析上面，由于數據的取得方式和網站本身的程序方式的關系比較復雜，所以在分析網站數據的時候，需要比較謹慎，數據中的故障和陷阱隨時都可能發生。

一種方式是在點擊上埋點的方式，在點擊的代碼中加入一些代碼，例如seed=“submit“ 這樣的代碼， 跟蹤的JS在用戶點擊的時候向數據記錄的服務器回發數據代碼的記錄。這樣的埋點可以放在有跳轉產生的鏈接上，也可以放在例如checkBOX這樣的控件上。
 
這樣操作的好處是：
        ·成本相對比較低，在整個頁面的操作上，由于用戶的點擊一般不超過頁面記錄的兩倍，所以這個數據的傳輸量并不是很大。
        · 可以記錄用戶絕大多數的操作記錄，并且可以根據數據分析很多的數據問題。
        · 記錄丟失量很小，由于是用戶觸發的操作，這個數據99.5%以上可以被記錄下來。
這個方案存在的一些問題：
        · 沒有埋點的空點擊無法記錄；
        · 所有監控的頁面位置都需要進行埋點的處理，這對開發來說是一定的成本。
        · 只能知道用戶點擊行為，但是不知道這個行為是在那個位置發生。
 
另一種方式是采用點擊記錄的方式，通過頁面上的觸發器，鼠標每次點擊的時候，向服務器請求一個信息。并且擺放在鼠標當前的坐標上。
 
這樣操作的好處是：
        · 無需要對頁面進行其他的處理，只要進行添加整體的代碼就可以。
        ·  可以記錄到詳細的每一個點擊的行為，只要用戶是在這個頁面上點擊操作都可以記錄，即使用戶是在頁面上空點。
這個方案存在的一些問題：
        · 頁面的成本很高，需要監控頁面上的所有點擊行為，這對頁面本身的壓力就很大，甚至很可能因此而改變用戶的行為。
        · 記錄量增大，用戶的行為產生的數據量遠大于上一個方案中的數據。
        · 頁面代碼的要求增高，因為是根據坐標定位的，所以定位需要注意。
        · 數據處理極其復雜，受瀏覽器，屏幕分辨率，CSS代碼等問題影響較大。這點的分析上，必須結合瀏覽器內核和分辨率進行分析。例如自適應的頁面，你很可能發現用戶在某個位置有空點擊，而事實上，在他的分辨率下，按鈕正好是在那個位置上。
 
在應用上，記錄第一種方案的信息就已經夠分析了。第二個方案主要是用在A/B的test上。
 
以一個例子說明各個方式之間的差別：
 
例如分析瀏覽器的刷新，點擊瀏覽器的刷新會產生一個本頁面到本頁面的跳轉，在頁面上點擊鏈接也可能產生一個本頁面到本頁面的跳轉，以B頁面命名刷新的頁面。A頁面上有到B頁面的一個鏈接。
 
        ·      在服務器日志的記錄上可能沒辦法區分出本頁面到本頁面的跳轉，因為上面根本沒有來源頁面，連著的B頁面的記錄，可能是在A頁面上點擊B的鏈接，，第一次出現B頁面，之后刷新B頁面。也可能是兩次的在A頁面上點擊B頁面的鏈接。
        ·      但是使用了js或者圖片的跟蹤系統以后，通過來源頁面就可以找到這類的數據，如果來源頁面是B和當前頁面也是B，那么可以證明是B頁面到B頁面自身的跳轉。但是這個刷新是來自于頁面的點擊，還是瀏覽器上的刷新，就不得而知了。
        ·      靠著埋點的方式，如果是頁面上的點擊的話，則會在B頁面到B頁面，這條記錄之前有一個頁面的點擊記錄。如果存在點擊記錄，則證明用戶是在B頁面上點擊了一個鏈接，如果是沒有這個點擊記錄，則證明用戶點擊的是瀏覽器的刷新。
 
事實上，點擊記錄可以做到的事情更多，如果可以在埋點的命名上作一些規則的話，多窗口的操作等等信息，都可以根據埋點的信息分析到。
 
綜合以上， 那么如果你想監控網站的安全，日志信息就足夠了，如果是想監控網站訪問的數據，只要監控的JS就可以了， 但是如果想知道用戶的點擊行為，就需要在可以點擊的位置上埋點了。


CDA數據分析師考試相關入口一覽（建議收藏）：

? 想報名CDA認證考試，點擊>>>   “CDA報名” 了解CDA考試詳情；

? 想學習CDA考試教材，點擊>>> “CDA教材” 了解CDA考試詳情；

? 想加入CDA考試題庫，點擊>>> “CDA題庫” 了解CDA考試詳情；

? 想了解CDA考試含金量，點擊>>> “CDA含金量” 了解CDA考試詳情；

數據分析

數據分析咨詢請掃描二維碼

若不方便掃碼，搜微信號：CDAshujufenxi

上一篇圖論在大數據分析中的作用！
下一篇CDA認證再升一檔！與國家共同推進大數據人才培養標準教育事業！
數據分析師考試動態
CDA報考指南
數據分析學習
數據分析師資訊
更多

CDA教育閉環

常見問題

關于我們

CDA數據分析師公眾號

  • CDA數據分析師公眾號

CDA考試中心小程序

  • CDA考試中心服務號

CDA數據分析師App下載

  • CDA數據分析師App下載
Copyright © 2015-2021, www.ruiqisteel.com All Rights Reserved. CDA數據分析師(北京國富如荷網絡科技有限公司) 版權所有 京ICP備11001960號-9 京公網安備 11010802034615號 經營許可證編號：京B2-20210330
聯系電話：13321103290 (微信同號)

OK
客服在線
立即咨詢
日韩人妻系列无码专区视频,先锋高清无码,无码免费视欧非,国精产品一区一区三区无码
客服在線
立即咨詢