免費膠水層能不能撐住你的量，要看的限制不是「一天總共幾次」，而是「同一瞬間能有幾個請求在跑」。這兩者常被搞混，導致人用錯誤的方式估算容量。個人 blog 的流量幾乎不可能打爆總量限制，卻可能在某篇文章被分享的那一刻，短時間湧入的併發請求撞上併發上限。先建立正確的思考單位，才知道免費夠不夠、什麼時候要換工具。

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

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 地基。