關于我們 RRS sitemaps 網站地圖

首頁 > 運營分析 > 正文

SEM論壇

頁面標記法網站分析及數據捕獲原理

2012-05-18 00:23:24 |  評論:0  |  點擊:  |  SEM論壇

 談到網站分析的數據捕獲,大家應該先有一個預備知識,那就是頁面標記法網站分析和日志法網站分析的根本原理是完全不同的。此前有朋友在微博上留言,認為AWStats,Omniture,WebTrends都是日志分析工具,只不過Omniture利用了ASP方式,它們沒有不同。這個觀點是完全的誤解實際上,這三個工具都各不相同。AWStats是日志分析工具,免費。WebTrends最初也是純日志分析工具,但后來增加了Page Tagging(頁面標記)的功能。而Omniture SiteCatalyst則一出生則是以Page Tagging為思路的工具,而且至今Omniture并無面向日志分析的工具。

  因此,今天話題我們只談頁面標記法(Page Tagging)的網站分析獲取數據的原理。我們從一個游戲說起。

什么是頁面標記法

  大家都玩兒過暴雪公司的游戲StarCraft(星際爭霸一代)嗎?我可是這個游戲的狂熱愛好者。蟲族的女王有一個特殊的能力,把一個寄生蟲(parasite)噴在敵人的某個行動單位的身上,這樣這個行動單位走到哪里,他身邊的情況都能被蟲族看的一清二楚,成為一個非常忠誠的間諜。

  或者,大家都去過銀行,銀行里放在四處的攝像頭,把我們的一舉一動其實都拍攝了下來,然后傳遞到儲存裝置中保存起來。

  所以,不恰當的比喻,所謂的頁面標記,就像是“噴給”頁面的寄生蟲,或者是在頁面上安裝的攝像頭,把訪問者在頁面上的一舉一動都記錄下來,然后傳遞給相關的需要了解這個網站的組織或者個人。

  下圖表示了這個過程:

  頁面標記如同圖中紅色的一小塊,實際上是一段可以被瀏覽器執行的JavaScript程序語句,放在頁面的HTML源文件中。這樣,當頁面被下載到客戶端的瀏覽器的時候,這段頁面標記JavaScript程序就會被執行,如同星際爭霸中的寄生蟲上身,或是攝像頭被打開。

  頁面標記的JavaScript代碼被執行之后,就會如實的把訪問者在頁面上的互動訪問行為不間斷的發送給這個頁面標記所對應的網站分析工具的服務器,這與攝像頭把拍攝到的圖像傳送給圖像存儲服務器是完全一樣的。網站分析工具服務器收到數據后,會進一步處理這些數據,并且把數據翻譯成人們能夠閱讀和分析的圖形、表格以及數據文件,然后呈現在一個漂亮的用戶界面上。我們常用的Google Analytics就是這樣一種數據收集方法。

  可以看到,頁面標記方法跟日志方法具有本質上的不同。

  • 日志方法是把日志文件中的數據取出來加以分析;而頁面標記則是需要人為的在頁面中增加一個小的“間諜單位”,也就是說,需要依賴于一個第三方才能獲取數據。
  • 因為這個額外增加的小小“間諜單位”,頁面標記方法需要修改頁面的HTML源文件,而日志方法不需要。
  • 日志方法是被動地等著你來處理數據,你不處理,數據就是一條條忠實而死板的記錄;而頁面標記法則是主動地發送數據,而且會自動把數據預處理好,等著你來分析。

  講到這兒要說點兒歷史了。互聯網的早期,網站的規模較小,結構也簡單,日志方法獨霸天下,但是互聯網的發展太快了,網站的軟硬件體系和邏輯架構很快變得越來越復雜,用日志方法需要克服的困難越來越多,實施起來的難度也成倍增加,人們需要找到一種更簡單的實現方法。隨著JavaScript的普及,SaaS(Software as a Service,軟件即服務)的出現,頁面標記方法應運而生,這個方法實施起來簡單,而且再也不需要去跟海量的日志文件記錄打交道,數據管理和處理的效率極大提升,很快成為眾多站長的首選。正是因為存在諸如簡單易行、數據可讀性高、管理難度低等諸多優勢,頁面標記方法成為網站分析這門科學主流的數據獲取方法

 

頁面標記方法是如何工作的

  我們已經了解了頁面標記方法的基本原理,現在我們要細致學習頁面標記是如何能夠實現數據的收集、傳遞并最終呈現在我們面前的。了解這個過程,對于我們進行網站分析的具體監測實施很有幫助。

第1步,頁面監測代碼被瀏覽器載入并執行

  頁面標記方法能夠正常工作的前提是要在網站中需要監測的每一個頁面中都加入一段JavaScript的監測代碼。當用戶打開這個頁面時,服務器(或者Cache)會響應用戶的請求,然后把頁面,連同監測代碼一起傳遞給用戶的瀏覽器。當用戶的瀏覽器接收到監測代碼,就會開始執行代碼。

第2步,執行完整的監測代碼

  頁面上的監測代碼被執行后,并不能實現全部的監測功能,而是轉而向它所對應的網站分析工具的服務器請求完整的監測代碼。完整的監測代碼語句量較大,因此被集合成一個.js文件存放在網頁的外部。外部代碼一旦收到頁面監測代碼的請求,也會傳遞給瀏覽器,并被瀏覽器執行。這樣,完整的監測功能就能得以實現。

  以我自己的這個博客(CWA, 網站分析在中國, http://www.chinawebanalytics.cn)的GA監測為實例,在完整的監測代碼執行過程中,會有幾件事情發生:

1. 探測客戶端的各種屬性,包括瀏覽器版本,操作系統版本,屏幕分辨率等等,并且記錄下來頁面訪問具體發生的時間,以及訪問的來源(Traffic Source)等等。

2. 為這個用戶的這個瀏覽器建立一個cookie。什么是cookie?簡單說cookie的作用是把用戶這一次訪問這個網站的相關關鍵情況記錄下來,當下次這個用戶再瀏覽這個網站的時候,cookie中的記錄就會作為新的瀏覽記錄的參考,從而能夠讓網站分析工具判斷這次訪問是否是重復訪問,訪問者是不是新的訪問者,以及很多其他的重要數據。cookie在頁面標記監測方法中是必須的,也就是說,如果瀏覽器禁用了cookie,頁面標記方法就不能發生作用。

3. 如果之前已經為這個訪問者的這個瀏覽器建立了cookie,那么監測代碼會把舊的cookie數據中需要更新的部分重寫,這樣保證每次cookie都記錄的是相應的訪問行為的數據。

第3步,傳送數據給網站分析工具的服務器

  當監測代碼收集了全部的信息,這個時候它會把相關的數據的傳回給網站分析工具的服務器。傳送的方式并不是直接把數據發去(即不是用post方法,如果你不了解HTTP協議中的post和get方法,這個括號中的內容可以略過不看),而是通過向網站分析工具服務器請求一個1×1像素的透明GIF圖像來完成的(即仍然是用get方法,不懂同樣請略過)。看起來有有點兒奇怪對嗎?其實在發出這個1×1像素請求的時候,所有收集到的數據都作為這個請求的相關參數被一起發送給了分析工具的服務器,這樣分析工具就能夠獲得并存儲下來相關的數據。

第4步,網站分析工具服務器記錄數據

  網站分析工具服務器收到了數據之后,會把這些數據存放在一個大的數據文件中,這個數據文件的記錄方式和我們前面講到的日志文件(Log File)非常相似,因此,這里我們也就稱它為Log File,不過區別在于,這里來的Log File裝著的不是網站分析工具服務器自己的運行數據,而是被監測的網站的數據。

  這個Log File文件里面的每一個數據行(一條數據條目)都包含了某一個頁面瀏覽(PageView)的很多信息,包括但不限于如下內容(以Google Analytics的Log File記錄文件為例):

  • l 頁面訪問發生的日期和時間;
  • l 訪問的頁面的標題;
  • l 訪問者的來源(是從某個網站鏈接過來的,還是通過搜索引擎,還是通過直接訪問等等);
  • l 這個訪問者訪問這個網站的次數;
  • l 訪問者IP地址的地理位置;
  • l 訪問者客戶端的屬性,例如操作系統、瀏覽器、屏幕分辨率等

  這些記錄一旦被計入到分析工具服務器的日志中,一次數據搜集的工作就結束了。下面這個例子是Google Analytics服務器中記錄的一行數據(請注意并非真實的數據):

123.121.215.51 www.chinawebanalytics.cn – [31/Jan/2010:20:45:26 -0600] "GET

/__utm.gif?utmwv=1&utmn=699988832&utmcs=utf-8&utmsr=1680×1050&utmsc=32-bit&utmul=enus&

utmje=1&utmfl=8.0&utmcn=1&utmdt=%E7%BD%91%E7%AB%99%E5%88%86%E6%9E%90%E5%9C
%A8%E4%B8%AD%E5%9B%BD%E2%80%94%E2%80%94%E4%BB%8E%E5%9F%BA%E7%A1%80
%E5%88%B0%E5%89%8D%E6%B2%BF&utmhid=2006742654&utmr=-

&utmp=/ HTTP/1.1" 200 35 "http://www.chinawebanalytics.cn/" "Mozilla/5.0 (compatible; MSIE 6.0;

Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

"__utma=453698521.699988832.235456888.235456888.235456888.1; __utmb=453698521;

__utmc=453698521;

__utmz=453698521.235456888.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)"

  上面的數據似乎雜亂無章,實際上還是能看出來一些端倪的。例如,能夠看到訪問者的IP地址是123.121.215.51,訪問的域是我的博客www.chinawebanalytics.cn,訪問發起的時間是2010年1月31日的晚上8點45分26秒。另外,如果你耐著性子往后看,你還能看到訪問者所使用的操作系統和瀏覽器的信息。

  

第5步,網站分析工具處理數據

  數據一旦被記錄到網站分析工具服務器的Log File中,流水線就要繼續往下走了。下一個環節是處理這些Log File的中的記錄行,每一個記錄行都包含了具體的數據元素,被稱為字段(field),例如訪問者IP、訪問時間、瀏覽器及其版本等;這些數據元素會被分別打散,然后存入相應的字段中,成為我們最終查看數據的“半成品”。

  接著,數據半成品會進一步被網站分析工具中人為設定的標準篩選,篩選不過的數據字段會被排除掉,剩下的數據會被進一步安排在為生成報告而準備的項目中。所有的這些數據被存放在網站分析工具的專門數據庫中,隨時等待被提取使用。

第6步,生成報告

  當數據都被處理完,整個過程也接近尾聲。如果用戶使用網站分析工具請求某個特定報告,數據字段就會按照預定義(或是用戶自定義)的格式組織被進一步計算、組織、然后被安排在為生成報告而準備的項目中。這個過程我們看不到,但是卻蘊含著一個網站分析工具算法的精妙,并且,算法的定義也影響了一些網站分析基本度量的定義,從而直接影響基本度量的實際值的輸出。這也是造成不同網站分析工具統計同一網站卻帶來不同值的一個重要原因。

  隨后,準備好的數據項目被進一步前推,推送到網站工具的UI(User Interface,用戶界面)的服務器中生成具體的圖、表和數字,然后被進一步輸出到用戶的瀏覽器或客戶端上,成為我們能夠輕易讀懂的報告。

整個過程其實不算復雜,但是網站分析工具會面對大量的數據處理,尤其是當一個網站的流量特別大的時候,網站分析工具會承受很大的負荷。這也是為什么很多網頁標記型的網站分析工具會按照被監測網站的流量大小計取費用的原因。

利用頁面標記方法進行網站分析的優點

  頁面標記法有諸多優點,使之能夠成為主流的網站分析獲取數據的方法。

1. 不怕緩存(Cache)影響

  與日志方法害怕緩存的影響相反,頁面標記法一點也不用擔心緩存的問題。因為頁面標記的代碼是放在頁面源文件中的,即使頁面被代理服務器緩存或是客戶端的瀏覽器緩存保存下來,頁面標記的代碼也會跟著被保存,并且在瀏覽器載入頁面的時候一道被執行。

  因此,如果你先后連續進入了一個網站的幾個頁面,然后又點擊瀏覽器的“后退”按鈕回到上一個頁面,那么在頁面標記方法下,回到上一個頁面的行為會增加這個頁面一個“頁面瀏覽”;但是在log file方法下則可能因為緩存的影響而不會記錄一次新的頁面瀏覽。這樣,頁面標記方法能夠記錄訪問者更準確的訪問過程(visitor journey)。

2. 能夠記錄“客戶端交互”

  前面已經講過,頁面標記法是在客戶端執行JavaScript代碼實現的,因此,理論上,被瀏覽器打開的頁面上的“一舉一動”都能被記錄下來。對于“客戶端交互”類型的Flash、JavaScript或者其他的web2.0應用,頁面標記法同樣可以給這些應用的各種互動加上標記,然后準確記錄這些互動發生的情況。

  由于網頁變得越來越互動,頁面標記法的優勢就會變得非常明顯,而且,已經有很多采用頁面標記法的工具是直接服務于頁面上的客戶端交互的,這說明客戶端交互監測需求已經不再是可有可無,而是成為衡量網站績效的重要組成部分。

3. 相對準確的訪客(visitor)記錄

  頁面標記法依賴于cookie記錄和辨識訪客的信息,也有些頁面標記法的工具利用cookie和IP共同辨識訪客信息,而日志方法則只依賴于具體的IP地址。

  要強調的是,利用cookie方法來辨識訪問者信息同樣不可能做到100%的準確(事實上完美是不存在的,史蒂芬霍金說過,百分之百完美在宇宙中不存在,若不如此,宇宙就不會存在),但是相較于僅僅依賴于IP地址,cookie畢竟增加了一種辨識機制,而且這種機制與客戶端的瀏覽器捆綁且存入了更多的識別信息,因此利用cookie記錄的訪客記錄肯定要比IP訪客計數準確。公允的說,在找到新的方法前(這種方法目前還沒有聽說),采用cookie技術的頁面標記方法能夠提供目前最準確的訪客數據。

  此外,頁面標記法不受到機器人或者蜘蛛等為爬取網站數據而訪問網站的影響,因此,排除惡意作弊的情況,幾乎可以認為這種方法記錄的全部是“人”訪問網站的數據。尤其是對于我自己的博客http://www.chinawebanalytics.cn這種非商業性的網站而言,我并不太關心機器人對我網站的爬取。不過如果你對SEO有非常高級的需求,那么你應該利用日志分析軟件查看搜索引擎機器人的網站p

4. 更好的實時性

  同日志方法一樣,頁面標記法也是實時采集數據的。訪問行為發生了,觸發(trigger)了頁面上的標記,然后數據隨即被擷取并傳送至工具的服務器。但與日志方法不同的是,日志方法的數據處理不是實時的,而頁面標記方法的數據被傳送至工具的服務器后,即在短時間內(甚至是實時地)被處理,并進而形成報告。因此,頁面標記方法有相當不錯的實時性。例如,Omniture的SiteCatalyst的數據報告僅僅只有幾個小時的延時;過去,Google Analytics有一到兩天的延時,現在也大約只有幾個小時,這樣的數據延遲對分析影響不大,已經可以近似認為是實時的了。

5. 不再存在的數據存儲和傳輸問題

  與日志方法需要保存大量的日志文件不同,只要你愿意,頁面標記法的數據可以全部存放在網站分析工具提供商的服務器(工具服務器)上,這意味著你額外添置日志存儲設備的硬件成本和管理日志文件的軟件成本都不存在了。此外,還被省去的一個麻煩是把日志文件輸入到日志文件分析軟件中的工作,有些時候,這個工作并不像用鼠標在工具的導入界面中點選一個文件那么簡單,而是要開發專門的程序。另外,當存在鏡像服務器等情況的時候,頁面標記法其實可以毫不在乎,但日志方法在合并數據上就不那么簡單了。 

您可能對下面的文章也感興趣




抢红包送彩金