概念位置

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 障礙。

概念位置

部署有兩個決定端點行為的設定。執行身分（execute as） 決定程式用誰的權限跑：選「我」時，匿名訪客送來的請求也用你的身分執行，才能存取你的試算表。誰可存取（who has access） 決定誰能呼叫這個網址：接收匿名訪客的 beacon 必須選「所有人」，因為訪客沒有登入 Google。

可觀察訊號與例子

一個實務要點是部署與網址的關係：每次「新增部署作業」會產生一個新網址，但改完程式後應該用「管理部署作業」更新既有部署，網址才不變。用錯方式會讓前端指向舊網址、以為程式沒生效。

判讀方式

誰可存取設為「所有人」後，要判斷的是匿名端點被濫用的風險有多大：存取權限的安全含義見模組五。

概念位置

事件物件只帶請求的內容，不帶任何 HTTP 標頭——User-Agent 與來源 IP 在這裡都讀不到。伺服器端常見的 UA 比對與 IP 判斷因此不可用，需要那些資訊時只能由前端蒐集後放進請求主體送來（見辨識自動化流量）。

兩個函式都必須回傳一個 ContentService 或 HtmlService 的輸出，這是平台的硬性要求；不回傳會被當成執行沒有正常結束。接收 beacon 這類「送資料進來」的場景用 doPost，因為 sendBeacon 送的是 POST，主體放在 e.postData.contents（是個字串，需要自己 JSON.parse）。

可觀察訊號與例子

一個影響靜態站的關鍵限制是：Apps Script 沒有 doOptions。跨網域請求的 CORS preflight 會送 OPTIONS，但它打不到你的程式、平台的預設回應也不帶 CORS 許可標頭，於是 preflight 失敗、真正的請求送不出去。

判讀方式

這是「用 fetch 送 application/json 打 Apps Script 得到 CORS 錯誤」的根因，繞法是讓請求成為不觸發 preflight 的 simple request，見前端 beacon 與 CORS 障礙。

概念位置

觸發器的 90 分鐘每日總時間是另一條線，影響的是時間觸發器做的排程彙總，不是接收 beacon。

可觀察訊號與例子

估算容量時該看的是併發而非總量。接收 beacon 的膠水層，每次執行只寫一筆、幾百毫秒結束，遠用不到 6 分鐘；binding 的限制是「同一瞬間最多 30 個 beacon 在處理」。個人 blog 的流量分散在整天、任何瞬間的併發都遠低於 30，所以不會撞牆；會逼近上限的是「某篇文章短時間爆量」這種尖峰。

判讀方式

值得注意的是個人帳號的配額比 Google Workspace 帳號低，所以同一段程式在測試帳號能過、在別的帳號可能撞限。碰到配額上限的處理見模組五。

概念位置

流量統計用它把 beacon 累積的原始 log 每天彙總成一張日報表，實作見模組四。

可觀察訊號與例子

時間觸發器可以設成每分鐘、每小時、每天固定時段、或每週執行。典型用法是「每天凌晨把前一天的 raw log 依日期與路徑 group 成彙總表」，讓人打開試算表看到的是整理過的數字、而不是逐筆原始紀錄。

判讀方式

觸發器的成本受執行配額約束：個人帳號所有觸發器每天總執行時間上限 90 分鐘。所以彙總邏輯要寫得有效率，資料量大時避免每次都全表掃描——這條線在原始 log 累積到很多列時才會逼近，判讀與最佳化見模組三：Sheets 的容量邊界。

概念位置

指紋與識別碼是兩種不同的識別途徑。識別碼（存在 localStorage 的隨機值）由網站產生、使用者可以清除、內容不從個人推導；指紋由使用者的環境被動產生、清除不掉、也不需要對方同意就能取得。這個差別決定了設計取向：自建統計要辨識「是不是同一個瀏覽器」時用識別碼，用指紋做同一件事會在使用者無法拒絕的前提下達成，兩者的技術效果相近而性質不同。指紋的另一個用途是分辨自動化環境。在 Apps Script 這類接收端上，判別素材只能由前端蒐集後隨 beacon 送出——doPost 拿不到任何 HTTP 標頭，伺服器端的 UA 與 IP 比對都不可用。做法與邊界見辨識自動化流量。

可觀察訊號與例子

高熵的屬性包括完整 userAgent（含版本與作業系統細節）、螢幕解析度與色彩深度、時區、字型清單、WebGL 渲染器名稱。低熵而仍有分析價值的替代品是把這些降維成分類標籤——mobile / tablet / desktop 三選一的裝置類別由 userAgent 推導而來，但送出的是分類結果而非原始字串，唯一性大幅下降而排版決策所需的資訊仍然保留。

判讀方式

判斷一個欄位該不該送，問它「單獨無害，但與已送出的欄位組合後唯一性有多高」。答案是「組合後接近唯一」時，改送降維後的分類標籤而非原始值。這條界線在訪客識別與 opt-out的隱私邊界段有完整的取捨說明，配額與 PII 的整體討論見 execution quota 所在的模組五。

概念位置

這個頁面回答的問題是「請求有沒有抵達端點」，而它把故障範圍切成兩半：有執行紀錄但狀態失敗代表請求送達了、接收端出錯；完全沒有對應時間的執行紀錄代表請求根本沒送出來，問題在瀏覽器端或網路。兩者的排查方向相反，而在此之前它們的症狀完全相同——試算表都沒有新資料。

它與 Logger.log 的分工也在這裡：Logger 記錄的是程式自己選擇要說的話，執行項目記錄的是平台觀察到的事實，程式在第一行就爆掉時前者什麼都沒有、後者仍有一列失敗紀錄。判讀失敗紀錄時常要對照執行配額的三條上限，因為逼近上限的症狀（耗時拉長、密集失敗）都先出現在這一頁。

可觀察訊號與例子

一次正常的 beacon 接收在這裡是「doPost / 網頁應用程式 / 一秒出頭 / 已完成」。耗時異常拉長是逼近執行配額單次上限的前兆；同一時段出現大量失敗則指向併發撞頂。

版本欄位還洩漏另一件事：它顯示這次執行用的是哪一個部署版本，因此「程式碼改了但端點跑舊版」這個假故障在這裡看得出來。

判讀方式

排查「資料沒進來」時先開這一頁，再決定往哪個方向查——這一步的成本是開一個頁面，而它省下的是往錯誤方向排查的整段時間。實際運用見假故障與靜默失效的診斷。