頁面標記法網站分析及資料捕獲原理

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

【前言】　　網站分析如何獲得資料，其實有很多種方法。 例如利用伺服器日誌資料，或者是在用戶端裝一些監視軟體。 頁面標記法網站分析獲取資料的方法跟前二者都不一樣，但一經出生，就豔驚四座，迅速成為主流方法。 我的博客(HTTP://www.chinawebanalytics.cn)實際上幾乎所有的話題都是基於頁面標記法的。 今天的文章，帶朋友們一起再次瞭解什麼是頁面標記法的網站分析，以及我們日常所讀的Omniture Site Catalyst或是Google Analytics網站分析報告中的資料，都是怎麼被捕獲的。

因為在出差，所以能夠寫博客的時間減少了。 這篇文章是我正在猛力撰寫的關於網站分析基礎知識的書中摘取的一段。 希望這本書明年能夠跟大家見面。

【正文】

談到網站分析的資料捕獲，大家應該先有一個預備知識，那就是頁面標記法網站分析和日誌法網站分析的根本原理是完全不同的。 關於日誌法網站分析的原理，請大家看這個帖子：伺服器日誌法網站分析的原理及優缺點。 此前有朋友在微博上留言，認為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，軟體即服務)的出現，頁面標記方法應運而生，這個方法實施起來簡單，而且再也不需要去跟海量的日誌檔記錄打交道，資料管理和處理的效率極大提升， 很快成為眾多站長的首選。 正是因為存在諸如簡單易行、資料可讀性高、管理難度低等諸多優勢，頁面標記方法成為網站分析這門科學主流的資料獲取方法，我的博客(CWA, HTTP://www.chinawebanalytics.cn)也完全聚焦于這種方法， 而不會詳細討論日誌方法。

興趣閱讀：監測代碼和監測標籤的區別

在進行網站分析的具體實踐活動中，我們常常把兩種不同的監測標記方法——監測代碼(Tracking Code)和監測標籤(Tracking Tag)混用。 但實際上它們是不同的事物，我們如果能夠把它們嚴格區分開，將有助於我們在溝通中進行更準確地溝通。

代碼(Code)指能夠執行的程式中的語句，因此監測代碼是指為監測目的而編寫的一段可執行檔程式語句。 最典型的監測代碼就是我們在頁面中添加的Google Analytics的JavaScript監測代碼。

標籤(Tag)指為辨識某個監測物件而添加的標識，這個標識不是程式語句，不能夠被執行，但可以被程式識別用於判斷監測物件的具體屬性。 例如這樣一個URL：HTTP://www.chinawebanalytics.cn/?utm_campaign=newbook&utm_source=tsinghua&utm_medium=press，「 ?utm_campaign=newbook&utm_source=tsinghua&utm_medium=press」就是一個標籤。 標籤同樣也可以是一段完整的URL。

簡單講，能執行的程式是監測代碼，不能執行的是監測標籤。

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

我們已經瞭解了頁面標記方法的基本原理，現在我們要細緻學習頁面標記是如何能夠實現資料的收集、傳遞並最終呈現在我們面前的。 瞭解這個過程，對於我們進行網站分析的具體監測實施很有説明。

　　

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

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

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

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

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

1. 探測用戶端的各種屬性，包括瀏覽器版本，作業系統版本，螢幕解析度等等，並且記錄下來頁面訪問具體發生的時間，以及訪問的來源(Traffic Source)等等。

2. 為這個使用者的這個瀏覽器建立一個cookie。 什麼是cookie?請看這個帖子：捍衛Cookie——沒有Cookie，我們什麼都沒有了，以及這個帖子：JavaScript和Cookie對GA的影響有多大?。 如果不想看這兩篇文章，沒關係，簡單說cookie的作用是把使用者這一次訪問這個網站的相關關鍵情況記錄下來，當下次這個使用者再流覽這個網站的時候，cookie中的記錄就會作為新的流覽記錄的參考， 從而能夠讓網站分析工具判斷這次訪問是否是重複訪問，訪問者是不是新的訪問者，以及很多其他的重要資料。 cookie在頁面標記監測方法中是必須的，也就是說，如果瀏覽器禁用了cookie，頁面標記方法就不能發生作用。 想知道Google Analytics的cookie設置，請看這個文章：網站分析度量、意義以及不為人所知的(2)。

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秒。 另外，如果你耐著性子往後看，你還能看到訪問者所使用的作業系統和瀏覽器的資訊。

關於utma，utmb，utmc和utmz都代表什麼，大家看這個文章就明白了：網站分析度量、意義以及不為人所知的(2)。

第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. 不再存在的資料存儲和傳輸問題

與日誌方法需要保存大量的日誌檔不同，只要你願意，頁面標記法的資料可以全部存放在網站分析工具供應商的伺服器(工具伺服器)上，這意味著你額外添置日誌存放裝置的硬體成本和管理日誌檔的軟體成本都不存在了。 此外，還被省去的一個麻煩是把日誌檔輸入到日誌檔分析軟體中的工作，有些時候，這個工作並不像用滑鼠在工具的導入介面中點選一個檔那麼簡單，而是要開發專門的程式。 另外，當存在鏡像伺服器等情況的時候，頁面標記法其實可以毫不在乎，但日誌方法在合併資料上就不那麼簡單了。

好了，這周的功課給大家交上了，現在輪到大家了。 我真的很希望看到您的留言和意見。 祝大家有一個愉快的新的一周!

原文位址：HTTP://www.chinawebanalytics.cn/pag-tagging-data-acquire/