兩家恆春民宿各自跑一個 Google Ads 帳號，都設了 Smart Bidding。好幾個月，我餵給 Smart Bidding 的「轉換」是網站上的聯絡按鍵——電話點擊、LINE 按鈕、WhatsApp 連結、Facebook 訊息連結。系統學到的是怎麼找會點按鈕的人。會不會訂房，它看不到。
這個缺口是真實且可量化的。一個訪客在頁面上逛了七分鐘，點了 LINE 按鈕，算一筆轉換，但沒有訂房。一個週二看了頁面、週五直接打電話、訂了九月包棟的客人，沒有留下任何點擊紀錄——不算事件、不計 session，對 Smart Bidding 完全隱形。最高意向的客人，系統裡最看不到。
要填這個缺口，得先有一個可以查詢的訂房資料來源。最難的不是資料架構，是建一個業者媽媽每天都會打開的記錄工具。
給七十歲老人用的介面，反而最難做對
恆春的民宿業者靠電話跟通訊軟體接訂房，不會登入第二個工具。這個現實決定了每一個架構決策。需要摩擦的工具不會被用。這份訂房工具得跟點 app icon 一樣順手，因為它就得在 iPhone 主畫面上。
評估了三個方向：
原生 iOS app：Apple Developer 年費 NT$3,000，每次更新要過 App Store 審核。維護成本跟兩家民宿的規模完全不對稱。
LINE Bot：業者活在 LINE 裡，啟動摩擦低。但用聊天介面做結構化資料輸入——選房源、選聯絡管道、選訂房類型、填日期——遠不如專用按鈕來得清楚。
PWA：Next.js 部署到 Vercel，從 Safari 加入 iPhone 主畫面，外觀跟 native app 一樣。推 GitHub 自動部署，沒有上架程序，也沒有審核週期。
選 PWA。記錄畫面只問五件事：哪一間民宿（大按鈕）、客人怎麼聯絡（LINE / 電話 / WhatsApp / FB 訊息 / 其他）、包棟還是散客單間、入住跟退房日期，最後是選填備註。每個問題都是一次點擊，只有備註需要打字。標準訂房三十秒內完成。
多帳號共用——Wayne 跟白天負責詢問的家人各自用自己的 Google 帳號登入——靠 Supabase Auth 加上 Google OAuth 解決。資料庫裡建了一張 operator_members 表，多個 Google 帳號對應同一個業者。RLS policy 透過一個 SECURITY DEFINER SQL 函數把 auth.uid() 映射到正確的業者 ID。兩個帳號看到的是同一份訂房資料，不需要共用密碼，也不需要自建帳號系統。
按下「確認訂房」，server 同時做三件事
送出之後不只是寫進資料庫。server 同時觸發三件事：
寫進 Supabase：房源名稱、聯絡管道、訂房類型、入住退房日期、備註，進 bookings 表。
建 Google 日曆事件：在業者共用的「訂房日誌」日曆裡新增一筆，顯示房源名稱、包棟或散客、聯絡管道、晚數。所有有寫入權限的成員立刻看到。業者第一次登入時，日曆自動建立並分享給所有成員，不需要任何手動設定。
送 GA4 Measurement Protocol 事件：server 端立刻打一支 GA4 事件，用這間民宿專屬的事件名稱，把訊號分流到正確的 Google Ads 帳號。
Google 日曆這塊是業者端的閉環。業者本來就會看自己的 Google 日曆，訂房現在自動出現在那裡，不需要另外開任何工具確認。
為什麼不直接走 Google Ads Conversion API
最直觀的做法是訂房確認當下直接送一筆轉換到 Google Ads Conversion API。這個 API 強制要求 gclid——廣告被點擊那一刻附上的識別碼。業者記的是事後資料，客人早就離開網站了，不存在任何 gclid。送空的 gclid 直接回 400。路死在這裡。
GA4 Measurement Protocol 沒有這個限制。每筆確認訂房送一支 server 端 GA4 事件，24-48 小時內自動同步到連結的 Google Ads 帳號。
兩家 Google Ads 帳號各自連結同一個 GA4 property。資料庫裡每間民宿有自己的事件名稱。每家 Google Ads 帳號只匯入自己的事件名稱，收到的是完全獨立的訊號，兩家帳號的資料不互相污染。只需要一組 GA4 憑證，卻是兩條分開的轉換 pipeline。
轉換價值動態計算：晚數乘以各訂房類型的均價。包棟每晚均價約為散客單間的數倍，兩晚包棟跟一晚散客送給 Smart Bidding 的訊號在量級上完全不同。Smart Bidding 現在收到的不只是「訂房發生了」，是「這筆訂房值多少」。
兩條時間線，不能壓成一個數字
一個「訂房總數」依然是錯的，只是換了一種更貴的錯法。
民宿老闆腦袋裡同時跑兩條時間線：這週「進來」幾筆訂房，跟這週實際「有人住」幾間。今天進來的訂房可能是九月的行程。今晚入住的客人可能是四月就訂好的。把兩個壓成一個數字，老闆得先在腦子裡拆開，才能決定下一步要怎麼動。那樣自動化的是錯的那一半。
received 按訂房建立時間過濾：這週進系統的訂房，行銷跟廣告投入的直接成果，是領先指標。staying 按入住日期過濾：這週實際在住的客人，是住房現實，跟廣告什麼時候投沒有直接關係。
三個月的住房率快照——上個月已結算、這個月進行中、下個月已確認——讓報告同時呈現上個月怎麼收尾、這個月現在到哪、下個月已經鎖了多少。老闆要調廣告預算或規劃促銷，這三個數字缺一不可，而且沒有一個能從另外兩個推算出來。
週報怎麼整合這份資料
週報 pipeline 在跑完 GA4 跟 Search Console 查詢之後，透過 Supabase REST API 拉訂房資料。整合是 opt-in：每個 site 的設定檔裡有一個 booking_tracker 區塊，放 enabled flag、憑證環境變數名稱、要過濾的民宿名稱清單。flag 關掉的 site 跑起來跟原本一樣，下游 stage 收到 null 欄位就跳過，不會壞掉。
開啟之後，fetch 階段跑七支平行的 Supabase query：本週和上週的 received 訂房，本週和上週的 staying 訂房，加上上個月、這個月、下個月的住房率快照。每次報告都是完整的三段時間視角，不是只有當週。
訊號替換之後
網站上的 CTA 事件——電話點擊、LINE 點擊、WhatsApp 點擊、Facebook 訊息點擊——沒有從報表裡消失。它們繼續作為行為訊號：多少訪客伸手去點了聯絡、哪些頁面產生最多詢問意圖。只是它們不再是 Smart Bidding 的優化目標。那個位置讓給了真實的訂房記錄，帶著跟實際入住收入成比例的轉換金額。
對恆春的小民宿來說，這個等級的系統——真實訂房訊號進 Smart Bidding、每週跨三個月的住房率報告、確認訂房自動出現在 Google 日曆——過去不是因為不知道怎麼做才缺席。是建置跟維護的成本，讓這個服務對這個規模的客戶根本不存在。前提條件改變了，業者需要準確訊號這件事從來沒變過。