No-Server on Tarragonhttps://tarrragon.github.io/blog/tags/no-server/Recent content in No-Server on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Mon, 06 Jul 2026 00:00:00 +0800免伺服器自動化實務指南：用免費雲端服務給靜態站補上動態能力https://tarrragon.github.io/blog/automation/Mon, 06 Jul 2026 00:00:00 +0800https://tarrragon.github.io/blog/automation/<p>本指南處理一類具體的工程問題：手上有一個沒有後端的靜態站或小專案，需要一點點動態能力（收一筆表單、記一次瀏覽、每天彙總一次資料），但這個需求還不到、也不值得租一台伺服器的程度。核心概念是「膠水層」——用別人已經在跑、且對個人用量免費的雲端服務，補上靜態站缺的那一小塊伺服器端邏輯，讓你不必自己維護一台開機的主機。</p> <p>靜態站的能力邊界很明確：瀏覽器把 HTML/JS 抓下來後，所有邏輯都在使用者的瀏覽器裡跑，沒有任何一段程式碼在你控制的伺服器上執行。這代表任何「要記在你這邊」的資料——誰來看過、表單填了什麼、累積計數——都需要一個瀏覽器以外、由你掌握的接收端。這個接收端不必是傳統伺服器；它可以是一段掛在免費平台上、只在被呼叫時才執行的函式。本指南教怎麼用這種函式把靜態站的能力補齊。</p> <p>貫穿全指南的案例是「幫這個架在 GitHub Pages 上的 blog 做流量統計」。GitHub Pages 不給 access log、也不能跑伺服器端程式碼，所以流量資料只能靠瀏覽器主動回報。這個案例會從模組零的架構推導、一路實作到模組六的資料判讀，讀者跟著做完會得到一個真的能用、資料存在自己試算表裡的流量統計系統——「自己手上」在這裡指的是資料的控制權與查詢自由，基礎設施仍然是 Google 託管的。</p> <p>第一種膠水工具選 Google Apps Script + Google Sheets：它對個人 Google 帳號免費、不需要信用卡、Sheets 直接當資料庫兼儀表板，起步門檻是所有選項裡最低的。指南後續會加入其他膠水工具（例如 Cloudflare Workers）作為對照，說明各自的適用邊界——Apps Script 適合資料量小、需要人可直接讀寫試算表的場景；當量體變大或需要低延遲時，模組五會給出換工具的判準與遷移路徑。</p> <h2 id="教材邊界">教材邊界</h2> <table> <thead> <tr> <th>類型</th> <th>放在本指南</th> <th>不放在本指南</th> </tr> </thead> <tbody> <tr> <td>心智模型</td> <td>靜態站能力邊界、膠水層架構、client beacon、免費額度的思考方式</td> <td>大型後端架構、微服務拆分</td> </tr> <tr> <td>工具地基</td> <td>Apps Script web app 部署模型（<code>doGet</code>/<code>doPost</code>）、授權模型、V8 runtime</td> <td>Apps Script 在 Workspace 企業版的進階整合</td> </tr> <tr> <td>實作</td> <td>beacon 前端、接收端 handler、Sheets 讀寫、觸發器排程、配額與安全</td> <td>商業級 analytics 平台的自建（見 <a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring</a>）</td> </tr> <tr> <td>資料品質</td> <td>訪客識別、事件模型、自動化流量辨識、靜默失效診斷</td> <td>跨裝置身分解析、廣告歸因、第三方資料串接</td> </tr> <tr> <td>選型</td> <td>自建 vs 現成分析服務、Apps Script vs Workers 的適用邊界、何時該換工具</td> <td>雲端主機比價、Kubernetes</td> </tr> </tbody> </table> <p>流量分析的<strong>概念層</strong>（事件分類、漏斗、cohort、歸因）不在本指南，在 <a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>。本指南是<strong>動手做</strong>的那一半：怎麼用免費工具把資料真的收進來、存起來、彙總出報表。兩者互補——先看 Monitoring 想清楚要收什麼，再回本指南把管線搭起來。</p> <h2 id="backlog">Backlog</h2> <table> <thead> <tr> <th>項目</th> <th>類型</th> <th>前置條件</th> <th>規模</th> </tr> </thead> <tbody> <tr> <td>雙事件配對的彙總實作（平均停留、閱讀深度）</td> <td>主章</td> <td>模組四彙總改寫成事件感知版本</td> <td>1 篇</td> </tr> <tr> <td>Cloudflare Workers 對照與遷移路徑</td> <td>主章</td> <td>實機驗證免費額度與部署流程</td> <td>2 篇</td> </tr> <tr> <td>Referrer-Policy 知識卡</td> <td>知識卡</td> <td>無（模組六已完整展開、判定它是否仍需獨立卡）</td> <td>1 張</td> </tr> <tr> <td>現成分析服務的實測對照</td> <td>vendor</td> <td>實測 Plausible / Umami / GoatCounter 的免費額度與能力</td> <td>1 篇</td> </tr> <tr> <td>Monitoring 對本指南的反向連結</td> <td>跨模組</td> <td>盤點 monitoring 各模組的實作落點</td> <td>小</td> </tr> </tbody> </table> <p>跨模組那一列是目前唯一的結構性不對稱：本指南對 monitoring 有五條引用，反向零條，而 monitoring 的漏斗與 cohort 分析都預設資料乾淨、可識別、無機器混入——那些前提正是模組六在處理的。</p> <p>模組六補上了資料判讀，但彙總層仍停在模組四的單事件版本——那裡目前只標明了前提與修法方向，尚未有一篇把「配對進入與離開事件、算出平均停留與閱讀深度」實作出來。順序上它依賴模組六的事件模型定案，因此排在其後。</p> <h2 id="章節">章節</h2> <table> <thead> <tr> <th>章節</th> <th>責任</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/automation/00-mental-model/" data-link-title="模組零：心智模型" data-link-desc="判斷一個動態需求要不要伺服器、資料從哪個接收端進來、免費額度撐得住多大量時的思考框架">模組零：心智模型</a></td> <td>靜態站能力邊界、膠水層、client beacon 架構、免費額度、自建 vs 現成服務、GAS vs Workers 選型</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/01-apps-script-basics/" data-link-title="模組一：Apps Script 地基" data-link-desc="搞懂 Apps Script 的 web app 部署模型與授權模型，才不會在做 beacon 時卡在網址打不通或權限被擋">模組一：Apps Script 地基</a></td> <td>Apps Script 是什麼、V8 runtime、web app 部署模型、授權模型、跟一般伺服器的差異</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/02-analytics-beacon/" data-link-title="模組二：流量 beacon 實作" data-link-desc="把「頁面被看了就送一則事件、接收端寫進 Sheet」從零做到收到第一筆真實瀏覽紀錄時的完整實作">模組二：流量 beacon 實作</a></td> <td>前端 beacon、接收端 handler、寫進 Sheet、CORS 的雷與解法，從零到第一筆</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/03-sheet-as-database/" data-link-title="模組三：Sheets 當資料庫" data-link-desc="用 Google Sheet 存流量資料時，怎麼處理多個 beacon 同時寫入的並發、設計資料模型、以及判斷資料量到哪會撐不住">模組三：Sheets 當資料庫</a></td> <td><code>appendRow</code>、資料模型、並發與 <code>LockService</code>、Sheets 的容量邊界</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/04-triggers-automation/" data-link-title="模組四：觸發器與排程" data-link-desc="用 Apps Script 的時間觸發器把累積的原始瀏覽 log 定時彙總成看得懂的日報，以及觸發器的每日執行配額">模組四：觸發器與排程</a></td> <td>time-driven trigger 每日彙總、<code>onFormSubmit</code>、把原始 log 變成日報</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/05-deploy-quota-security/" data-link-title="模組五：部署、配額與安全" data-link-desc="把匿名可存取的 beacon 接收端上線後，怎麼守住免費配額、擋掉濫用、保持資料乾淨、以及判斷何時該換更重的工具">模組五：部署、配額與安全</a></td> <td>部署權限、免費配額上限、CORS 設定、防濫用、隱私邊界與同意機制</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/automation/06-reading-the-data/" data-link-title="模組六：收到資料之後" data-link-desc="流量統計上線、資料開始累積，但欄位讀不出「這是誰、是不是同一個人、是不是機器」時的判讀與補強">模組六：收到資料之後</a></td> <td>訪客識別與 opt-out、事件模型與停留時間、辨識自動化流量、假故障與靜默失效診斷</td> </tr> </tbody> </table> <p>模組零到五走的是「怎麼把管線接起來」，那條路徑上的每個障礙都能從文件讀出來。模組六的位置不同——它處理管線接好、資料真的開始累積之後才浮現的問題：來源網址大量空白、任兩列之間看不出是不是同一個人、真人與機器抓取混在一起。這些無法在設計階段推導，只有真實流量打進來才會現形。</p>本指南處理一類具體的工程問題：手上有一個沒有後端的靜態站或小專案，需要一點點動態能力（收一筆表單、記一次瀏覽、每天彙總一次資料），但這個需求還不到、也不值得租一台伺服器的程度。核心概念是「膠水層」——用別人已經在跑、且對個人用量免費的雲端服務，補上靜態站缺的那一小塊伺服器端邏輯，讓你不必自己維護一台開機的主機。

靜態站的能力邊界很明確：瀏覽器把 HTML/JS 抓下來後，所有邏輯都在使用者的瀏覽器裡跑，沒有任何一段程式碼在你控制的伺服器上執行。這代表任何「要記在你這邊」的資料——誰來看過、表單填了什麼、累積計數——都需要一個瀏覽器以外、由你掌握的接收端。這個接收端不必是傳統伺服器；它可以是一段掛在免費平台上、只在被呼叫時才執行的函式。本指南教怎麼用這種函式把靜態站的能力補齊。

貫穿全指南的案例是「幫這個架在 GitHub Pages 上的 blog 做流量統計」。GitHub Pages 不給 access log、也不能跑伺服器端程式碼，所以流量資料只能靠瀏覽器主動回報。這個案例會從模組零的架構推導、一路實作到模組六的資料判讀，讀者跟著做完會得到一個真的能用、資料存在自己試算表裡的流量統計系統——「自己手上」在這裡指的是資料的控制權與查詢自由，基礎設施仍然是 Google 託管的。

第一種膠水工具選 Google Apps Script + Google Sheets：它對個人 Google 帳號免費、不需要信用卡、Sheets 直接當資料庫兼儀表板，起步門檻是所有選項裡最低的。指南後續會加入其他膠水工具（例如 Cloudflare Workers）作為對照，說明各自的適用邊界——Apps Script 適合資料量小、需要人可直接讀寫試算表的場景；當量體變大或需要低延遲時，模組五會給出換工具的判準與遷移路徑。

教材邊界

類型 放在本指南 不放在本指南
心智模型 靜態站能力邊界、膠水層架構、client beacon、免費額度的思考方式 大型後端架構、微服務拆分
工具地基 Apps Script web app 部署模型（doGet/doPost）、授權模型、V8 runtime Apps Script 在 Workspace 企業版的進階整合
實作 beacon 前端、接收端 handler、Sheets 讀寫、觸發器排程、配額與安全 商業級 analytics 平台的自建（見 Monitoring）
資料品質 訪客識別、事件模型、自動化流量辨識、靜默失效診斷 跨裝置身分解析、廣告歸因、第三方資料串接
選型 自建 vs 現成分析服務、Apps Script vs Workers 的適用邊界、何時該換工具 雲端主機比價、Kubernetes

流量分析的概念層（事件分類、漏斗、cohort、歸因）不在本指南，在 Monitoring 監控體系。本指南是動手做的那一半：怎麼用免費工具把資料真的收進來、存起來、彙總出報表。兩者互補——先看 Monitoring 想清楚要收什麼，再回本指南把管線搭起來。

Backlog

項目 類型 前置條件 規模
雙事件配對的彙總實作（平均停留、閱讀深度） 主章 模組四彙總改寫成事件感知版本 1 篇
Cloudflare Workers 對照與遷移路徑 主章 實機驗證免費額度與部署流程 2 篇
Referrer-Policy 知識卡 知識卡 無（模組六已完整展開、判定它是否仍需獨立卡） 1 張
現成分析服務的實測對照 vendor 實測 Plausible / Umami / GoatCounter 的免費額度與能力 1 篇
Monitoring 對本指南的反向連結 跨模組 盤點 monitoring 各模組的實作落點 小

跨模組那一列是目前唯一的結構性不對稱：本指南對 monitoring 有五條引用，反向零條，而 monitoring 的漏斗與 cohort 分析都預設資料乾淨、可識別、無機器混入——那些前提正是模組六在處理的。

模組六補上了資料判讀，但彙總層仍停在模組四的單事件版本——那裡目前只標明了前提與修法方向，尚未有一篇把「配對進入與離開事件、算出平均停留與閱讀深度」實作出來。順序上它依賴模組六的事件模型定案，因此排在其後。

章節

章節 責任
模組零：心智模型 靜態站能力邊界、膠水層、client beacon 架構、免費額度、自建 vs 現成服務、GAS vs Workers 選型
模組一：Apps Script 地基 Apps Script 是什麼、V8 runtime、web app 部署模型、授權模型、跟一般伺服器的差異
模組二：流量 beacon 實作 前端 beacon、接收端 handler、寫進 Sheet、CORS 的雷與解法，從零到第一筆
模組三：Sheets 當資料庫 appendRow、資料模型、並發與 LockService、Sheets 的容量邊界
模組四：觸發器與排程 time-driven trigger 每日彙總、onFormSubmit、把原始 log 變成日報
模組五：部署、配額與安全 部署權限、免費配額上限、CORS 設定、防濫用、隱私邊界與同意機制
模組六：收到資料之後 訪客識別與 opt-out、事件模型與停留時間、辨識自動化流量、假故障與靜默失效診斷

模組零到五走的是「怎麼把管線接起來」，那條路徑上的每個障礙都能從文件讀出來。模組六的位置不同——它處理管線接好、資料真的開始累積之後才浮現的問題：來源網址大量空白、任兩列之間看不出是不是同一個人、真人與機器抓取混在一起。這些無法在設計階段推導，只有真實流量打進來才會現形。

讀者旅程

想直接把流量統計做出來：模組零建立架構直覺後，跳模組二照著實作，缺概念再回模組一補。想完整理解這套膠水模式、之後套用到其他專案：模組零到六順讀。已經收到資料、正要開始看報表：直接進模組六。只想查某個 Apps Script 術語：看 knowledge-cards。

]]>