[CODE]

一套數位運作層、一個工程師、一條反幻覺回饋迴路:墾丁民宿的廣告與報告自動化

平台佣金遠比外界想像的高,而且帶走的不只是錢。這篇記錄我如何用 Astro 網站、GA4 分析、TypeScript 週報引擎和 LLM 驅動的廣告健檢,為恆春半島九家小型民宿搭起一套之前在任何價格帶都不存在的數位運作系統。

1 min read AI 生成
bnb google-ads ga4 automation llm astro small-business

OTA 對小型民宿的壓制,來自三個複利疊加的結構優勢:早於大多數小型物件將近十年開始燒廣告、在那段時間裡堆疊的海量評價、以及每天在後台做優化的全職人員。這種領先不是品質問題,是時間換來的複利;一個旅遊季追不上。佣金遠比外界想像的高,是顯性成本。隱性成本更重:每一筆 OTA 訂房都在替平台的資料飛輪加速,不是替你的品牌建立回流客基礎。

恆春半島這九家民宿的處境幾乎相同:網站沒有搜尋能見度、廣告帳戶沒有轉換訊號、GA4 業主偶爾看但看了不知道下一步。這三件事哪一件單獨解決都不夠:網站開始排名才能產生廣告系統需要學習的行為資料;有資料但沒有讀取迴路,出價永遠不調整;週報讀不懂,沒有決策。工作單位是整套系統,不是單一元件。

不會出現在交付清單上的承重牆

網站用 Astro 做,中英雙語,有房型、季節定價、墾丁國家公園周邊活動指南,聯絡路徑走 LINE、電話、WeChat。後台讓業主可以自己換首頁 banner、上傳活動圖,不用找工程師。這部分大概一週。

真正決定下游系統能不能跑起來的,是效能工。把 Lighthouse 行動版分數拉到 Google 不壓排名的範圍。修掉版面位移,很多是業主直接把活動橫幅當房型縮圖上傳造成的。改寫圖片傳送,讓主視覺圖不讓手機訪客多耗 65 MB。這些工作不出現在交付物裡,但 Lighthouse 行動版 48 分的網站沒有轉換率問題——流量不夠多,還輪不到談轉換。

每個站都接 GA4,疊了 Search Console 和 Google Ads 轉換追蹤。決定下游是否全部有效的關鍵只有一個地方:點擊代理事件——電話 CTA 按鈕、WeChat 啟動連結、立即預訂——必須在訪客離開網站之前觸發。晚一步,GA4 就收不到這筆訊號。沒有訊號,廣告系統等於在真空裡燒預算。這是我審過的帳戶裡最常見的設定缺口。修法是兩行 JavaScript,但要知道放在哪裡才有用。

四段 Pipeline,加一條反幻覺閘門

週報引擎用 TypeScript 寫,跑在 GitHub Actions,每週一 cron 自動執行,目前涵蓋三個站。Pipeline 分四段:fetch 把 GA4 和 Search Console 的當週與前週資料拉成結構化 JSON;analyze 把這份 JSON 餵給 LLM 提取結構化洞察;render 寫出 Markdown 報告;verify 把報告裡每一個數字追溯回原始資料。

verify 這段是最關鍵的設計決策。語言模型負責寫文字——段落標題、診斷框架、建議行動——但不能寫數字。報告裡所有數字都在 fetch 階段從 GA4 API 回應做確定性計算,不經過 LLM。verify 讀取渲染好的 Markdown,抽出每一個數字,在允許小誤差的範圍內對照原始 JSON 追溯來源。找不到來源的數字,整個階段失敗。模型同時有一份禁止詞表——聽起來像在分析但沒有運營含義的顧問術語——出現一個就拒絕。

verify 失敗時,它把失敗清單寫成結構化快照。下一次嘗試,render 讀到這份快照就進入修正模式:LLM 同時看到自己的前一份草稿和具體的失敗描述,只重寫失敗的段落。Pipeline 最多重試五次才中止。實際上,一次初稿失敗加一次修正幾乎都能收斂;五次上限是應對邊緣情況的安全墊。

這個架構讓業主收到的報告可以直接轉發,不需要人工審查。拿掉「模型不能寫數字」這條限制,你會得到語氣自信但數字錯誤的報告——那比沒有報告更糟,因為業主會根據錯誤的數字做決策。

站點情境組裝與雙層模型架構

每次分析開始之前,引擎先為每個站組裝情境:旺季區間、目標客群、這家民宿的實際轉換定義、以及解讀規則——決定同一份 GA4 訊號在這個站應該怎麼讀。墾丁海邊的家庭包棟民宿和後壁湖的潛水客民宿,面對同樣的會話資料有不同的解讀邏輯,Prompt 在 Stage B 開始前就必須知道自己在看哪一家。

週報跑 Gemini 2.5 Pro。廣告健檢是一條獨立的 on-demand pipeline,審查廣告結構、關鍵字品質、浪費支出、Final URL 覆蓋率——同樣的四段架構,但在手動觸發時可以選模型層級:標準層用 Gemini 2.5 Pro,Premium 層升級到 Claude Sonnet,適合帳戶結構複雜或資料異常持續時需要更深層推理的情況。廣告健檢不是固定週期——它在有具體帳戶問題需要回答的時候跑,不是照日曆跑。

廣告健檢涵蓋的四個站台,加起來是九家民宿。幾家物件共用同一個 Google Ads 管理帳號,所以每次健檢會在同一次執行裡跨多個子帳號審查。

這套服務以前不存在,不是因為沒人想做

建網站、設分析、管廣告、每週一份報告。傳統服務模式下,這是四個獨立人力成本項目。合計起來,遠超過恆春小型民宿能付的費用。所以他們繼續走 OTA,繼續讓佣金從每筆訂房帶走利潤,從來沒有機會累積可以改變這個算式的直客資料。這不是市場失靈,是毛利結構決定的。

AI 在這裡做的事:把三個文字產出密集的工作——情境感知的摘要寫作、廣告問題的白話診斷、把分析資料翻譯成業主能執行的語言——壓縮進一套每個物件每週只需要個位數美元的系統。這九家民宿拿到的,不是「以前就有、只是更便宜」的同一套服務。是一個在這個價格帶,以前根本不存在的服務類別。

這條門檻,降了。