Google 的 uploadClickConversions API，只要少了 gclid、wbraid、gbraid 三者之一就直接拒收。但 booking-tracker 記的是「事後補登的訂房」——客人早就離開網站了，是打電話或用 LINE 訂的，根本沒有點擊 ID 可以附上去。所以那條最直覺的路，把真實訂房餵回 Google Ads，從一開始就走不通。
這篇和〈Real Bookings Replace Click Proxies in the Ads Conversion Pipeline〉講的是同一套系統，但切入點不同。那篇談的是為什麼用真實訂房取代網站聯絡按鍵點擊，當作廣告優化的目標。這篇談的是底下更窄、更難的一個問題：當同一位業主經營兩館、兩館各自一個 Google Ads 帳號，一張共用的訂房表單要怎麼把每筆訂房送到對的帳號——而且手上完全沒有點擊 ID 可以歸因。
這是分流問題，不是追蹤問題
這套系統的全貌，是一個把訂房記在腦袋裡、寫在紙上的民宿業主的直接訂房管道。廣告引擎要拿真實成交的訂房、而不是按鍵點擊代理指標，來優化廣告花費。要讓這件事成立，登在 tracker 裡的一筆訂房，就得變成 Google Ads 裡的一個轉換訊號——而且價值算對、歸到對的廣告活動。
麻煩在這裡：這位業主經營兩館，兩館各自用一個 Google Ads 帳號打廣告。A 館的訂房要進 A 帳號，B 館的訂房要進 B 帳號。表單是共用的。所以表單的 POST handler 得知道，每一筆訂房該去哪個帳號。
當時桌上有三個選項，決策紀錄把三條路都走過一遍。
為什麼不直送 Conversion API（路 B）
直覺是乾脆跳過 GA4，從訂房 POST 直接 server-side 呼叫 Google Ads Conversion API。歸因更乾淨，少一層分析中介。
但這條路在這個情境走不通。uploadClickConversions 要求 gclid / wbraid / gbraid，而這些訂房一個都沒有——客人幾天前就離開網站，是在站外聯絡業主訂的。硬送一個空點擊 ID 的轉換請求，API 直接回 400 Invalid。那個 endpoint 根本沒有「無歸因轉換」這種模式。對這套訂房模型來說，路 B 一開始就出局。
為什麼不開兩個 GA4 property（路 A）
「兩個廣告帳號」的教科書答案是開兩個 GA4 property——一個帳號配一個，各自一條 data stream，各自連到自己的 Ads 帳號。乾淨切開，程式裡不用寫分流邏輯。
代價不在技術，在維運。這意味著要新建兩個 GA4 property、重設 data stream、重新連結那些本來就有正常歸因的 Ads 帳號。可能弄壞現有那條已經在餵 Smart Bidding 的網站聯絡按鍵點擊追蹤——這個風險是真的，而換來的「切開」我可以用別的方法拿到。
為什麼是事件名稱分流（路 C）
Google Ads 允許你把「某一個特定的 GA4 事件」匯入成轉換，而且範圍綁定在某一個特定的 Ads 帳號。這就是那根槓桿。一個共用的 GA4 property、一個 Measurement Protocol endpoint——但 tracker 裡每一館各自帶自己的 ads_event_name。A 館的訂房送 booking_confirmed_a、B 館送 booking_confirmed_b。A 帳號只匯入第一個事件當轉換、B 帳號只匯入第二個。分流發生在 Google Ads 的匯入設定裡，不是在我程式裡那種容易出錯的多帳號憑證周旋。
實作很小，正是因為設計對了。POST handler 讀出那一館的 ads_event_name，連同這筆訂房的價值，透過 Measurement Protocol 送出去。憑證也從資料庫裡每個 operator 各自存 GA4 secret，改成環境層級單一的 Measurement ID 和 API secret——現在就一個 GA4 property，每個 operator 再各存一份 GA4 設定就沒道理了。
轉換的價值：算晚數，不算筆數
一個轉換訊號的好壞，看你附上去的價值準不準。光是一句「有一筆訂房」，沒辦法告訴 Smart Bidding 這是一晚的單間、還是七晚的包棟。所以價值是用 晚數 × 每晚價值 算出來的，包棟和散客單間的每晚數字各不一樣。一筆長天數的包棟，現在在競價模型裡的份量就壓過一筆短天數的單間——這正是業主實際面對的營收現實。
這件事的份量比看起來重。沒有動態價值，Smart Bidding 會朝訂房「筆數」優化，於是一個衝出一堆便宜單晚單間的廣告活動，數字看起來會比一個帶來幾筆高價長住的還漂亮。把轉換價值跟晚數綁在一起，競價目標才對得上真實營收。
老實說的但書
這一切都建立在訂房真的會被登記的前提上。代理指標——網站聯絡按鍵點擊——當初存在是有真實理由的：業主把訂房記在紙上，沒有低摩擦的數位路徑。booking tracker 整件事的重點，就是要當那條低摩擦的路徑。但它成不成，要看每天登記的紀律撐不撐得住。分流是對的；資料流不流得進來，要看一個還沒被驗證過的人類習慣。
這種工作，以前不會發生在一家兩館的民宿身上——不是沒人想做，是把工程、數據分析、廣告維運串起來的成本，超過一個小業者願意花的。它能存在，本身才是值得注意的那一點。
Google 給你的是一套歸因模型；但你手上真正的訂房模型，決定了你能用哪一套。