有一間每個月花了不少預算下 Google Ads。關鍵字清單幾個月沒動過。沒有轉換追蹤——只有費用持續出去，加上一個模糊的感覺說房間有在訂，所以應該有在發揮作用。
這不是設定問題。工具都在。決策流程不在。同一個缺口，九間全都有。
恆春這九間民宿不是輸給彼此，是輸給 OTA 後面那套從不停轉的「測量—分析—調整」機器。這套基礎設施，沒有任何個別小物件有能力自己複製。三個月要回答的問題是：AI 工具出現之後，這筆帳划不划得來。
OTA 的優勢不在品牌信任，在從不停轉的閉環
業主知道 OTA 佣金遠比旅客以為的高，還是繼續上架。因為替代方案沒有競爭力：一個靜態介紹頁掛在網路上，不在旅客的搜尋路徑裡，也不在比較邏輯裡。Booking.com 和 Agoda 的優勢不只是品牌，是全職優化轉換率的工程師、跑了幾年的行為數據、讓個別業主廣告預算相形見絀的投放規模。
直接訂房對特定族群可以搶回來——會自己找、找到了就信任的那批人。但前提是有閉環：能被搜尋到的落地頁、追蹤好的轉換事件、每週把廣告成效餵回決策的固定節奏。少了閉環，不是在跟 OTA 競爭，是在燒錢。
五個 codebase、三套自動化系統、九間民宿。三個月。
五個站，設計目標是部署後不需要我
九間整進五個 repository。同一個業主跑多個物件的，共用一個 repo。其中一個站跑靜態輸出，其他四個是 SSR server mode——不是為了即時資料，是因為業主後台需要跑 OAuth 和 GitHub commit pipeline，必須在 server side 處理。
Astro 5 + Tailwind v4。頁面本體大部分預先渲染，只有 /admin 路由在 request time 執行。Node.js adapter 跑 Express middleware 模式而非 standalone，這樣 gzip/brotli 壓縮和靜態資源的 immutable cache header 可以在 Astro handler 之前先處理掉。Core Web Vitals 不需要手動調校就達到健康分數。
內容更新走 GitHub REST API 搭的後台表單。業主自己改房型說明和定價，送出後直接 commit 進 repo，CI 自動重建，不需要打電話給我。設計原則就是把我自己從這個系統裡移除：部署後不需要我盯，內容控制權完全在業主手上。
GA4 裝了，分析流程從沒存在
九間都裝了 GA4。一間都沒有固定流程把數字變成決定。
從「打開 GA4」到「做一個具體決定」，中間要找對報表、記住上週的基準、把百分比變化翻成可以行動的事，還得在當天其他事情把這段流程擠掉之前完成。對每天核心工作是跑接待的人，這段路每週的摩擦力都太大。結果是根本不走，不是不願意走。
每週一早上，一個三階段 TypeScript pipeline 透過 GitHub Actions 自動執行：從 GA4 Data API 拉數據、透過 LLM 抽取洞察、輸出 Markdown 報告並寄給業主。分析這步除了原始數字，還會收到一份背景文件——那份文件不是自動生成的，是我和每位業主訪談後整理的：旺季規律、核心轉換事件、他們真正在乎的指標、附近節慶的影響模式。
LLM 輸出中文：「本週自然搜尋下滑 15%，與端午連假規律一致，付費流量持平，不是廣告問題。」標準配置用 Gemini 2.5 Pro；需要更深度判讀時可以切換到 Claude。週一早上進信箱。問題從「這數字什麼意思」，換成「我這週要做什麼」。
排程跑兩次——台北時間 08:37 一次、09:07 一次。因為 GitHub Actions 的 cron 偶爾會整個 tick 消失，既沒有 error、也沒有觸發任何 run。去重機制讓第二次在第一次已經 commit 的情況下成為 no-op，所以不會重複發報告。
每月數萬廣告費靠感覺跑
有些業主每月在 Google Ads 投入數萬元，沒有系統性辦法評估哪個關鍵字在發揮作用。決定靠直覺，或根本沒在做決定。
廣告健診 pipeline 從 Google Ads API 拉關鍵字和成效數據，跑四個階段：fetch、analyze、render、verify。verify 是防幻覺關卡——它確認報告裡每個被引用的數字都能追溯到原始資料 JSON 裡的真實值。沒過就讓 render 帶著失敗清單重跑，最多五次才放棄，不是無限重試。
關鍵字決策另外落進 Google Sheets——每個關鍵字一列，附狀態、加入日期、移除日期、當時的判斷理由。我可以用資料庫，schema 更乾淨，查詢更彈性。沒用，因為資料庫讓那些記錄只存在於我這邊。Sheets 讓業主自己翻歷史、看清楚每個決定是怎麼來的，完全不需要找我。業主把 Sheets 當成自己的帳本，不是我生給他們看的報告。這個心理差距對採用率的影響，比我預期的大很多。
新加入的關鍵字有 14 天保護期，不評估、不刪除。這個規則被執行兩次：一次在 LLM prompt 裡、一次在執行操作前的 code hard filter 裡。兩道關卡都要過。用 LLM 做唯一把關太脆弱——數據壓力大的時候，模型偶爾會忽略它被告知的規則。不到兩週的數據不夠做判斷。這個保護窗口不開放設定，因為可以設定就代表有人在等不及的時候會把它改掉。
有效的報告和準確的報告是兩件事
API 串接、自動化 pipeline 大概花了一週。讓報告真的產生後續討論，花的時間更長。
我在追的信號只有一個：這份報告有沒有讓業主打電話來問下一步怎麼做？被讀過然後存檔的準確報告，只是沒有改變任何事的昂貴基礎設施。
讓這個信號改變的，跟準確度無關。有效的格式要符合每個業主思考業務的方式，不是符合分析 dashboard 組織資訊的方式。有人需要看週比住房率，不是流量。有人對所有牽涉端午連假的數字都會有反應。背景文件存在，是因為同樣的輸出對某個業主能引發一通電話，對另一個只是被讀過存檔。校準還在繼續。
以前這個預算叫不起這套服務
三個月前，這套服務不存在這個定價。數據分析、廣告優化、週報、效能優化過的多物件基礎設施——每個環節原本都需要專門人手或企業級訂閱費。LLM 分析層承擔了原本需要分析師的工作。GitHub Actions 承擔了需要常駐排程基礎設施的部分。Astro 承擔了需要手工調校的效能優化。三者壓住了成本，讓服務定價落在這些業主算得過來的地方。
AI 沒有做的：判斷 Sheets 比資料庫更適合這個客戶脈絡、找出哪些摩擦是結構性的、發現準確的報告和有效的報告是兩個不同的產品。那些是判斷，不是分析。
自動化花了一週。校準還沒停。