一個同時跑 GA4 和 Google Ads 的雙語民宿站，數據出錯最危險的方式只有一種，而且你不會馬上發現：某個事件本來只該送到一邊，卻同時送進兩邊。GA4 的行為流裡多出一個不存在的轉換。Ads 帳號學了一個根本不是轉換的事件。沒有任何錯誤拋出，畫面也看不出問題。數字只是悄悄地變成假的。
這個 skill 存在的全部理由，就是為了防這一種錯。
這套東西屬於哪個系統
每個客戶民宿，同一個頁面上有兩件完全不同的事在跑。GA4 追行為——頁面瀏覽、捲動深度、哪些聯絡按鍵被點。Google Ads 追轉換——那些被允許拿去給廣告帳號優化的網站 CTA 點擊（打電話、點 LINE、立即訂房）。這是兩個系統在回答兩個問題，只是剛好共用同一個 gtag.js runtime。
下游的廣告引擎能不能用，完全取決於這兩條流乾不乾淨。如果 GA4 的行為事件漏帶了 Ads 的 send_to，廣告帳號就會開始往雜訊出價。如果一個 Ads 轉換不小心掉進 GA4，週報的意圖數字就會灌水。兩邊都在做決策——一邊是自動出價，一邊是給業主看的報告——而這兩個決策的品質，就看底下這層分得乾不乾淨。
最初驗證這套做法的實作，跑在一個雙語 Astro 站上，GA4 和 Ads 在那裡乾淨共存好幾個月。這個 skill 就是把那份實作一般化，讓下一個站不用重新踩一次同樣的坑。
最關鍵的設計選擇
一次 gtag.js 載入。接著每個去處各自呼叫一次 gtag('config', ...)——一個給 GA4 資源，一個給 Ads 帳號。然後是真正在幹活的那條規則：每個事件都要用 send_to 指明它要去哪裡。
這正是不夠小心的做法會搞錯的地方。預設的 gtag('event', ...) 沒帶 send_to 時，會廣播到所有已設定的去處。在一個同時設了 GA4 和 Ads tag 的頁面上，一個沒指定範圍的事件就會兩邊都送。捲動深度事件變成 Ads 訊號、或一個只該拿來算轉換的按鍵點擊也順手灌進 GA4 行為流——都是這樣來的。
這個 skill 用結構本身把它反過來。GA4 行為事件只帶 GA4 的 send_to，住在自己的 DOMContentLoaded handler 裡。Ads 轉換住在一個完全分開的點擊 handler 裡，用真實的分渠道轉換 label 去觸發 gtag('event', 'conversion', ...)，完全不碰 GA4 那條路。兩者從不共用同一段程式，所以也就不可能不小心共用同一個去處。
設定模組是唯一的真實來源：GA4 的 ID 永遠在，GOOGLE_ADS_CONFIG 那一塊只有在這個專案真的有跑廣告時才出現。
Google Ads 是選配——而那個分岔決定一切
整個 skill 最重要的決定在第二步就要做完，而且要一路貫穿到最後每一步：這個專案到底有沒有跑 Google Ads？
這些站很多只跑 GA4。對那些站來說，寫任何 Ads 的接線不只是沒用，而是個負債。skill 把這個選配分岔講得很明白，還加了一條硬規則：絕不要寫業主沒給你的 Google Ads 轉換 label。佔位字串一律禁止。
「不准用佔位字串」這條規則聽起來很龜毛，直到你看過一個假 label 會幹出什麼事。假 label 不會報錯。它只會默默地對著空氣觸發轉換，更糟的是對著一個屬於別的帳號的 label 觸發。等到有人發現，廣告帳號可能已經對著一個幽靈優化好幾週了。一開始就把佔位字串擋掉，比事後任何除錯都便宜。
同一套紀律也貫穿 onboarding 那一側。把客戶接進分析引擎的那個新站 skill 帶著同一條規則：最終檔案裡每一個 ID、label、email、URL 都必須是真的——值沒拿到就先去拿，拿到了再寫檔，順序不能反。
為什麼做成 skill，而不是一段程式碼
隨 prompt 附四個參考模板：設定模組、<head> 載入器、GA4 行為 handler、Ads 轉換 handler。它們是寫給 Astro 的，但 prompt 講得很清楚——機制（設定模組＋<head> 裡的一段 script＋一個 DOMContentLoaded handler）原封不動就能搬到 Next.js 的 <Script>、純 HTML，或任何能在 head 裡塞 script 的東西。換的只是宿主框架，邏輯不變。
要把這個打包成 skill 而不是複製貼上一段程式碼，原因在那些不是程式碼的部分：決策樹。這是 Ads 專案還是不是？哪些事件帶 GA4 的 send_to、哪些帶 Ads 轉換 label？頁面上那些散落的 gtag / dataLayer 殘留在哪——你不先 grep 出來，它們就會撞在一起？這些才是新做一份會搞錯的地方，而一段程式碼答不出這些問題。skill 編碼的是判斷，不只是接線。
這是哪個更大東西的一部分
這是一個更大的數位營運堆疊裡的一個節點，服務的是一批恆春民宿——能掌握自己訂房的站、一份自動週報、一個對著真實訊號優化的廣告引擎。追蹤這一層，是讓其他一切變得可量測的基礎。沒有行為和轉換數據之間的乾淨分離，下游每一個數字都可疑：週報分不清意圖和雜訊，廣告引擎分不清轉換和捲動。
對一間小民宿來說，請專家逐站正確設定這一套，從來不是划得來的帳——每站的成本會把預算吃光。把設定本身、把那些坑、把整棵決策樹編碼進一個 skill，才讓「正確的追蹤」變成可以鋪到每一間民宿、而不是只有當初撐起原始工程的那一間。
這層分離在運作正常時是看不見的，而這正是為什麼它必須靠結構強制、而不能靠「記得要小心」。