補上識別能力之前，先看清楚原本被寄予厚望的那個欄位為什麼不夠用——如果進來的問題是「為什麼來源網址幾乎都是空白」，答案在下一節。

來源網址為什麼大量空白

來源網址（document.referrer）記錄的是「進到這一頁之前，讀者在哪一頁」。它的值不由接收端決定、也不由當前頁面決定，而是由上一頁送出請求時附帶的 Referer 標頭決定——這代表控制權在上一頁手上。

上一頁能控制到什麼程度，由它的 Referrer-Policy 設定。現代瀏覽器的預設值是 strict-origin-when-cross-origin：跨網域時只送出來源網站的網域（例如 https://www.google.com/）、不送完整網址；同網域之間才送完整網址。這個預設有一個直接的推論——在未覆寫預設政策、且換頁是整頁載入的站上，站內導覽會留下來源網址，因為那是同網域的跳轉。

兩個前提都要成立，而它們都可能不成立。站方能用 meta 標籤或回應標頭覆寫政策，設成 no-referrer 時連站內導覽都不留來源，部分 CDN 與佈景主題會預設加上這類設定。單頁應用程式（client-side routing）換頁時不重新載入文件，document.referrer 因此停在最初進站的那個值、不隨導覽更新。

這裡有一個容易混淆的地方：站方的 Referrer-Policy 決定的是「離開這個站時送出多少來源」，與「收到的訪客帶著什麼來源」是兩件事。後者由上一頁的站決定，自己這端管不到。

前提成不成立可以直接驗：在自己的站上點兩篇文章，看記錄裡有沒有出現自家網域的來源。沒有出現時，下面所有以站內來源為依據的判讀都不適用。

從這個推論可以反過來判讀空白：

這張表沒有窮盡所有可能，但它已經足以說明關鍵：除了「自動化抓取」那一列，其餘全部是真人。單看空白這一件事分不出它們，因此空白不是「缺資料」，它是一個需要其他欄位才能拆開的分類。

拆開要靠交叉判讀，而每一類留下的欄位組合不同。app 內建瀏覽器的記錄通常伴隨行動裝置分類，部分 webview 回報不到視窗尺寸而語言偏好正常。自動化抓取在裝置欄多半落在桌機、語言偏好常是空的或單一英文，而且自動化訊號欄會有命中。這一類的佔比通常比預期低——beacon 靠 JavaScript 觸發，而多數抓取工具根本不執行 JS、不會出現在這份資料裡。隱私瀏覽器與擴充功能的特徵最不明顯：裝置與語言都正常，識別碼卻可能每次都是新的。直接輸入、書籤與原生程式喚起在這幾個欄位上與一般真人瀏覽沒有差別。它們是排除掉可辨識的那幾類之後剩下的殘差，而殘差裡也包含這張表沒有列到的成因——把殘差整個當成「直接訪問」會高估那一類。

站內來源的比例可以當成追蹤指標，但它沒有跨站通用的門檻。真人從搜尋結果進來、看完一篇就離開是常見的，內容型網站的站內跳轉本來就偏低，剛上線只有幾篇文章的站更接近零。同樣的比例在不同的站代表完全不同的事。

能用的作法是先量出自己的基線：取一批組成已知的記錄（例如設定 opt-out 之前自己走過的閱讀路線），算出其中站內來源佔多少，之後用偏離這個基線的幅度判讀，而不是套一個絕對數字。基線的完整量法見辨識自動化流量。

兩層隨機識別碼

識別的做法是讓瀏覽器自己產生一個隨機值、存起來、每次送 beacon 時一起帶上。這個值不從任何個人資訊推導出來，它只是一個標籤——同一個標籤出現在多列上，代表那些列來自同一個瀏覽器。

用兩層而非一層，是因為要回答的是兩個不同的問題：

訪客識別碼存在 localStorage，它跨越分頁與瀏覽器重啟繼續存在。 同一個訪客識別碼出現在相隔數天的兩列上，代表這個人回來了。這是判斷內容有沒有留住讀者的直接依據，而它無法從單次瀏覽的任何屬性推導出來。

session 識別碼存在 sessionStorage，分頁一關就消失。 同一個 session 識別碼底下有五個不同路徑，代表這次來訪讀了五篇。這個數字回答的是「單次閱讀深度」，跟回訪率是正交的兩件事——有人每天回來但每次只看一篇，也有人只來過一次卻一口氣讀完整個模組。

實作上兩者共用同一段邏輯，差別只在傳入哪個儲存體：

 1// storage 在隱私模式或停用 cookie 時會丟例外，統計不該因此讓頁面出錯
 2function safeGet(store, key) {
 3  try { return store.getItem(key); } catch (e) { return null; }
 4}
 5function safeSet(store, key, value) {
 6  try { store.setItem(key, value); } catch (e) { /* 存不了就當作無法識別 */ }
 7}
 8
 9function stableId(store, key) {
10  var existing = safeGet(store, key);
11  if (existing) return existing;
12  var fresh = (window.crypto && crypto.randomUUID)
13    ? crypto.randomUUID()
14    : Date.now().toString(36) + Math.random().toString(36).slice(2, 10);
15  safeSet(store, key, fresh);
16  return safeGet(store, key) ? fresh : "";
17}
18
19var visitorId = stableId(localStorage, "blog_visitor_id");
20var sessionId = stableId(sessionStorage, "blog_session_id");

三個實作細節各自對應一種會實際發生的狀況。存取包在 try/catch 裡，因為 Safari 的私密瀏覽把配額壓到接近零、setItem 會丟 QuotaExceededError，而封鎖網站資料的設定會丟 SecurityError；統計失敗不該讓頁面的其他 JS 一起中斷。crypto.randomUUID 有 fallback，因為它需要安全連線環境（secure context，HTTPS 或 localhost），在少數環境下不存在。寫入後再讀一次確認，因為 safeSet 把例外吞掉了——寫入成功與否在這個結構下只能靠讀回來判斷。讀不回來時回傳空字串、彙總時歸為不可識別，比回傳一個「下次就不見了」的值誠實：假的識別碼會讓每次瀏覽看起來都是新訪客。

這裡有一個附帶的觀察能力：自動化抓取工具每次都在全新的瀏覽器環境執行，所以每一列都帶著不同的訪客識別碼、而且每個 session 只有一列。這個模式不需要額外偵測就會自己浮現。

退出機制的選型與邊界

排除特定瀏覽的機制有三種候選，選擇的依據是各自的技術可行性與副作用。

IP 位址在這個架構下不可行。 Apps Script 的 doPost(e) 事件物件只提供 parameter、postData、pathInfo 這些欄位，不提供任何 HTTP 標頭——接收端讀不到來源 IP。即使技術上讀得到也不該用：家用寬頻的 IP 會變動，行動網路的多個用戶共用同一個對外 IP，用 IP 排除自己會連帶排除掉一批陌生讀者。

Cookie 可行但代價不對等。 Cookie 會隨著每一個同網域的 HTTP 請求自動送出，而靜態站託管平台根本不讀它——頁面、圖片、CSS、字型的每一個請求都多帶一段用不到的資料。單筆負擔很小，但它落在讀者的每一次連線上，換來的功能與存在 localStorage 完全相同。

localStorage 只在 JS 主動讀取時才被用到，不污染任何請求，容量也充裕。整段邏輯放在 beacon 送出之前，讀到標記就直接返回：

1var OPTOUT_KEY = "blog_analytics_optout";
2
3// 設定入口用網址參數，讓不熟悉開發者工具的讀者也能操作
4var query = new URLSearchParams(location.search);
5if (query.get("noanalytics") === "1") safeSet(localStorage, OPTOUT_KEY, "1");
6if (query.get("noanalytics") === "0") { try { localStorage.removeItem(OPTOUT_KEY); } catch (e) {} }
7
8// 判定：有標記就不送
9if (safeGet(localStorage, OPTOUT_KEY) === "1") return;

開啟一次 https://網域/?noanalytics=1，該瀏覽器之後就不再送出統計。這段程式碼與前面的 safeGet / safeSet 同屬 beacon 那個立即執行函式，return 讓整個統計流程在此中止。

這個機制的邊界要說清楚，因為它決定了使用方式。設定綁定「瀏覽器 + 來源」這個組合，不綁人也不綁裝置——localStorage 依 origin（協定、網域與 port 的組合）分割、路徑不影響，所以同一台電腦的不同瀏覽器要各設定一次，手機要另外設定。隱私瀏覽視窗的設定活不過該視窗：Chrome 無痕與 Firefox 隱私視窗寫得進去、當次有效，關閉最後一個私密分頁時清除；Safari 私密瀏覽則因為配額接近零而根本寫不進去。清除網站資料時會一併消失，需要重新設定。

還有一個平台特性值得知道：Safari 的追蹤預防機制（Intelligent Tracking Prevention，ITP）會清除網站以指令碼寫入的儲存資料，觸發條件是「連續七個有使用 Safari 的日子裡，沒有在該站發生過使用者互動」。這個天數是廠商政策、改過不只一次（曾經是三十天），引用時要回頭確認現行值。計時單位是使用瀏覽器的天數而非日曆天，重置條件是互動而非單純造訪。這既影響退出設定，也代表 Safari 讀者的回訪率會被系統性低估——同一個人隔一段時間回來會拿到新的訪客識別碼，在資料上看起來是新訪客。判讀回訪數字時要記得這個偏差的方向。

隱私邊界

這套識別的性質是第一方隨機標籤：值由瀏覽器產生、只送到自己的接收端、不含任何從個人資訊推導出來的成分、也不與任何外部服務交換。它能回答的是「這幾列來自同一個瀏覽器」，回答不了「這個人是誰」。

相對地，有幾件事是刻意不做的。不送完整的 userAgent，只送 mobile / tablet / desktop 三選一的裝置分類——完整字串帶著版本與系統細節，組合起來足以構成瀏覽器指紋。不送螢幕解析度、時區、字型清單這類單獨無害但組合起來高度唯一的欄位。不記錄頁面上的任何輸入內容。

還有一項刻意的選擇藏在程式碼裡、值得寫出來：路徑送的是 location.pathname 而不是 location.href，差別在於前者不含 query string。搜尋關鍵字、追蹤參數、以及任何被塞進網址的識別碼都因此不會進入資料。這一行如果哪天被改成 href，上面整段隱私說明會在沒有任何人察覺的情況下失真。

有一個欄位需要如實交代：來源網址送的是完整值。同網域導覽時它是站內另一篇文章的完整網址，跨站時多半只有對方的網域。它不是這個站產生的資訊，但它確實被記錄下來。

公開這些界線本身也是設計的一部分：實作是靜態站的一段 JS，任何人都能讀原始碼驗證，所以說明必須與實作一致。退出的入口要放在讀者找得到的地方，而不是只寫在原始碼註解裡。

下一步

記錄之間有了關聯，但每列承載的資訊仍然停在「這一頁被打開了」。讀者停留多久、有沒有真的在讀，要靠第二則事件才量得到——事件模型與停留時間講怎麼拆、以及那個秒數實際量到的是什麼。

已經想處理「哪些記錄是機器產生的」，可以跳過事件模型直接看辨識自動化流量，但那一章的行為訊號建立在事件模型上，讀起來會少一層。隱私與防濫用的完整討論在模組五的配額、防濫用與隱私邊界。

概念位置

Beacon 跟一般 API 請求的差別在「不等回應」。發起者送出後就繼續做自己的事，不阻塞、不讀回應、不重試——這種模式叫 fire-and-forget。對流量統計這類「送到就好、漏一兩筆無所謂」的場景，fire-and-forget 讓回報完全不影響使用者體驗。beacon 送出的請求由接收端的 doPost 進入點接住處理。

可觀察訊號與例子

瀏覽器的 navigator.sendBeacon 是專為此設計的 API：它保證即使頁面正在關閉，請求也會在背景送完，而且預設用 text/plain 送出，這一點在打跨網域端點時關鍵——text/plain 屬於 simple request、不觸發 CORS preflight。

判讀方式

跨網域打 Apps Script 這類端點時，text/plain 是否夠用決定要不要處理 CORS preflight。實作細節見前端 beacon 與 CORS 障礙。

CORS preflight 為什麼會擋住 beacon

瀏覽器對跨網域的請求有一套安全機制。當網頁（你的 blog，網域 A）要送一個請求到另一個網域（Apps Script，網域 B），而這個請求「不夠單純」時，瀏覽器會先偷偷送一個 OPTIONS 請求去問網域 B：「我等一下要送這種請求，你允許嗎？」這個預先詢問叫 preflight。要等網域 B 回答允許，真正的請求才會送出。

Apps Script 在這裡有一個結構性的問題：它的 web app 無法回應 OPTIONS 請求。原因是 Apps Script 只有 doGet 和 doPost 兩個進入點，沒有 doOptions；preflight 送來的 OPTIONS 打不到你的程式，Apps Script 平台直接用預設方式回應，而那個回應不帶「我允許」的 CORS 標頭。於是 preflight 失敗、真正的請求根本沒送出。這就是「我照 API 教學寫了 fetch 打 Apps Script，瀏覽器 console 一片 CORS 紅字」的根本原因——問題不在你的程式，在於 preflight 發生在你的程式被執行之前，你沒有機會處理它。

避開的方法是讓請求「夠單純」，單純到瀏覽器判定不需要 preflight。這種請求叫 simple request，條件之一是 Content-Type 必須是 text/plain、application/x-www-form-urlencoded 或 multipart/form-data 其中之一。關鍵就在這：只要用 text/plain 送，就不會有 preflight，請求直接送達，Apps Script 的 doPost 正常收到。用 application/json 送則會觸發 preflight、然後失敗。

用 sendBeacon 送 text/plain

navigator.sendBeacon 是瀏覽器為「送出後就不管」這種場景設計的 API，正好適合流量 beacon。它有三個特性剛好對上需求：送出後不阻塞頁面、即使使用者馬上關頁面也保證在背景送完、而且它送出的 Content-Type 預設就是 text/plain（當你傳字串或 text 型別的 Blob 時）——自動滿足 simple request 條件，不觸發 preflight。

最小可用的 beacon 長這樣：

 1(function () {
 2  var ENDPOINT = "https://script.google.com/macros/s/你的部署ID/exec";
 3
 4  var payload = JSON.stringify({
 5    path: location.pathname,        // 哪一頁
 6    ref: document.referrer || "",   // 從哪裡連來的
 7    lang: navigator.language || "", // 瀏覽器語言
 8  });
 9
10  // 用 Blob 明確指定 text/plain，確保是 simple request
11  var blob = new Blob([payload], { type: "text/plain;charset=UTF-8" });
12  navigator.sendBeacon(ENDPOINT, blob);
13})();

送出的是一個 JSON 字串，但外層 Content-Type 是 text/plain——接收端再自己 JSON.parse 把字串還原成物件（模組二的接收端那半會做）。這是「內容是 JSON、但傳輸標成純文字」的常見手法，專門用來繞過 preflight。

payload 刻意只放不涉及個人身分的欄位：看了哪一頁、從哪連來、瀏覽器語言。不送任何能識別個人的資訊。附帶一提，Apps Script 的 web app 收不到訪客的 IP 位址，記不到也就無從外洩——這反而讓這套統計在隱私上乾淨很多，時間戳記交給接收端用伺服器時間補（模組二接收端那半處理）。

這幾個欄位描述的都是單次瀏覽的屬性，任兩列之間沒有關聯，因此算得出「某頁被打開幾次」、算不出「幾個人來過」。要補上那個能力需要額外的識別欄位，而「收不到 IP」這個事實在辨識自動化流量時會再次成為關鍵限制——兩者都在模組六處理。

加上閱讀裝置

閱讀裝置（讀者用手機、平板還是桌機看）是一個對排版決策有用的欄位：某篇長表格文章若行動裝置佔比高，就值得回頭檢查它在窄螢幕的可讀性。要在 payload 加這個欄位，關鍵是只送粗粒度的分類標籤、不送完整 userAgent——mobile / tablet / desktop 這種三選一的標籤足以回答「讀者用什麼裝置」，而完整 userAgent 帶著版本、系統等可組成指紋的細節，送它就破壞了前面刻意維持的不記 PII 立場。

分類邏輯在前端從 navigator.userAgent 判斷：

1function deviceType() {
2  var ua = navigator.userAgent;
3  // iPadOS 的 Safari 會把 userAgent 偽裝成 Mac，靠觸控點數補抓
4  var iPadAsMac = /Macintosh/.test(ua) && navigator.maxTouchPoints > 1;
5  if (/iPad|Tablet|PlayBook|Silk/.test(ua) || iPadAsMac || (/Android/.test(ua) && !/Mobile/.test(ua))) return "tablet";
6  if (/Mobi|iPhone|iPod|Android|BlackBerry|IEMobile|Opera Mini/.test(ua)) return "mobile";
7  return "desktop";
8}

有兩個判斷值得說明，因為它們是「照一般 userAgent 教學寫會分錯」的地方。Android 手機與平板的區分靠 Mobile 這個 token：Android 手機的 userAgent 含 Mobile、Android 平板不含，所以「有 Android 但沒有 Mobile」判為平板。iPad 會偽裝成 Mac：新版 iPadOS 的 Safari 為了要到桌面版網頁，把 userAgent 報成 Macintosh，單看字串會把 iPad 誤判成 desktop；靠 navigator.maxTouchPoints > 1（Mac 桌機沒有觸控）搭配 Macintosh 字樣才抓得回來。這類分類規則會隨瀏覽器演進而過時，所以只做粗分類、不追求精確到型號——粗分類容錯高，型號級的判斷維護成本高又容易錯。

把 dev 加進 payload：

1var payload = JSON.stringify({
2  path: location.pathname,
3  ref: document.referrer || "",
4  lang: navigator.language || "",
5  dev: deviceType(),   // mobile / tablet / desktop
6});

接收端多寫一欄就好（模組二接收端那半會補上 裝置 欄）。

放進 Hugo 的哪裡

這段 JS 要在每一頁都執行，所以放進網站的共用版型、而不是單篇文章。Hugo 的慣例是做一個 partial，在關閉 </body> 前引入：

 1<!-- layouts/partials/beacon.html -->
 2<script>
 3  (function () {
 4    var ENDPOINT = "https://script.google.com/macros/s/你的部署ID/exec";
 5    function deviceType() {
 6      var ua = navigator.userAgent;
 7      var iPadAsMac = /Macintosh/.test(ua) && navigator.maxTouchPoints > 1;
 8      if (/iPad|Tablet|PlayBook|Silk/.test(ua) || iPadAsMac || (/Android/.test(ua) && !/Mobile/.test(ua))) return "tablet";
 9      if (/Mobi|iPhone|iPod|Android|BlackBerry|IEMobile|Opera Mini/.test(ua)) return "mobile";
10      return "desktop";
11    }
12    var payload = JSON.stringify({
13      path: location.pathname,
14      ref: document.referrer || "",
15      lang: navigator.language || "",
16      dev: deviceType(),
17    });
18    var blob = new Blob([payload], { type: "text/plain;charset=UTF-8" });
19    navigator.sendBeacon(ENDPOINT, blob);
20  })();
21</script>

然後在 baseof 版型的結尾引入它：

1<!-- layouts/_default/baseof.html，在 </body> 前 -->
2{{ partial "beacon.html" . }}

放在 </body> 前、而不是 <head> 裡，是為了讓 beacon 在頁面主要內容都載入後才送，不跟關鍵資源搶頻寬。sendBeacon 本身就不阻塞，這個位置只是讓它更晚一點、更不影響體驗。

一個上線前要注意的邊界：本機 hugo server 預覽時 beacon 也會照送，會把開發時的瀏覽混進統計。實務上會加一個判斷，只在正式網域才送——例如檢查 location.hostname 是不是正式網域，是才執行。這個 hostname guard 擋掉本機預覽；「在正式站上自己重整」則需要另一套機制，見訪客識別與 opt-out。防濫用與資料乾淨度的整體討論在模組五。

下一步

前端會送了，但現在 beacon 送出去還沒有人接。接收端要怎麼解析這個 text/plain 的 JSON、怎麼安全寫進 Sheet、部署後怎麼確認收到第一筆——見接收端 handler：寫進第一筆。想先補齊 doPost 跟部署模型的背景，回模組一：Apps Script 地基。資料開始累積之後怎麼讀出意義，見模組六：收到資料之後。

先建立三個直覺：靜態站的能力邊界在哪、資料要靠瀏覽器主動回報到一個你掌握的接收端、以及免費額度該用「同時併發」而非「總次數」來思考。把這三件事想清楚，才知道流量統計為什麼要這樣搭、以及什麼時候該換更重的工具。

章節文章

跨分類引用

• → 模組二：流量 beacon 實作：把本章的 beacon 架構實際做出來
• → Monitoring 監控體系：想清楚「要收集什麼事件」的概念層

為什麼靜態站量不到自己的流量

流量統計的本質是「把每一次瀏覽記在某個你能事後查詢的地方」。傳統有伺服器的網站天生做得到，因為每個請求都會經過你的伺服器，伺服器在回應頁面的同時，順手在 access log 寫下一行「誰、什麼時候、看了哪一頁」。這行 log 是伺服器端的副產品，不需要前端配合。

靜態站沒有這個副產品。GitHub Pages 確實有伺服器在送檔案，但那是 GitHub 的伺服器、不是你的——你拿不到它的 access log，也不能在它上面跑任何統計邏輯。所以對靜態站來說，「有人來看過」這個事實，在預設情況下沒有留在任何你查得到的地方。頁面被看完、瀏覽器關掉，紀錄就消失了。

要把這個事實留下來，唯一的切入點是頁面裡的 JavaScript——那是靜態站上唯一會執行的程式碼。做法是讓這段 JS 在頁面載入時，主動送一個請求到一個由你掌握的接收端，接收端把這次瀏覽記下來。這種「瀏覽器主動回報一則事件」的請求，慣例上叫做 beacon。

膠水層補的是哪一塊

膠水層（glue layer）是一段掛在別人免費平台上、只在被呼叫時才執行的伺服器端邏輯，用來補上靜態站缺的那一小塊伺服器能力。它的形態是一個函式，而非一台你要維護的主機：平時不佔資源、不計費，有請求打進來時才醒過來跑幾百毫秒，跑完就休眠。

用流量統計來看這個分工會很清楚：

• 靜態站（瀏覽器端）：負責偵測「這一頁被看了」，並發出 beacon。這段程式碼在使用者瀏覽器跑。
• 膠水層（伺服器端函式）：負責接住 beacon，把這次瀏覽寫進某個儲存體。這段程式碼在免費平台跑，是你控制的接收端。
• 儲存體：真正記住資料的地方。可以是一張 Google Sheet、一個免費資料庫、或平台自帶的 key-value 儲存。

膠水層補的就是中間那一塊——一個「屬於你、會執行、看得到每個 beacon」的接收端。它不必是完整後端，只要能接住請求、寫一筆資料就夠了。本指南模組二用 Google Apps Script 當這個膠水層，模組三用 Google Sheet 當儲存體。

client beacon 架構怎麼運作

一次完整的流量紀錄走三步，全部由瀏覽器發起：

1. 使用者打開你的一篇文章，瀏覽器載入頁面，頁面裡的 JS 開始執行。
2. JS 組出一則事件（例如「路徑 /posts/foo/、時間、referrer」），送一個 HTTP 請求到膠水層的網址。
3. 膠水層收到請求，把這則事件 append 進儲存體，回一個簡短回應。瀏覽器不需要等這個回應、也不需要用它做任何事。

第三步的「不需要等回應」是 beacon 跟一般 API 呼叫最重要的差別。使用者是來讀文章的，不是來等統計寫完的——beacon 應該是 fire-and-forget（送出就忘）：發出去、不阻塞頁面、不管有沒有成功都不影響閱讀體驗。瀏覽器有一個專門為此設計的 API navigator.sendBeacon，它保證即使使用者馬上關頁面，這個請求也會在背景送完。模組二會用到它。

這個架構有一個取捨要先知道：beacon 只記得到「會執行 JS 的訪客」。爬蟲、關掉 JavaScript 的人、在 beacon 送出前就離開的人，都不會被算進去。因為紀錄的觸發點在瀏覽器端的 JS，client beacon 量到的數字偏保守——它少算，但不會多算。對個人 blog 想知道「哪篇文章有人看」這個目的，偏保守完全夠用；但如果哪天需要精確到不能漏一個請求（例如計費），就得回到有伺服器 access log 的架構。判斷訊號很簡單：漏算幾個訪客會不會造成實際損失——不會，就用 beacon；會，就別用。

下一步

beacon 該送到哪、那個接收端能承受多大的量、免費到什麼程度會開始要錢——這些是免費額度的思考方式與工具選型要回答的。想直接把 beacon 做出來，跳到模組二：流量 beacon 實作。

補上這個能力需要第二則事件，而第二則事件的設計比第一則複雜：載入的時機明確且必定發生，離開的時機則有多種可能，且不保證每次都能送出。

進入與離開拆成兩則事件

模型是每次瀏覽產生兩列：進入事件在頁面載入時送出，離開事件在頁面不再可見時送出，兩列靠 session 識別碼與路徑配對起來。

 1// send()：把物件轉成 JSON 字串、用 navigator.sendBeacon 送出（模組二建立）
 2// deviceType()：回傳 mobile / tablet / desktop（模組二建立）
 3// visitorId / sessionId：兩層隨機識別碼（見〈訪客識別與 opt-out〉）
 4var base = { path: location.pathname, lang: navigator.language, dev: deviceType(),
 5             vid: visitorId, sid: sessionId };
 6
 7// 進入：載入時立刻送，帶來源網址
 8send(Object.assign({ t: "view", ref: document.referrer || "" }, base));
 9
10// 離開：帶停留秒數與是否互動過
11var arrivedAt = Date.now();
12var interacted = false;
13var leaveSent = false;
14
15["scroll", "pointerdown", "keydown"].forEach(function (evt) {
16  addEventListener(evt, function () { interacted = true; }, { once: true, passive: true });
17});
18
19function sendLeave() {
20  if (leaveSent) return;
21  leaveSent = true;
22  send(Object.assign({
23    t: "leave",
24    dur: Math.round((Date.now() - arrivedAt) / 1000),
25    act: interacted ? 1 : 0
26  }, base));
27}

拆成兩列而不是合併成一列，是為了讓兩件事各自失敗。 合併的設計會是「等到離開時才送一列，裡面同時放路徑與停留時間」——它看起來省一半的列數，代價是離開事件送不出去時，這次瀏覽在資料裡完全不存在。而離開事件送不出去是會實際發生的，至少有這些途徑：行動裝置被系統回收記憶體、瀏覽器被強制關閉、裝置斷電、網路在切換基地台時中斷、廣告或隱私擴充功能攔截這個請求、以及接收端在流量尖峰撞到併發上限而拒絕。拆開之後，最壞的結果只損失品質欄位，計數的基準線不受影響。

這份丟失清單在後面還有一個用途。辨識自動化流量會用「沒有離開事件」當作機器的候選訊號，而上面每一條途徑都會讓真人產生同樣的形態——行動流量佔比高的站尤其明顯。判讀那個訊號時要一併想起這一段。

這個取捨的另一面是列數翻倍。試算表容量的影響見模組三的資料模型與容量邊界，執行配額（併發上限與觸發器時間）的影響見模組五的配額碰撞。個人網站的量體下這個代價可以接受；量體大到需要壓縮時，正確的方向是在接收端合併而不是在前端少送——前端少送會讓資料從一開始就不存在。

用 visibilitychange 觸發離開事件

離開事件的觸發時機有三個候選，可靠度差距很大。

beforeunload 不適用。 行動版 Safari 不支援它，所以 iOS 上的所有瀏覽器都不會觸發；而在 Firefox，註冊這個監聽器會讓頁面失去進入 bfcache 的資格——那是瀏覽器把整個頁面狀態留在記憶體裡、讓上一頁 / 下一頁能瞬間還原的機制，失去資格代表讀者按返回時要重新載入——為了統計而拖慢讀者的返回操作，取捨方向是錯的。各家瀏覽器一致排除出 bfcache 的其實是 unload，現代瀏覽器的 beforeunload 本身已不影響 bfcache，但 Firefox 這個例外加上行動端完全不支援，已經足以讓它出局。

pagehide 涵蓋頁面卸載與進入快取兩種時機（event.persisted 可區分兩者），比 beforeunload 可靠，但漏掉「切換到別的分頁或別的 app」這個最常見的離開方式。

visibilitychange 進入 hidden 狀態涵蓋範圍最廣：切換分頁、導覽到新頁、切換 app、行動裝置鎖定螢幕、最小化或關閉瀏覽器都會走到。規格把「轉為 hidden」描述成頁面最後一個能可靠觀察到的事件。兩者都註冊、靠旗標防止重複送出：

1addEventListener("visibilitychange", function () {
2  if (document.visibilityState === "hidden") sendLeave();
3});
4addEventListener("pagehide", sendLeave);

sendLeave 開頭那個 leaveSent 旗標在這裡是必要的而非防禦性的——一次真實的離開通常會同時觸發這兩個事件。

它帶來一個容易漏掉的交互作用：頁面進入 bfcache 時 JS 狀態整個保留下來，讀者按返回還原頁面之後，leaveSent 仍然是 true、arrivedAt 仍然停在上一次載入的時刻。不處理的話，這次閱讀不會產生任何記錄，而在快取裡待的那段時間會被算進上一筆的停留秒數。修法是監聽 pageshow，在 event.persisted 為真時把三個狀態變數重置並補送一則進入事件：

1addEventListener("pageshow", function (evt) {
2  if (!evt.persisted) return;          // 一般載入不需要處理
3  leaveSent = false;
4  interacted = false;
5  arrivedAt = Date.now();
6  send(Object.assign({ t: "view", ref: document.referrer || "" }, base));
7});

送出方式是 navigator.sendBeacon（見beacon 知識卡），它的設計目標正是這個場景：頁面正在關閉時，一般的請求會隨著頁面銷毀而被取消，而 sendBeacon 把資料排進瀏覽器的傳送佇列、不阻擋頁面卸載。

它保證的是「不延遲卸載」而非「一定送達」——排進佇列之後的傳送結果不會回報，行動裝置被切走或強制關閉時仍可能沒送出去。同步能得知的只有排隊本身成不成功：佇列有 64 KiB 的上限，超過或排隊失敗時回傳 false。流量事件的 payload 遠小於這個上限，但要監控收集鏈健康度時，這個回傳值是唯一在瀏覽器端可見的失敗訊號。

停留秒數對應的是可見時長

這個欄位的語意需要精確界定，否則會被當成閱讀時長使用而得出錯誤結論。它量的是「頁面從載入到不再可見之間經過的時間」，這與讀者實際花在這篇文章上的時間有系統性的差距。

差距來自兩個方向。切換到別的分頁去查資料再切回來，會被切成多段——第一段在切走時就結束了，切回來不會產生新的進入事件（頁面沒有重新載入），所以回來之後的閱讀時間完全沒有被記錄。反過來，開著分頁去做別的事，如果沒有切換到其他分頁（例如直接離開電腦），這段時間會全部算進停留秒數。

站內導覽時還有一個可以驗證的現象：離開事件與下一頁進入事件的時間戳落在同一兩秒內，因為舊頁進入 hidden 與新頁開始載入是同一個動作的兩面。時間戳由接收端在寫入時補上，所以這個間隔還包含網路傳輸與接收端排隊，不是純粹的瀏覽器事件間隔。用它重建連續的閱讀路徑時，配對條件要留這個寬容範圍。

這個欄位因此適合分辨量級、不適合精確比較，而分界由誤差來源決定：中途切換到別的分頁會讓後半段完全不計，所以量測誤差可以達到一次分頁切換的完整時長——查一個名詞、回一則訊息都是數十秒的量級。比較的粒度要大於這個誤差，否則差異可能全部來自切換行為而非閱讀。分桶而不是比大小，是這個限制下唯一穩健的用法。

互動旗標

act 記錄的是「這次瀏覽期間有沒有發生過捲動、點擊或按鍵」。它用 { once: true } 註冊，第一次觸發後就移除監聽器——需要的資訊只是「有沒有發生過」，不是次數，持續監聽只會增加沒有用途的執行成本。

passive: true 這個選項對捲動事件是必要的：它向瀏覽器宣告這個監聽器不會取消預設行為，讓捲動不必等待 JS 執行完成。統計程式碼不該是頁面捲動卡頓的來源。

這個旗標的判讀價值在於它與停留秒數的組合。停留六秒且沒有任何互動，與停留六秒且捲動過，是兩種完全不同的閱讀行為——前者是頁面被打開然後放著，後者是有人真的在看。單獨看秒數分不出這兩者。

資料模型變更會讓既有的報表公式換語意

這個變更有一個容易被漏掉的下游影響：在單事件模型下寫的統計公式，在雙事件模型下仍然合法執行，但回答的已經不是同一個問題。

具體的例子是判斷「這次 session 只看了一頁」。單事件模型下，這等價於「同一個 session 識別碼只出現一次」：

1COUNTIFS(session欄, 當列session) = 1

改成雙事件之後，每次瀏覽至少產生兩列，這個條件從此永遠不成立。公式沒有報錯、沒有回傳錯誤值，只是那個分類的計數變成恆為零——而零看起來就像「沒有這種流量」。正確的寫法要把事件型別納入條件：

1COUNTIFS(session欄, 當列session, 事件欄, "view") = 1

同一個影響也及於模組四的每日彙總：那段 group by 對每一列加一，在單事件模型下等於數瀏覽次數，改成雙事件之後多數瀏覽會被數兩次。倍率不是固定的二——離開事件本來就會丟失一部分，實際倍率落在一與二之間、且隨行動裝置佔比浮動。這正是這類失效難察覺的原因：固定倍數還有機會被看出來，浮動的比例只會讓數字「看起來變多了」。修法是在迴圈裡先篩掉非進入事件，模組四的程式碼旁已標明這個前提。

因此資料模型的變更範圍必須包含下游的分析邏輯，把公式與彙總程式的重算當成同一次變更的一部分，而不是之後再說。延後處理會失去對照：之後回頭看時，看到的數字已經是新邏輯算出來的，沒有東西可以比對。這類失效的完整判讀方法見假故障與靜默失效的診斷，抽象層的原則見 #250 資料多出一種形狀時，既有分析邏輯靜默換語意。

下一步

事件模型完成後，資料裡有了停留時間與互動訊號。這兩個欄位除了描述閱讀行為，也比環境屬性難偽裝，因此是分辨真人與機器的主要依據——前提是先知道它們在真人身上也會缺席。怎麼組合它們與其他訊號、以及怎麼量出自己站上的真人基線，見辨識自動化流量。

這一章的作法受兩個限制支配：接收端拿不到判別素材，以及會出現在這份統計裡的機器比想像中少。先講清楚這兩件事，它們決定了訊號從哪裡來、以及能期待抓到什麼。

接收端讀不到請求標頭

Apps Script 的 doPost(e) 事件物件提供 parameter、parameters、queryString、contentLength、postData、pathInfo 這幾個欄位，不提供任何 HTTP 標頭。這代表接收端拿不到 User-Agent，也拿不到來源 IP。

傳統的伺服器端過濾（比對 UA 字串、查 IP 反解、比對已知爬蟲的 IP 區段）在這個架構下全部不可用。所有判斷素材必須由前端蒐集之後放進 payload 送出——這既是限制，也界定了設計空間：能用的訊號只有瀏覽器環境暴露給 JavaScript 的那些。

這個限制連帶產生一條必須守住的界線。前端能取得完整的 userAgent、螢幕尺寸、時區、字型清單，把它們全部送出確實能提高辨識率，但那正好構成瀏覽器指紋——為了分辨機器而蒐集足以識別個人的資料，取捨方向是錯的。後面的每個訊號都在「有判別力」與「不構成指紋」之間取值。

會被 beacon 記錄到的機器只有一小部分

beacon 靠 JavaScript 觸發，所以只有會執行 JS 的抓取工具才會進入這份統計。這一條大幅縮小要辨識的對象範圍，而它與直覺相反：

AI 訓練爬蟲不執行 JavaScript 是其中最反直覺的一項。Vercel 在 2025 年對自家平台流量的量測顯示，GPTBot 與 ClaudeBot 都會抓取 JS 檔案卻從不執行；連結預覽服務只讀 HTML 的 meta 標籤。在主流爬蟲裡，目前已知具備完整 JS 渲染的只有 Googlebot——這是對演化中的世界所做的觀察，不是永久成立的分類，各家的渲染能力隨時可能改變。

這件事有三個後續影響。其一，這套統計看不見的機器流量遠多於看得見的——伺服器日誌裡的爬蟲比例與這裡的數字不可比較。其二，下一節那份具名清單接住的是「會執行 JS」與「誠實申報身分」的交集，比清單本身小得多；清單裡多數條目預期永遠不會命中，保留它們是為了接住少數會渲染的變體。

其三會影響上一章的判讀：來源網址空白的成因把「自動化抓取」列為其中一類，而這一節說明了那一類的實際佔比比直覺低——真正大量抓取的工具不執行 JS、根本不在這份資料裡。空白列偏向真人的機率因此比乍看之下高。

訊號分層與信心度

四個訊號的可靠度不同，分開記錄而不是合併成單一結論。

這個信心排序由誤差方向推導而來，不是本站資料測得的命中率。 沒有標註任何誤判比例是刻意的——那需要一份已知組成的對照流量，而本文的每個判準都停在「這個訊號可能怎麼錯」的層次。既然正確率無從得知，處置方式就不是「先用著、之後校正」，而是讓判定與使用分離：訊號照實記下、判定留在彙總端，改了規則之後可以拿同一批舊資料重跑比對。

navigator.webdriver 是自動化框架的預設標記。 Playwright、Puppeteer、Selenium 啟動的瀏覽器這個值都是 true，一般瀏覽器是 false。它的判別力強而誤判極少，代價是刻意規避偵測的工具第一件事就是把它蓋掉——因此它抓得到的是「沒有隱藏身分意圖」的自動化訪客。

UA 比對抓的是自我申報。 搜尋引擎與正派的抓取服務會在 User-Agent 裡寫明自己是誰，這是它們與網站經營者之間的慣例。比對這個字樣不會誤判真人，因為真人的瀏覽器不會自稱是機器。

空語言清單與零視窗尺寸原本是無頭環境的特徵，而這兩條正在失效。 Chrome 112 起的新無頭模式會建立一個不顯示的平台視窗，並帶有正常的語言偏好，兩項特徵大多不再成立。它們的誤差方向因此從「誤判真人」偏向「漏判機器」——保留是因為舊版工具仍在使用中，但不能當作主力。

因為誤差方向不同，記錄下來的是命中了哪些訊號、而不是一個布林結論：

 1function botSignal() {
 2  var hits = [];
 3  try {
 4    if (navigator.webdriver === true) hits.push("webdriver");
 5    // UA 比對見下一節
 6    if (!navigator.languages || navigator.languages.length === 0) hits.push("lang");
 7    if (!window.outerWidth || !window.outerHeight) hits.push("size");
 8  } catch (err) {
 9    // 偵測本身出錯不該影響統計，當作沒有訊號
10  }
11  return hits.join(",");
12}

這個設計讓判定閾值留在彙總端——也就是試算表那一側，資料寫進去之後用公式分類的地方。日後發現某條訊號誤判太多，改公式就好，不必改前端重新部署；而前端一旦部署出去，快取的頁面還會用舊版跑一段時間。

送出的字串寫進試算表的一個欄位，後面稱它為訊號欄。

具名比對與通用退回

UA 比對要回答的問題有兩層：「這是不是機器」以及「是哪一隻機器」。後者的價值在於處置方向不同——搜尋引擎索引是內容被收錄的證據，監控服務是自己設定的，而不具名的抓取工具才是需要留意的那一類。

直覺的作法是列一份已知名單做精確比對。這個作法單獨使用時有一個不會顯現的失效模式：名單會過時，而過時的表現是新出現的抓取工具完全不被標記——統計上呈現為自動化流量比例逐漸下降，而這個下降與「內容吸引到更多真人」在數字上不可區分。

因此比對分成兩層，讓過時的代價落在精度而非覆蓋：

 1// 以下兩個常數與比對邏輯接在上一段 botSignal() 的 try 區塊內，共用同一個 hits 陣列
 2// 已知抓取工具的自我申報名稱，命中時送出具體名稱
 3var KNOWN_BOTS = /claudebot|claude-user|claude-searchbot|gptbot|oai-searchbot|chatgpt-user|perplexitybot|googlebot|bingbot|applebot|duckduckbot|yandexbot|bytespider|amazonbot|ccbot|meta-externalagent|facebookexternalhit|twitterbot|linkedinbot|slackbot|discordbot|telegrambot|whatsapp|semrushbot|ahrefsbot|dotbot|petalbot/i;
 4// 通用字樣，接住誠實申報但不在具名清單裡的自動化訪客
 5var GENERIC_BOT = /bot\b|crawler|spider|headless|slurp|bingpreview|python-requests|curl\//i;
 6
 7var ua = navigator.userAgent || "";
 8var named = ua.match(KNOWN_BOTS);
 9var generic = named ? null : ua.match(GENERIC_BOT);
10if (named) hits.push("ua:" + named[0].toLowerCase());
11else if (generic) hits.push("ua:" + generic[0].toLowerCase().replace(/[^a-z]+$/, ""));

兩層的比對來源不同是關鍵：具名層比對的是身分（清單裡的名字），通用層匹配的是類別詞（bot、crawler、spider、headless），後者不需要知道任何一隻抓取工具的名字就能運作。清單過時時，新工具仍然被通用層接住——失去的是「知道是誰」，不是「知道有」。

上面的 GENERIC_BOT 裡混了 slurp、bingpreview、python-requests、curl/ 四個具體名稱，嚴格說它們屬於具名層——把產品名放進退回層，退回層就變成清單的延伸而不是獨立的一層。實際運作上它們是無害的殘留，但這個混用會讓「通用層純靠類別詞」這個保證打折：wget、Go-http-client、node-fetch、axios 這些同樣不含類別詞的 UA，兩層都接不住。

真正獨立於 UA 的那一層是 webdriver / lang / size ——它們讀的是瀏覽器環境而非字串，UA 比對整個失效時仍然運作。三層的關係值得明說：具名層給身分、通用層給類別、環境訊號層給「這個執行環境不像人用的」，而只有第三層完全不依賴任何列舉。

這個結構要能被觀測，標記本身得分得出層級。上面的寫法送出的是 ua:googlebot 與 ua:bot，而 ua:slurp 這種看起來像具名層、其實來自通用層——不比對兩條 regex 就分不出來。加一個前綴讓它自證：

1if (named) hits.push("ua:named:" + named[0].toLowerCase());
2else if (generic) hits.push("ua:generic:" + generic[0].toLowerCase().replace(/[^a-z]+$/, ""));

分得出層級之後，COUNTIF(訊號欄, "*ua:generic*") / COUNTIF(訊號欄, "*ua:*") 就是清單的過時指標：這個比例上升代表有新工具在被通用層接住、該更新具名清單了。這把「清單過時」從一件不可見的事變成一個可以看的數字，而且不需要有人事先知道漏了哪些新工具。抽象層的原則見 #251 清單過時的代價要落在精度、不落在覆蓋。

清單維護有一個實際邊界值得先講明。Anthropic 目前把不同用途拆成 ClaudeBot、Claude-User、Claude-SearchBot 多個 token，這類拆分會持續發生，而拆分後的新名稱在被加進清單前由通用層接住——那正是這個設計在運作。

另一個邊界是命名系統的混淆，而這份清單踩過一次。它上線時含有 google-extended 這個條目——那其實是 robots.txt 的控制 token，不會出現在任何請求的 User-Agent 裡，因此它從第一天起就是死的。系統不會回報「某個條目從未命中」，這個缺陷是靠一次外部查核才浮現的。robots.txt 的控制 token 與 UA 字串是兩套獨立的命名，這正是「訊號只能來自瀏覽器暴露給 JavaScript 的東西」這條限制的具體案例。

只送出命中的關鍵字、不送完整 userAgent，是前面那條界線的具體落實——那個關鍵字是抓取工具主動公開申報的身分，不構成指紋特徵。

行為訊號對沒有規避意圖的工具有效，代價是誤判方向指向真人

行為留下的痕跡比環境屬性稍微難改，但它們擋不住有規避意圖的工具。前面對 webdriver 說過的那句讓步在這裡同樣適用，而且成本更低：讓抓取工具在關閉前觸發一次 visibilitychange 是三行程式碼，隨機化頁面存活時間是一行，重用瀏覽器的 storage state 讓識別碼保持穩定是兩行——最後這項甚至提升效率，因為它本來就是自動化測試處理登入狀態的標準做法。

這一節的三個訊號在對象沒有隱藏意圖時判別力最強，同時誤判代價也最高——誤差方向一致指向「把真人判成機器」，而這個方向最難察覺，因為結果看起來是流量變乾淨了。

離開事件缺席是其中最直接的一個。抓取工具取得頁面內容後直接終止瀏覽器環境，不會經歷「頁面轉為不可見」這個狀態轉換，因此不產生離開事件。

真人這一側同樣會缺席，而且不罕見。事件模型列過那份丟失清單：記憶體回收、強制關閉、斷電、網路中斷、擴充功能攔截、接收端併發撞頂。行動流量佔比高的站，真人的離開事件缺席率本來就不低，把缺席直接當成機器訊號會系統性誤判這一群人。

只有離開事件、沒有進入事件這個相反的形態也一樣。可觀測的只有一件事：接收端在進入事件的時間點沒有收到任何請求。抓取工具的網路攔截設定是一種相容的成因——許多框架只放行文件與必要資源，等內容抓完、進入關閉流程時攔截器已經解除——但它只是幾個候選之一。

真人也會產生孤兒離開事件，至少三條路徑：接收端併發撞頂（執行配額的併發上限，見模組五的配額碰撞——爆量時同時湧入的進入事件被拒，離開事件數秒後送達時併發已消退，正好剩下孤兒）、廣告或隱私擴充功能攔截第一次請求、以及網路瞬斷。第一條特別值得注意，因為它與爆量時段重疊，會把流量高峰的真人整批劃給機器。

停留時間的一致性洩漏的是排程。抓取工具的頁面存活時間由設定決定，因此相隔數小時、來自不同識別碼的多列可能有精確相同的秒數。這一條需要區間限定：dur 經過取整為秒，而真人的跳出流量集中在最短的那幾秒，在那個區間裡精確重複是常態而非訊號。分界落在哪一秒由下一節的短停留分佈量出來，不是一個可以跨站沿用的固定值。只有落在跳出區間之外的精確重複才有判別力。

三個訊號各自的觀察都只有個位數的記錄撐著，所以它們指出的是「該往哪裡看」，不是「這一列是什麼」。

先量本站的基線

前面所有訊號都描述「機器可能長什麼樣」，而判定需要的是「這一列與本站的真人有多不一樣」。判準寫成絕對條件（缺席、為零、幾乎沒有）在換一個站之後就不成立：行動流量佔八成的站與桌機為主的站，真人的離開事件缺席率差距很大；剛上線五篇文章的站，真人的站內導覽比例天然接近零。

基線要用一批組成已知的流量來量，而唯一穩定可得的那批是自己的瀏覽：在設定 opt-out 之前刻意走幾條完整的閱讀路線，那批記錄裡每一列是誰產生的都確定。

第三欄不是免責聲明，它決定判讀的方向：站內來源比例的基線偏高，代表真實讀者低於這個值是正常的，拿它當「低於就可疑」的門檻會系統性誤判。四個指標的偏差方向都指向同一側——真人看起來比基線「差」。

有一種量法要避開：用「訊號欄乾淨」的記錄當已知樣本。那等於用被校正的偵測器定義校正用的樣本，結論會自我印證。同理，量離開事件缺席率時不能只取互動旗標為 1 的記錄——那個條件蘊含離開事件已經送達，算出來必然是零。

樣本規模也要誠實看待：刻意走幾條路線得到的是數十列，那個量足以看出量級差異（缺席率是一成還是六成），不足以做統計顯著性判斷。判準因此寫成「明顯偏離基線的量級」而非某個百分點門檻。

基線本身要重量：改版換了頁面結構、流量來源組成變化、行動裝置佔比上升，都會讓它漂移。

這一節的限制會累積到哪裡

前面每一節都交代了自己的限制：只有執行 JavaScript 的訪客會被記錄、離開事件會在幾種情境下丟失、訊號的誤差方向一致指向誤判真人。這些限制加上其他篇的（退出機制、配額漏記、儲存清除）共同界定了這份資料的母體，而母體決定了哪些結論下得出來——完整的總帳與外部對照方法見這份統計的分母是什麼。

標記而非丟棄

偵測到疑似自動化流量時有兩種處置：前端直接不送，或照常記錄並加上標記欄位。

這一章從頭到尾談的是標記，不是阻擋。靜態站託管層沒有可以攔請求的地方，這些訊號只在資料進來之後才產生作用——真的要擋抓取工具需要 CDN 或反向代理層的規則，那是另一個主題。

照常記錄買到的是三件不需要 ground truth 的事。 判定的正確率本身無從得知——這套統計沒有一份標好答案的對照資料，前面每個訊號都只能談誤差方向、談不了誤判率。真正的理由在別處：

改了規則之後可以重跑舊資料，比對同一批記錄在新舊規則下的分佈差多少。這回答不了「哪一個對」，但看得出「改動影響了多少列」，而那是決定要不要改的實際依據。

日後認出新的抓取工具時可以回溯標記。今天標成 ua:bot 的那些列，等它被加進具名清單之後仍在表裡，過去半年的歷史因此跟著變得可讀。丟掉的列沒有這個機會。

總量守恆檢查的前提就是列沒有被丟掉。前端過濾會讓分母本身失真，而分母失真時所有比例都不可信。

代價是試算表多存一些列，以及彙總時必須記得過濾。

對免費配額敏感、或流量大到列數成為問題時，取捨會反過來——那時應該只丟棄高信心訊號（webdriver 與具名 UA）命中的部分，中信心與行為訊號仍然照常記錄。

彙總端的分類與條件順序

分類邏輯把訊號與行為組合起來。以下是虛擬碼——欄位名要換成試算表的實際範圍參照，而每個閾值都該換成前面量出的基線值，寫成固定條件只是為了讓結構清楚：

1=IFS(
2  AND(事件="leave", 同session同路徑的view筆數=0), "待查-孤兒離開事件",
3  事件<>"view", "",
4  REGEXMATCH(訊號欄, "webdriver|ua"), "機器-高信心",
5  AND(同session的leave筆數=0, 裝置<>"mobile"), "待查-無離開事件",
6  訊號欄<>"", "訊號弱-待觀察",
7  同session的view筆數=1, "單頁即走",
8  AND(同session的leave筆數>0, 訊號欄=""), "真人",
9  TRUE, "未分類")

條件的順序承載語意。孤兒離開事件排在最前面，否則第二條會把所有離開事件留白，那一整類記錄就在統計裡消失了。非進入事件留白避免同一次瀏覽被計數兩次。

分類名稱用「待查」而非「爬蟲」是刻意的：行為訊號給的是需要進一步確認的候選。孤兒離開事件要對照執行項目同時段有沒有失敗紀錄——有的話那是配額問題而非機器。無離開事件那一條排除了行動裝置，因為真人在該環境的缺席率本來就高。

最後兩條分支的分工是刻意的。「真人」寫成顯式條件、catch-all 標成「未分類」，而不是反過來讓沒被接住的列直接落進「真人」——後者是這份報表最被消費、最不會被追問的類別，新的資料形狀靜默落進去只會讓數字變好看。IFS 在所有條件都不成立時回傳 #N/A，而滿欄的錯誤值與滿欄的留白一樣不會被追問，所以 catch-all 要給一個會被看見的標籤。這條防線的完整推導見假故障與靜默失效的診斷。

用總量守恆檢查這份分類時，作用域是進入事件那些列——離開事件被第二條留白，把它們算進分母會讓差額永遠等於離開事件的列數，而一個恆常的巨大差額只會訓練出忽略它的習慣。

下一步

判定規則到位了，接下來要問的是這些規則吃進去的資料本身可不可信。判定寫對了但公式算錯、程式改了但端點沒生效、錯誤訊息指向的位置不是問題的位置——假故障與靜默失效的診斷處理這三類。

爆量時段的漏記是另一回事，它來自配額而非判定，見模組五的配額、防濫用與隱私邊界。

實作拆成兩半，剛好對應架構的兩端。前端這半的重點是用對送出方式，避開靜態站打 Apps Script 最常見的 CORS 障礙。接收端這半的重點是把請求解析出來、安全地 append 進試算表。

章節文章

跨分類引用

• → 模組一：Apps Script 地基：doGet/doPost 與部署模型的完整說明
• → 模組三：Sheets 當資料庫：資料進來後的並發、資料模型與容量
• → 模組六：收到資料之後：這裡的 payload 只描述單次瀏覽，補上訪客識別、停留時間與自動化訊號之後才讀得出「幾個人來過、有沒有真的在讀」

這些問題有一個共同性質——它們只在真實流量打進來之後才浮現，設計階段推導不出來。模組零到五處理的是「怎麼把管線接起來」，那條路徑上的每個障礙（CORS preflight、部署授權、配額上限）都能從文件讀出來。這一章處理的是管線接好之後才出現的那一類問題：資料格式完全正確、程式沒有報錯、統計數字看起來合理，而結論是錯的。

補強的方向是給 payload 加上足以交叉判讀的欄位，並理解每個欄位的能力邊界。訪客識別回答「是不是同一個人」，事件模型回答「停留多久、有沒有真的在讀」，自動化訊號回答「這是不是機器」。三者互相驗證——單獨任何一個都能被繞過或誤判，組合起來才有判讀能力。

補強完之後還有一步：把各篇的限制加總，確定這份資料的母體涵蓋了誰。分母不清楚時，比例算得再精確也不知道在說什麼。

章節文章

欄位變更要同步到接收端

這一章的三篇實作都在前端的 payload 上加欄位，而接收端與試算表表頭不會自己跟著長。模組二的 doPost 是一個寫死的五欄陣列，新欄位送到之後會被靜默丟棄——沒有錯誤、沒有警告，只是那幾欄永遠是空的。這正是假故障與靜默失效的診斷講的欄位錯位，而它最容易發生在「跟著教學一路改前端」的過程裡。

三篇讀完之後，payload 會長成十一個欄位：

對應的接收端要把 appendRow 的陣列改成同樣長度，並讓表頭在工作表被清空時自動重建：

 1var HEADERS = ['時間', '路徑', '來源', '語言', '裝置',
 2               '事件', '訪客ID', 'SessionID', '自動化訊號', '停留秒數', '有互動'];
 3
 4function getLogSheet() {
 5  var ss = SpreadsheetApp.getActive();
 6  var sheet = ss.getSheetByName('工作表1') || ss.insertSheet('工作表1');
 7  if (sheet.getLastRow() === 0) {
 8    sheet.getRange(1, 1, 1, HEADERS.length).setValues([HEADERS]);
 9    sheet.setFrozenRows(1);
10  }
11  return sheet;
12}
13
14// doPost 內：陣列順序必須與 HEADERS 一致
15getLogSheet().appendRow([
16  new Date(), data.path || '', data.ref || '', data.lang || '', data.dev || '',
17  data.t || 'view', data.vid || '', data.sid || '', data.bot || '',
18  data.dur === undefined ? '' : data.dur,
19  data.act === undefined ? '' : data.act
20]);

把表頭建立放進讀取路徑而非一次性腳本，是因為一次性腳本有個隱性假設：「執行過了」這個狀態存在執行者的記憶裡、不在系統裡。固定位置的 setValues 重複執行結果相同，工作表被清空後也會自動重建。

改完之後記得走「管理部署作業 → 編輯 → 版本選新版本」讓端點跑新程式碼——改了程式碼卻沒更新部署是這裡最常見的假故障。

新欄位只對之後進來的資料生效。 既有的記錄不會回填，所以這一章教的判讀方法要等新資料累積一段時間才用得上；拿舊資料套新判準會得到「所有記錄都不可識別」這個沒有意義的結論。

讀者旅程

已經跟著模組二把資料收進來、正要開始看報表的人，從訪客識別順讀，並在動手改 payload 前先看上一節的欄位變更清單。

已經在懷疑手上的數字的人，入口看症狀分三條：某個分類永遠是零多半是資料模型變更後公式沒跟著改，推導在事件模型談報表公式換語意的那一節；懷疑數字裡混了機器走辨識自動化流量；想知道這些數字到底涵蓋了誰走這份統計的分母是什麼；流量突然變乾淨、或懷疑統計整個壞掉走假故障與靜默失效的診斷。

跨分類引用

• → 模組二：流量 beacon 實作：payload 的基本欄位與 CORS 障礙，本章的補強都疊在那個實作上
• → 模組三：Sheets 當資料庫：欄位增加後的資料模型與容量影響
• → 模組五：部署、配額與安全：隱私邊界與防濫用的完整討論，本章的 opt-out 是那一章「過濾自己的瀏覽」的具體實作
• → Monitoring 的事件分類：要收哪些事件、怎麼分類的概念層
• → Monitoring 的行為資料商業利用：漏斗、cohort 與歸因的分析框架，本章只處理自建管線的資料品質

靜態站的能力邊界很明確：瀏覽器把 HTML/JS 抓下來後，所有邏輯都在使用者的瀏覽器裡跑，沒有任何一段程式碼在你控制的伺服器上執行。這代表任何「要記在你這邊」的資料——誰來看過、表單填了什麼、累積計數——都需要一個瀏覽器以外、由你掌握的接收端。這個接收端不必是傳統伺服器；它可以是一段掛在免費平台上、只在被呼叫時才執行的函式。本指南教怎麼用這種函式把靜態站的能力補齊。

貫穿全指南的案例是「幫這個架在 GitHub Pages 上的 blog 做流量統計」。GitHub Pages 不給 access log、也不能跑伺服器端程式碼，所以流量資料只能靠瀏覽器主動回報。這個案例會從模組零的架構推導、一路實作到模組六的資料判讀，讀者跟著做完會得到一個真的能用、資料存在自己試算表裡的流量統計系統——「自己手上」在這裡指的是資料的控制權與查詢自由，基礎設施仍然是 Google 託管的。

第一種膠水工具選 Google Apps Script + Google Sheets：它對個人 Google 帳號免費、不需要信用卡、Sheets 直接當資料庫兼儀表板，起步門檻是所有選項裡最低的。指南後續會加入其他膠水工具（例如 Cloudflare Workers）作為對照，說明各自的適用邊界——Apps Script 適合資料量小、需要人可直接讀寫試算表的場景；當量體變大或需要低延遲時，模組五會給出換工具的判準與遷移路徑。

教材邊界

流量分析的概念層（事件分類、漏斗、cohort、歸因）不在本指南，在 Monitoring 監控體系。本指南是動手做的那一半：怎麼用免費工具把資料真的收進來、存起來、彙總出報表。兩者互補——先看 Monitoring 想清楚要收什麼，再回本指南把管線搭起來。

Backlog

跨模組那一列是目前唯一的結構性不對稱：本指南對 monitoring 有五條引用，反向零條，而 monitoring 的漏斗與 cohort 分析都預設資料乾淨、可識別、無機器混入——那些前提正是模組六在處理的。

模組六補上了資料判讀，但彙總層仍停在模組四的單事件版本——那裡目前只標明了前提與修法方向，尚未有一篇把「配對進入與離開事件、算出平均停留與閱讀深度」實作出來。順序上它依賴模組六的事件模型定案，因此排在其後。

章節

模組零到五走的是「怎麼把管線接起來」，那條路徑上的每個障礙都能從文件讀出來。模組六的位置不同——它處理管線接好、資料真的開始累積之後才浮現的問題：來源網址大量空白、任兩列之間看不出是不是同一個人、真人與機器抓取混在一起。這些無法在設計階段推導，只有真實流量打進來才會現形。

讀者旅程

想直接把流量統計做出來：模組零建立架構直覺後，跳模組二照著實作，缺概念再回模組一補。想完整理解這套膠水模式、之後套用到其他專案：模組零到六順讀。已經收到資料、正要開始看報表：直接進模組六。只想查某個 Apps Script 術語：看 knowledge-cards。