爲何你統計 PV 的方式是錯的？

翻譯自 Google 工程師 Philip Walton 的文章。共 3754 字，讀完需 7 分鐘。合格的工程師要能認識到數據和功能同樣重要，由於準確的數據收集是產品迭代、市場營銷的決策基礎。本文會幫你剖析爲何你經常使用的統計方式是錯的？而後給出可行的解決方案。

直言不諱的說，目前市面上的 Page View（常說的PV，即用戶瀏覽頁面的次數）統計工具沒法準確統計愈來愈多的新站點，且已經和 WEB 技術的演進方向徹底脫節。

由於在大多數狀況下，這些工具假設每次頁面瀏覽（Page View）對應一次頁面加載（Page Load），且每次頁面加載完成後都會運行一些統計代碼，將 Page View 事件發送到後端服務器。任何不符合這種模式的網站都須要工程師作額外的工做才能統計到正確的結果，然而大多數前端工程師彷佛不具有這方面的專業知識，或者乾脆沒有時間。

現實是，WEB 技術在過去 10 年間發生了巨大的變化，愈來愈多的網站已經不符合傳統的網站模式，而咱們的分析工具演化並無跟上。

問題在哪兒？

舉個具體的例子，考慮 mail.google.com（Gmail），使用 Gmail 的大多數人在首次打開後會保持它在後臺運行，每隔一段時間去檢查是否有新消息，若是有新消息，會直接打開閱讀，整個過程無需刷新頁面。

因爲絕大多數 Gmail 用戶幾乎歷來不刷新頁面，從統計分析的角度就產生了一些很是有趣但重要的疑問：

• 若是用戶打開 Gmail 一次，而在接下來的幾天以內使用數百次，可是並無刷新頁面，這種狀況應該只算一個 Page View 麼？
• 若是用戶點擊 Gmail 左上角的 Logo 來刷新頁面內容，或者移動端的下拉刷新，是否應該算一個新的 Page View？這種動做與徹底刷新頁面有何不一樣？
• 若是用戶打開並閱讀一封新郵件，實際上無需刷新頁面，是否應該計算爲一個新的 Page View？
• 若是兩個用戶天天訪問 Gmail 的次數徹底相同，可是其中一個每次刷新，而另外一個保持頁面在後臺運行，這兩種使用模式的 Page View 統計結果應該有很大的不一樣麼？

列舉這些疑問想說明的問題是，對於某些站點，繼續使用傳統的 Page View 統計方法會致使不許確的統計結果，而在 WEB 應用的技術實現方案隨時間推移不斷演進的狀況下，這種不許確會變的很是離譜。

試想，你在傳統的 WEB 網站中添加了統計代碼，幾個月後，你將該網站更新爲單頁應用（SPA，或 Single Page Application），而沒有修改統計代碼代碼。再過幾個月，你又將網站更新爲漸進式 WEB 應用（PWA，或 Progressive Web Application），這種技術能夠在後臺從新加載內容並脫機工做），這時候你仍然沒有更新統計代碼。若是這段時間應用的訪客數量及使用模式沒有變化，你確定會指望統計結果不出現大幅度波動。

不幸的是，在上述狀況下，即便你改善了用戶體驗，但 Page View 的統計結果能夠確定是降低的。這是一個很是糟糕的狀況：你但願改善網站的交互體驗，可是沒法用數聽說服任何人這樣作是值得的，由於統計數據給出的結果是徹底相反的。

該怎麼解決？

任何技術問題總會有解決辦法，本文提出的解決方案則須要迴歸 Page View 這個指標的本原。咱們須要追蹤的不是頁面被加載（loaded）的次數，而是被瀏覽（viewed）的次數。

咱們能夠利用 Page Visibility API 達成目的，實際上該 API 已經存在了很長時間，而且幾乎全部的主流桌面和移動瀏覽器都支持。

事實證實，統計頁面被瀏覽的次數而不是被加載的次數能優雅地解決掉傳通通計方式不能處理的不少問題：

• 當用戶打開的某個選項卡轉入後臺，而後在幾小時或幾天以後再切回來，但不從新加載頁面；
• 當用戶打開某個頁面做爲參考，並來回切換以快速瀏覽其中的內容，但不從新加載頁面；
• 當用戶在後臺選項卡中打開頁面，而後忘記了，歷來沒有實際瀏覽頁面內容；

Page Visibility API 由 document.visibilityState 屬性以及 visibilitychange 事件組成。基於這兩個 API，你能夠確保只會在頁面的 visibilityState 可見時才發送 Page View 統計。此外，你還能夠監聽 visibilitychange 事件，在用戶從新切回到在後臺運行有段時間的應用時發送新的 Page View 統計。Page Visibility API 很好的解決了加載完成後幾乎不須要刷新的 WEB 應用的 Page View 統計問題。

解決方案的第二部分是 History API，這是 SPA 應用構建的基礎技術，目前主流瀏覽器都支持（詳見），所以統計工具能夠經過監聽 URL 變化來發送相似於傳統網站的頁面統計。

該怎麼實現？

利用 Page Visibility 和 History API 來準確統計 Page View 的基本思路以下（這種思路適用於傳統網站、SPA、PWA）：

1. 頁面加載時，若是頁面的 visibilityState 是可見的，發送 Page View 統計；
2. 若是頁面的 visibilityState 是隱藏的，就監聽 visibilitychange 事件，並在 visibilityState 變爲可見時發送 Page View 統計；
3. 若是 visibilityState 由隱藏變爲可見，而且自上次用戶交互以後已通過了「足夠長」的時間，就發送新的 Page View 統計；
4. 若是 URL 發生變化（僅限於 pathname 或 search 部分發送變化, hash 部分則應該忽略，由於它是用來標記頁面內跳轉的) 發送新的 Page View 統計；

上述步驟 3 是最重要的，但同時也是最模糊的和頗具爭議的，關鍵的問題是：究竟多長才算是「足夠長」？一方面，你可能並不想在每次 visibilityState 發生變化的時候都發送新的 Page View 統計，由於對於用戶來講，在選項卡之間來回切換是很是常見的，而實際狀況是，某些應用同時在多個選項卡中打開使用是最方便的，而這就伴隨這大量的選項卡切換。另外一方面，你又指望統計到在一段時間沒有和應用交互以後用戶的回訪（returning）行爲，也就是說須要統計到用戶屢次使用的行爲。

幸運的是，全部的統計工具都定義了一種區分屢次使用的方式，即會話，或者叫 Session。會話是在給定時間窗口中發生的用戶交互的集合，當某個預設的時間段過去時會話就結束了。好比，默認狀況下 Google Analytics 的會話在 30 分鐘無交互的狀況下結束。而大多數統計工具都提供了會話時長自定義的功能。

因此回到上面列表中的第三步，個人建議是，若是用戶會話已結束，而且頁面的 visibilityState 從隱藏變爲可見，則應發送新的 Page View 統計。在會話內發生的 visibilityState 變動不該被視爲不一樣的 Page View。

注意：若是你使用 autotrack（特別是 pageVisibilityTracker 和 urlChangeTracker 插件），你就無需本身實現上面的邏輯。這些插件能夠自動處理全部這些狀況，固然你可使用配置項來自定義插件的行爲）。

如何減小誤報？

在爲 autotrack 建立 pageVisibilityTracker 插件時，我對基於 Page Visibility API 的多種實現方案進行了大量完全的測試，發現利用啓發式信息在避免誤報上是很是必要的。

例如，用戶使用鍵盤快速在一堆打開的標籤頁中來回切換，結果是不少頁面的 visibilityState 從隱藏變爲可見，可是很快又恢復原狀。在個人測試中，有至關比例的 Page View 是因爲在會話超時後 visibilityState 變爲可見致使，可是緊接着 visibilityState 又恢復爲隱藏。而 99% 相似這種的頁面從可見恢復爲隱藏狀態的間隔都在 5 秒之內。

當我分析本身的使用模式以後，這種現象的存在並不奇怪，很常見的操做有：意外的切換到一個選項卡，可是很快就離開了；切換到一個選項卡，只由於我要切換到其餘的選項卡，而這個選項卡恰好在夾在中間（這裏使用鍵盤切換）；切換到某個選項卡，只是爲了關閉它。在全部這些狀況下，發送新的 Page View 並無任何意義，而在上報 Page View 統計以前設置 5 秒的超時能夠防止 99％ 以上的誤報。

Page View 和 Page Load

有時候你可能想了解你的網站加載（Page Load）了但從未被瀏覽過的頻率，你可能還想知道頁面瀏覽是由初始頁面加載觸發仍是由 visibilityState 或 URL 變化致使的。

顯然你能夠建立一個自定義維度來統計頁面加載（實際上我一般會這樣作），可是透過這個問題咱們能清楚的認識到，咱們真正須要的是兩個獨立的指標：頁面瀏覽（Page View）和頁面加載（Page Load）。幸運的是，現在的大多數統計工具容許用戶自定義指標來統計他們想要的任何數據，而 autotrack 支持經過配置項 幫你把頁面瀏覽與頁面加載的統計分開。

經過將頁面瀏覽與頁面加載解耦，咱們就能徹底掌握 Page View 這個指標的真實含義：測量用戶實際瀏覽頁面的次數，而不管頁面加載了多少次。

Page View 和 Session

有些讀者可能會嘀咕：只要你正確的統計到了初次頁面加載後用戶的全部交互，只統計首次頁面加載又有什麼關係呢？Page View 的正確統計爲何相當重要呢？

雖然看起來彷佛是一個合理的問題，但若是你瞭解大多數統計工具使用的數據模型，你將很快意識到這些問題自己是站不住腳的。

大多數分析工具假定每一個會話都至少包含一個 Page View，該 Page View 用於肯定諸如 Landing Page（落地頁）和 Exits（跳出頁）等指標。若是你僅僅統計了初次頁面加載，而後後續全部會話只包含事件統計，則大多數會話報告變得一團糟。而幾乎全部的傳統 WEB 統計工具都使用這種模型來計算，這也從側面印證了傳統模型的侷限性。

暫且把工具限制放在一邊，另一個讓你信服的論據是：全部包含了用戶交互事件的會話都應該至少包含一次 Page View，畢竟，若是沒有打開頁面，你怎麼跟它交互呢？在會話超時、visibilityState 變爲可見時發送新的 Page View 能好好的解決這個問題。

總結和 TIPS

但願你讀完這篇文章，能從新思考 Page View 的正確姿式，若是你在本身項目中使用了統計工具，能夠結合本文的建議把統計作到準確。

統計工具應該衡量的是用戶參與度，而不該該與網站的技術實現相耦合。當用戶體驗改善時，咱們應該能夠經過統計工具的分析報告來證實。這是利用技術推進業務發展最直接的方法。

若是你使用的是 Google Analytics，則能夠經過使用 autotrack（強烈建議 SPA 或 PWA 項目使用）來將本文的解決方案運用到項目中，要查看如何配置 autotrack 的示例？請移步 analyticsjs-boilerplate 倉庫。

One More Thing

本文譯者王仕軍，商業轉載請聯繫做者得到受權，非商業轉載請註明出處。若是你以爲本文對你有幫助，請點贊！若是對文中的內容有任何疑問，歡迎留言討論。想知道我接下來會寫些什麼？歡迎訂閱知乎專欄：《前端週刊：讓你在前端領域跟上時代的腳步》。