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

來源網址為什麼大量空白

來源網址（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，任何人都能讀原始碼驗證，所以說明必須與實作一致。退出的入口要放在讀者找得到的地方，而不是只寫在原始碼註解裡。

下一步

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

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

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

進入與離開拆成兩則事件

模型是每次瀏覽產生兩列：進入事件在頁面載入時送出，離開事件在頁面不再可見時送出，兩列靠 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 要給一個會被看見的標籤。這條防線的完整推導見假故障與靜默失效的診斷。

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

下一步

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

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

這一篇把散落的限制收成一張總帳，理由是報表上的每個數字都會被拿去回答某個問題，而問題答得準不準取決於母體涵蓋了誰。不知道分母的比例沒有意義。

看不見的部分

七條的性質不同，處置方向也不同，值得分開看。

第一條是刻意的。 多數抓取工具不執行 JavaScript，因此不會出現在這份資料裡——這正是辨識自動化流量那一篇說明的結構限制。它讓這份統計比伺服器日誌乾淨，代價是兩者的爬蟲比例完全不可比較。看過日誌裡「七成流量是機器」那類數字的人，不要拿它與這裡的數字對照。

第二條是最容易被低估、也最沒有痕跡的一條。 接收端的網址對本站而言是外部網域，而 uBlock Origin 與 Brave 的預設規則會攔下大量指向分析類端點的請求。被攔下時什麼都不會留下——沒有失敗紀錄、沒有孤兒事件、沒有任何欄位是空的，那次瀏覽就是不存在。這條損失無法從資料內部觀測，只能從外部估（下一節談怎麼估）。讀者組成越偏技術，這一塊越大，而技術部落格的讀者組成正是最偏的那一端。

第三與第四條是小量但方向明確的。 停用 JavaScript 的訪客現在很少；退出統計的讀者則是自己設計出來的缺口，那個缺口存在本身比它的大小重要。

第五條與第六條影響的是行為欄位而非計數。 離開事件遺失讓停留時間與互動旗標偏向缺失，而缺失集中在行動裝置；配額撞頂只在流量尖峰發生，症狀是那個時段的數字偏低。兩者都不影響「哪一篇被打開幾次」這個基準線，只影響建立在行為欄位上的判讀。

第七條讓回訪率單向偏低。 Safari 的追蹤預防機制清除儲存資料之後，同一個人回來會拿到新的訪客識別碼，在資料上是新訪客。這個偏差不會反向發生——不會有人被誤判成回訪——所以回訪率永遠是低估，而低估幅度隨 Safari 讀者佔比變動。

怎麼估自己站的量級

表格裡的量級判斷是方向性的，實際比例要靠外部對照才估得出來。三個成本不高的作法：

用兩個瀏覽器環境自測攔截率。 一個乾淨、一個裝上常見的內容攔截器，各自走一遍相同的路徑，比對記錄有沒有進來。這量不出站上的實際比例，但能確認攔截會不會發生——如果連常見設定都擋得住，那條損失就是真的存在而非理論風險。

拿搜尋主控台的點擊數當外部對照。 Google Search Console 記錄的是搜尋結果的點擊次數，那個計數發生在讀者的瀏覽器之外、不受 JavaScript 與攔截器影響。用同一段時間、同一批頁面比對兩邊的數字，差額大致就是這份統計漏掉的搜尋流量比例。這是這個架構下最容易取得的一把外部尺。

看自己的裝置分佈與已知的偏差方向對不對得上。 若記錄裡行動裝置佔比明顯低於一般內容網站的水準，可能的解釋之一是行動端的離開事件與整段瀏覽更容易丟失，而不是讀者真的都用桌機。

三種作法都不會給出精確的修正係數，它們的用途是判斷「漏掉的量是百分之幾還是幾成」——而那個量級足以決定一個結論能不能下。

這份統計適合回答什麼

相對問題可以回答：哪幾篇比較多人讀、這個月比上個月如何、哪些路徑常被連著讀、哪一篇的停留時間明顯偏短。這些問題的答案建立在「各種損失通道在比較的兩邊大致相同」這個前提上，而在同一個站、相近的時間範圍內，這個前提通常成立。

絕對問題不適合回答：有多少人看過、真實的跳出率是多少、有多少比例的讀者會回訪。這些數字永遠是低估，而低估的幅度無法從資料本身估出來——這正是上一節要用外部對照的原因。

有一類問題落在中間，判斷起來要小心：跨時間的比較在損失通道本身改變時會失效。改版換了頁面結構、內容主題從技術轉向非技術（讀者的攔截器安裝率隨之改變）、加了新的 JavaScript 讓載入變慢，都會讓前後兩段時間的分母不同。看到某個指標長期趨勢反轉時，先確認是不是分母變了。

這張總帳怎麼影響最初的選擇

模組零的自建取捨當時給的判準是「想搞懂機制運作，或資料必須在自己手上」。走到這裡之後，那個取捨可以帶著具體內容重算一次。

值得注意的是，這些限制大部分不是自建造成的。JavaScript 觸發、攔截器、瀏覽器的儲存清除政策同樣適用於 Plausible、Umami、GoatCounter 或任何靠前端腳本收資料的服務——它們的網域出現在攔截清單上的機率甚至更高。自建額外承擔的是實作與維護：退出機制、欄位變更同步、判讀規則的更新。

所以重算的問題不是「自建的數字準不準」，而是「知道這些限制之後，還願不願意為了資料的控制權與理解的深度承擔那些維護工作」。答案是否定的話，換成現成服務不會損失準確度，只會換成另一組別人幫忙維護的限制。

下一步

母體界定清楚之後，剩下的是確認收集鏈本身健康——判定規則寫對了但公式算錯、程式改了但端點沒生效、錯誤訊息指向的位置不是問題的位置，見假故障與靜默失效的診斷。想回頭看某一條損失的機制細節：JavaScript 觸發前提與抓取工具見辨識自動化流量、離開事件遺失見事件模型與停留時間、退出機制與儲存清除見訪客識別與 opt-out、配額碰撞見模組五的配額、防濫用與隱私邊界。

這套統計的執行環境被切成四段——頁面上的 JavaScript、Apps Script 的部署層、接收端程式碼、Google 試算表——而每一段的狀態各自獨立。任何一段沒跟上都不會產生跨段的錯誤訊號，這是免伺服器架構特別容易產生假故障的結構原因。

錯誤訊息指向的位置不是問題的位置

Google 服務類別的查詢方法在找不到目標時回傳 null，而不是拋出例外。錯誤因此延後到使用回傳值的那一刻才發生：

1function inspectHeaders() {
2  var sheet = SpreadsheetApp.getActive().getSheetByName('log');
3  var lastCol = sheet.getLastColumn();   // TypeError: Cannot read properties of null
4}

訊息指向 getLastColumn，而真正的問題在上一行——這個試算表裡沒有名為 log 的工作表。判讀規則是：訊息形如「無法讀取 null 的某屬性」時，問題在產生那個 null 的地方，不在使用它的地方。

診斷方式是把假設換成觀測：先列出實際存在的工作表，再對照程式碼裡寫的名稱。

1function listSheets() {
2  SpreadsheetApp.getActive().getSheets().forEach(function (sheet) {
3    var lastCol = sheet.getLastColumn();
4    Logger.log('工作表「%s」 欄數=%s 列數=%s', sheet.getName(), lastCol, sheet.getLastRow());
5  });
6}

這段程式碼的價值在於它不帶任何關於名稱的假設。同樣的模式適用於所有「用名稱或 ID 取得物件」的 API——先列出實際存在的東西，再對照程式碼裡寫的。

有一個延伸判讀值得記住：getActive() 回傳的是這個 Apps Script 專案所綁定的試算表。專案綁在 A 表、而資料寫進 B 表（透過 openById）是完全合法的配置，這時 getActive() 拿到的是 A 表。工作表名稱與欄位都對不上時，要先確認取得試算表的方式，再懷疑工作表名稱。

程式改了但端點沒生效

Apps Script 把「編輯器裡的程式碼」與「端點服務的版本」設計成兩個獨立狀態。手動執行函式跑的是前者，HTTP 請求打到的是後者——這代表「我執行某個函式成功了」與「端點跑的是新版」是兩件事，前者成立不推出後者。

這個設計本身是合理的版本控制：可以邊改程式碼邊讓線上端點維持穩定，改完再一次切版。代價是「改了沒生效」成為最常見的假故障。

判讀的訣竅是問一個問題：這次觸發是自己按的，還是外面打進來的。自己按的走編輯器最新碼，外面打進來的走部署版本。症狀是「手動測試都對、實際收到的資料卻是舊格式」時，答案幾乎必定是部署版本沒更新。

更新的操作是「管理部署作業 → 編輯 → 版本選新版本 → 部署」，這會保持網址不變（web app 部署的更新語意）。用「新增部署作業」會產生新網址，前端設定的端點就對不上了——這一點與模組一的部署模型講的是同一件事，只是從故障診斷的方向再看一次。

驗證用執行項目頁面：它列出每一次 doPost 的執行時間、耗時與狀態。這個頁面能回答一個關鍵問題——請求到底有沒有打到端點：

• 有執行紀錄但狀態失敗：請求送達了，接收端出錯
• 完全沒有對應時間的執行紀錄：請求根本沒送達，問題在瀏覽器端或網路

這個分岔把排查範圍砍半，而且它的證據來自平台本身，不依賴任何推測。實際運用的例子是判斷「某些記錄只有離開事件、沒有進入事件」的成因：執行紀錄裡完全找不到進入事件對應時間的執行，因此問題落在接收端之前——請求根本沒送出來。

這一步能確定的就到這裡。再往下的「為什麼沒送出來」屬於假說，執行紀錄支撐不了它：可能是那個瀏覽器環境攔截了頁面載入期間的請求，也可能是接收端當時併發撞頂而請求被拒（那會留下失敗紀錄，可以排除），或是網路瞬斷。把觀測與解釋分開記錄，之後拿到更多樣本時才知道哪一個假說被推翻了。

靜默失效：合法執行、輸出合法、數字是錯的

第三類故障持續執行、持續產出看起來合理的數字，而數字是錯的——前兩類至少會停下來。

試算表的分類公式是典型場所，而它最難察覺的形態是「修正一個問題時引入下一個」。事件模型那一章示範過第一次：單事件模型下的計數條件在雙事件模型下永遠不成立，那個分類的計數從此恆為零。

修法是把事件型別加進條件，而修正版的開頭多了一句「非進入事件的列一律留白」——避免同一次瀏覽被計數兩次。第二次失效就出在那一句。 它預設每次瀏覽都有進入事件，而真實資料裡存在只有離開事件的記錄（成因見上一節）。這些列被開頭那個條件整批留白，於是一整類資料在統計裡完全不存在——這不是算錯，是那一類從報表上消失了。

兩次的共同形態相同：公式沒有語法錯誤、沒有回傳錯誤值，只有分佈變了。

零是這裡最危險的輸出，因為它與「沒有這種流量」完全不可區分。 要察覺算錯，得先有一個獨立來源知道這裡本來應該有多少——而分析公式存在的理由，正是因為沒有那個獨立來源。

三個作法讓這類失效可被發現：

用總量守恆檢查涵蓋。 分類後各類數量的總和與原始列數的差額應該為零。差額不為零代表有資料形狀沒被任何條件接住，而這個檢查不要求預先知道漏了什麼——這是它比逐條檢視有效的地方。

讓未涵蓋的資料顯示成標籤而非留白。 分類邏輯的最後放一個 catch-all 分支，把沒被接住的列標成「未分類」。留白與「不適用」在視覺上不可區分，而一個會被看見的標籤才有機會促使人去查。

資料模型變更時把公式的重算納入同一次變更。 分析邏輯是資料模型的下游依賴，與欄位定義、寫入程式碼屬於同一次變更的範圍——延後處理的代價與重算的方法見事件模型那一節的示範。

抽象層的完整推導見 #250 資料多出一種形狀時，既有分析邏輯靜默換語意。

診斷順序

三類故障的排查有一個共通的推進方式：沿著資料的路徑，逐段確認實際狀態，而不是逐段確認程式碼寫了什麼。

三段的觀測值需要補充。瀏覽器那一段看的是請求有沒有發出，而它沒發出通常有兩個良性成因：beacon 前端有一道網域判斷（只在正式站送、本機預覽不送），以及讀者可能設過退出標記——兩者都會讓程式在送出前就返回，看起來與故障相同。

傳輸途中那一段是「發出了但沒抵達」的落點。接收端是一個外部網域，廣告與隱私擴充功能的通用規則可能直接擋下這個請求；瀏覽器的網路面板會顯示它被封鎖而非失敗。這一段存在的理由是前後兩段都答不了它：瀏覽器說「我送了」、執行紀錄說「我沒收到」，兩邊都沒說謊。

彙總排程那一段容易被漏掉，因為它不在 beacon 的即時路徑上。定時彙總讀的是同一張表，而它有自己的一組常數（讀幾欄、事件型別在第幾欄），資料模型變更時它們與分析公式同樣需要重算。

試算表那一段看的是最新一列的時間戳與欄位對位。欄位錯位與資料沒寫進去是兩種不同的故障——前者每一格都有值、看起來完全正常，成因是寫入端的欄位順序與表頭不同步，而它不會產生任何錯誤。

每一段都有一個「不看程式碼就能得到的觀測值」，這是這張表的設計重點。讀程式碼只能知道它宣稱會做什麼，而這幾類故障的成因全都是宣稱與實際之間的落差——落差只有實際觀測才看得見。

下一步

收集鏈確認健康之後，資料判讀的環節分別是：識別欄位見訪客識別與 opt-out、行為欄位見事件模型與停留時間、判定規則見辨識自動化流量、而這些欄位加總起來涵蓋了誰見這份統計的分母是什麼。配額耗盡導致的漏記是另一類成因，見模組五的配額碰撞與防濫用。