execute as 與 who has access 的分工

部署 web app 時的兩個設定，一個決定「用誰的權限跑」、一個決定「誰能呼叫」，安全含義不同。

execute as（執行身分）決定程式用誰的權限執行。 選「我」時，任何打進來的請求都以你的身分執行程式——這是必要的，因為匿名訪客沒有你試算表的寫入權，只有用你的身分才寫得進去。它的含義是：這支程式能碰的資料範圍等於你授權給它的範圍（那一張試算表），而不是呼叫者的權限。所以程式裡只該做你願意讓匿名請求觸發的事——doPost 寫一列 log 是安全的，但如果程式裡寫了「刪除整張表」的邏輯，那也會用你的權限被匿名觸發。

who has access（誰可以存取）決定誰能呼叫這個網址。 接匿名 beacon 必須選「所有人」（完全不需登入），這也表示網址一旦洩漏（而它必然公開，見下一段），任何人都能呼叫。這兩個設定合起來的效果是：一個任何人都能觸發、但只會執行你寫的那幾行、且以你的身分操作你授權的那張表的端點。

這個網址必然公開

beacon 端點的網址會被寫進每一頁的 client-side JavaScript，任何人檢視原始碼都看得到。它藏不住，這是 client beacon 架構的本質、不是設定失誤——GA、Cloudflare Web Analytics 那些的收集端點同樣是公開的。所以安全策略不能建立在「保密網址」上，而要建立在「限制這個公開端點能造成的破壞」上。

這也界定了什麼不是風險：別人拿到網址讀不到你的 Sheet，因為 doPost 只做 appendRow 然後回一個固定的 {ok:true}，不回傳任何試算表內容；他也碰不到你其他 Google 資料，因為授權範圍只綁那張表。端點是「只能寫、寫入內容固定、回應不洩漏」的，這個形狀本身就把資料外洩排除了。

實際的風險範圍

公開端點的真實風險是騷擾型的，有兩種。髒資料：有人直接對網址 POST 任意內容，往你的 log 塞垃圾列、污染統計。配額消耗：有人狂打這個端點，吃掉你的執行配額，嚴重時排擠正常 beacon（配額的細節見配額、濫用與隱私）。

這兩種風險的共通點是它們不會洩漏或破壞你的資料，只會污染統計或耗資源。對沒沒無聞的個人 blog，攻擊者缺乏動機花力氣灌一個小站的瀏覽計數，實際發生機率低。所以務實的姿態是：先讓公開端點跑著、把「限制破壞範圍」的保護當成「遇到再加」的選項，而不是上線前就必備。具體的防護手段在下一篇。

更新部署不換網址（安全角度）

日常維護會反覆改 doPost，改完要讓 /exec 反映新版本、而網址不變——用「管理部署作業 → 編輯 → 版本選新版本」，不要用「新增部署作業」（那會產生新網址）。這個操作除了避免假故障（見web app 部署模型），也有安全意義：換網址意味著舊網址可能還殘留在快取的頁面裡繼續被打，管理起來多一個要追蹤的公開端點。用同一個部署更新，公開端點就始終只有一個、行為可控。

下一步

存取權限的安全框架清楚後，配額實際會怎麼碰撞、怎麼擋濫用、隱私怎麼守、以及量大到該遷移的訊號，見配額、濫用與隱私。

配額實際碰撞會怎樣

免費配額的三條線（單次 6 分鐘、同時併發 30、觸發器每日 90 分鐘，見執行配額）在正常個人 blog 幾乎碰不到，但知道碰到時的症狀有助於診斷。

同時併發 30 是接收 beacon 最可能先碰的線：某篇文章瞬間爆紅、一秒內湧入超過 30 個瀏覽，第 31 個以後的 doPost 會拿到錯誤、那幾筆瀏覽漏記。症狀是「爆量時段的統計數字明顯偏低」。單次 6 分鐘 接 beacon 用不到（寫一列幾百毫秒），但彙總 trigger 全表掃描在資料很多時會逼近，症狀是彙總 trigger 開始逾時失敗。每日 90 分鐘 是所有觸發器加總，正常一天彙總一次遠遠用不完，除非彙總寫得很沒效率或觸發器被重複註冊。

碰到併發上限的處理不是「調高配額」（個人帳號調不了），而是「削峰」——beacon 本來就是可容忍少量遺失的統計，爆量漏記幾筆不影響「哪篇熱門」的判斷；真的很在意，訊號就指向遷移到吞吐更高的 Workers。

濫用防護與資料乾淨度

公開端點的騷擾型風險（髒資料、配額消耗，見部署與存取權限），對應兩個層級的防護。

過濾自己的瀏覽是最先該做、報酬最高的一項——不是防外人，是防站主把開發與自我瀏覽混進統計。前端的 hostname guard 已經擋掉本機預覽（見前端 beacon）；要進一步排除「在正式站上自己一直重整」，可以在瀏覽器存一個退出標記、beacon 讀到就不送，或彙總時依訪客識別碼過濾。兩者的取捨在於前者省下配額與列數、後者保留資料可回頭校正，而它們可以並用。退出標記的實作、邊界與各瀏覽器的差異見訪客識別與 opt-out——存標記的版本同時也是給讀者的退出入口，適合公開在網站說明裡。

擋隨手亂打用一個約定 token：前端 payload 放一個固定字串、doPost 檢查對不上就丟掉不寫。這能擋掉不知情的爬蟲與隨手 POST，成本很低。但要誠實看待它的邊界：token 也在 client JS 裡看得到，鐵了心要灌的人抓一下原始碼就有——所以 token 是「擋雜訊」不是「擋攻擊」。對個人 blog，擋雜訊通常就夠了；真的被針對性灌爆，那是遷移到有更多防護手段（rate limiting、驗證）的平台的訊號。

隱私與 PII 邊界

這套統計在隱私上的立足點是根本不收集個人身分資訊，這讓它天然乾淨。具體有三條線值得明確守住：

• 不記 IP：Apps Script 的 web app 收不到訪客 IP，所以就算想記也記不到——這反而是好事，少一個 PII 來源。
• 裝置只送粗標籤：mobile / tablet / desktop 三選一足以回答「用什麼裝置看」，不送完整 userAgent（那帶版本等可組成瀏覽器指紋的細節）。
• 不放可識別個人的欄位：這一章講到的 payload 只有路徑、來源、語言、裝置，沒有任何綁到個人的東西。模組六會加上兩個隨機識別碼——它們同樣不含個人資訊，但確實會被寫進瀏覽器的儲存空間，下一段的同意機制討論就是為此。

不收 PII 讓「處理個資刪除請求」這類負擔不會發生，但同意機制的判斷不是由 PII 決定的。歐盟 ePrivacy 指令第 5(3) 條管的是「在使用者終端設備儲存或讀取資訊」這個動作本身，與存的內容是否為個資無關——市面上宣稱免同意橫幅的分析服務（Plausible、Fathom）之所以能這樣宣稱，正是因為它們完全不在瀏覽器儲存任何識別碼。模組六的訪客識別在 localStorage 存了兩個，因此那一步跨過了這條線。

實務上個人網站的合規風險與商業追蹤網路不在同一個量級，但這是取捨不是豁免。想更保守，可以尊重瀏覽器的 Do Not Track 訊號（navigator.doNotTrack === "1" 時不送 beacon），或者不存識別碼、只做頁面計數。

遷移訊號：什麼時候該離開 Sheets

Apps Script + Sheets 是為「量小、要人直接看試算表」設計的（選型見模組零）。以下訊號累積出現時，代表量已經長到該換更重的工具：

• 爆量時段頻繁撞併發上限、漏記明顯到影響判斷。
• 彙總 trigger 即使分表、只讀增量後仍逼近 6 分鐘。
• raw log 的 cell 數逼近試算表上限（見資料模型與容量邊界）。
• 需要的查詢已經超出試算表能力（多維交叉、即時儀表板）。

遷移的方向是把接收端換成 Cloudflare Workers、儲存換成 D1（免費 SQLite）：吞吐與查詢能力遠高於 Sheets，代價是失去「打開試算表就能看」的便利、要自己做查詢介面。判準用一句話收斂：當「Sheets 即儀表板」的便利已經被它的容量與吞吐限制抵銷，就是遷移的時機——在那之前，簡單版一直是對的選擇。

管線完成之後

到這裡，一套不租主機、資料存在自己試算表裡的流量統計已經建好，而且知道它的配額邊界、防濫用手段與遷移訊號在哪。

管線能跑，不代表資料讀得出意義。 收到的來源網址大量空白、任兩列之間看不出是不是同一個人、真人與機器抓取混在一起——這些問題只在真實流量打進來之後才浮現，處理方式見模組六：收到資料之後。那一章會在 payload 上增加欄位，本章的配額判斷也會因為列數翻倍而需要重算。

想把同一套膠水模式套到別的靜態站或別的工具，回模組零的選型重新判斷即可。