<mark id="r6le5"><output id="r6le5"><button id="r6le5"></button></output></mark>
    1. <ol id="r6le5"></ol>

      網站分析:網站數據是怎么來的?

      Category:創越網站建設     更新時間:2014-05-13 15:11      點擊:

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

        
       
        想要進行網站數據的分析,就先要知道網站數據是怎么來的。
       
        
       
        用戶在訪問互聯網的時候,會向服務器發送服務的請求。發送的請求,就被服務器以一條單獨記錄的方式記錄在服務器的日志中,這就是最原始的網站數據日志。
       
        
       
        先看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等的頁面會被分別請求,導致打開一個頁面的請求數并不一定是1,這也是原始日志的一些弊端。
       
        
       
        同時,這些記錄主要是為了跟蹤服務器狀態和服務器安全的,還有一些數據沒有被記錄下來。
       
        
       
         頁面的之間的關系沒有被記錄下來,用戶到底是從那個頁面訪問哪個頁面的關系沒有。
       
        
       
         不能區分出一個用戶來的某一次訪問來,尤其是對不需要就能訪問的網站。
       
        
       
         不能記錄頁面的操作,尤其是點擊的操作。
       
        
       
        于是一些網站制作了自己的記錄方法,一般是用JS或者一個一像素圖片的請求去記錄這些些信息。
       
        
       
        這樣有幾個信息又被記錄下來了,訪問的來源頁面refer,session的編號,cookie的編號,以及點擊所產生的數據。并且這些數據可以被直接記錄進數據庫里面。
       
        
       
        采用這樣的方式,的確降低了分析的難度,并且增加了可分析的信息,但是確是犧牲了一定的準確性?芍^是有得有失。
       
        
       
         首先是可記錄的數據,由于是在客戶端產生的,所有凡是出現服務器錯誤的情況,數據100%會丟失,服務器根本沒有相應,怎么能出數據呢!并且,由于需要啟動了js才能呢高進行數據的傳送,所有數據也會有一定的丟失,一般,服務器狀態不差的情況下,98%的準確率是可以被接受的。
       
        
       
         來源頁面的數據還是會丟失,由于頁面間跳轉和協議的關系,來源頁面中有一定的量會出現丟失的問題, 比較麻煩的是https的頁面由于是采用加密的協議進行傳輸的,無論采用什么方法,到http的頁面上都會丟失。
       
        
       
         受頁面語言和協議的影響比較大,頁面上的調用,ajax,js什么的都可能影響的記錄的準確性。
       
        
       
         最后是所有頁面都要加上代碼,別小看這點,如果是頁面多的話,這點上還真是個問題,那個頁面如果是忘記了,都會去整體的數據產生影響。
       
        
       
         找不到機器的IP,這點上的IP和日志上IP有一些區別,在某些多機器共用IP的情況下,記錄的不是用戶最終機器上的IP而是互聯網接入路由上的IP。
       
        
       
        綜合以上,網站分析上面,由于數據的取得方式和網站本身的程序方式的關系比較復雜,所以在分析網站數據的時候,需要比較謹慎,數據中的故障和陷阱隨時都可能發生
      (責任編輯:創越網絡)



      創越網絡是全國品牌形象塑造專家,致力提供高端品牌網站建設, SEO網站優化, 網站推廣, 網站策劃以及 外貿網站建設網絡營銷免費咨詢等服務;我們能讓企業品牌更有力量.

      欧美肥老太交性视频,亚洲综合在线视频自拍精品,中文无码字幕在线观看,伊伊人成亚洲综合人网 国产在线精品AV观看| 少妇高潮惨叫正在播放| 国产少妇人妻 在线播放| 欧美牲交A欧美牲交AⅤ| 国内真实大量偷拍视频| 日日摸天天碰免费视频| 久久这里只精品国产99RE66| 欧美 亚洲 国产 视频 小说| 一本到高清视频在线观看| 伊人大杳蕉青青视频| А∨天堂网地址| 久久婷婷国产综合色啪| 波多野结衣高清无码中文| 乱中年女人伦视频| 色拍拍在精品视频在线| 偷窥国产亚洲女爱视频在线| 在线福利小视频 无码| 欧美AV在线观看| BT天堂WWW| 伊人大杳蕉青青视频| 欧美肥胖老妇做爰|