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

流量統計的本質是「把每一次瀏覽記在某個你能事後查詢的地方」。傳統有伺服器的網站天生做得到，因為每個請求都會經過你的伺服器，伺服器在回應頁面的同時，順手在 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 實作。

免費額度該看併發，不看總量

Google Apps Script 對個人（gmail.com）帳號的關鍵限制有這幾條：

對一個接住 beacon、寫一筆進 Sheet 的膠水層，binding 的限制是同時併發 30。這條線的意思是：只要不是在同一瞬間有超過 30 個人的瀏覽器同時打 beacon 進來，就不會撞牆。一篇文章一天被看一千次、但這一千次分散在整天，任何瞬間的併發都遠低於 30，完全沒問題。會出事的情境是「某篇文章上了熱門、一分鐘湧入幾百個瀏覽」——這時併發才可能逼近 30，多出來的請求會拿到錯誤。

值得注意的是，Google 並沒有為個人帳號的 web app 每日呼叫次數公布一個硬性數字，所以正確的估算方式不是去湊「一天幾次」，而是問「我的流量會不會在某個瞬間有 30 個以上的同時請求」。對個人 blog，答案幾乎都是不會。

Apps Script vs Cloudflare Workers 的適用邊界

Apps Script 跟 Cloudflare Workers 都能當免費膠水層接住 beacon，但它們補的場景不一樣。選錯不會壞，但會讓你在錯的地方費力。

Apps Script 適合資料量小、需要人直接讀寫試算表的場景。 它最大的優勢是 Google Sheet 同時是儲存體跟儀表板——資料一 append 進去，你打開試算表就能看、能排序、能畫圖、能用樞紐分析，不必另外做前端。起步不需要信用卡、不需要買 domain、不需要學部署工具。代價是效能：每次執行有冷啟動延遲，Sheets 當資料庫在資料列數很多時讀寫會變慢，併發上限只有 30。對「一個人的 blog 想知道哪篇有人看」，這些代價都碰不到。

Cloudflare Workers 適合量體較大、需要低延遲的場景。 免費方案給到每天十萬次請求量級，冷啟動幾乎感覺不到，全球邊緣節點讓 beacon 延遲很低。代價是它沒有內建的試算表 UI——資料要存進搭配的 KV 或 D1（免費的 SQLite），看資料得自己寫查詢或做一個小前端。它更接近「一段真的後端程式」，彈性大但要自己搭的部分多。

選型判準用一句話收斂：先問資料要不要讓人打開試算表直接看、量會不會大到讓 Sheets 變慢。 想要試算表即儀表板、量不大——Apps Script。要低延遲或預期量大、能接受自己搭查詢介面——Workers。本指南先走 Apps Script，因為它把「看資料」這件事直接解決了，最適合第一次做流量統計、想快點看到成果的人。模組五會給出「Sheets 開始撐不住時怎麼判斷、怎麼往 Workers 遷移」的訊號與路徑。

自建與現成分析服務的差異

前面比較的兩個選項都是「自己搭」。在動手之前值得先看一眼另一條路：Google Analytics、Plausible、Umami、GoatCounter 這類現成服務同樣是貼一段 JS 就開始收資料，而且不必自己處理接收端、儲存、退出機制與資料判讀。

能力上的差異比想像中小。這些服務與自建同樣受只看得到執行 JavaScript 的訪客這條限制，也同樣會被廣告與隱私擴充功能攔截——它們的網域出現在攔截清單上的機率甚至更高。真正的差別在三個地方：

資料的所在位置。 自建的資料在自己的試算表裡，想怎麼查就怎麼查、要保留多久就保留多久；託管服務的資料在對方的系統裡，導出格式與保留期限由對方決定。

要處理的工作量。 退出機制、欄位變更同步、判讀規則的維護在自建這側全部要自己做，這些工作在模組六佔的篇幅比 beacon 本身還多。託管服務把這些都包好了。

理解的深度。 自己做過一次之後，「這個數字是怎麼來的、它漏掉了什麼」變成可以回答的問題。用託管服務時那些答案在對方的文件裡，而多數人不會去讀。

判準因此是：想搞懂這套機制怎麼運作、或者資料必須在自己手上——自建。只想知道哪幾篇比較多人看——現成服務省下的工作比預期多，本指南反而是拿來理解它們在做什麼的參考。

下一步

工具選定 Apps Script 後，先搞懂它的部署模型跟授權模型，才不會在模組二實作時卡在「為什麼我的網址打不通」。往模組一：Apps Script 地基。