這個網站自己的量測

追蹤契約

三個事件，四個參數，一個監聽器

站上每一個外連 CTA 都由同一個委派監聽器處理，所以「加了新連結忘記加追蹤」這件事不可能發生。你現在就可以按 F12 開 Console 貼上 dataLayer 自己看。

事件	觸發時機	cta_channel
booking_click	點擊任何預約連結	cal.com
contact_click	點擊 Email／電話／LinkedIn	email · phone · linkedin
pdf_download	點擊作品集 PDF	portfolio_pdf

每筆事件都帶四個參數：

{
  event:       'booking_click',
  cta_channel: 'cal.com',
  cta_label:   '預約 30 分鐘診斷通話',
  cta_section: 'hero',        // topbar / hero / cta-band / footer
  cta_href:    'https://cal.com/calibmedia/diagnosis'
}

cta_section 是關鍵的一個——它讓「三顆預約鈕哪一顆真的在轉換」變成可回答的問題，而不是猜。

實際設定

從瀏覽器到資料倉儲

兩條路徑匯流到同一個 BigQuery 專案。GA4 那條是 Google 自己每天匯出的，另一條由排程去取——所以任何一條斷掉，另一條都還在，而且看得出來是哪一條斷的。

層	設定
GTM	4 個資料層變數、3 個自訂事件觸發條件、3 個 GA4 事件代碼。容器設定檔版控在 repo 裡，跟發出事件的程式碼放在一起—— 這份就是。
GA4	四個 `cta_` 都註冊成事件範圍自訂維度（沒註冊的話資料會進來但報表看不到，而且不回溯）。事件資料保留期設為 14 個月*，不是預設的 2 個月。
BigQuery	GA4 原生每日匯出（事件層級）。專案有綁帳單—— BigQuery Sandbox 會靜默刪除 60 天前的分割區，對長期累積是致命的。
每日 ETL	Search Console 與 cal.com 預約每天落地到 BigQuery。認證走服務帳戶而非個人 token（OAuth refresh token 在同意畫面為「測試中」時 7 天過期，排程會每週靜默死一次）。
完成度檢查	每次排程的日誌最後一行一定是 `exiting RC=0`。工作排程器的 `LastTaskResult` 只說明行程有沒有結束，不代表工作有做完——沒有那一行就是沒跑完。

這一整套的重點不是它很複雜，是每一層都有辦法知道它有沒有在運作。多數壞掉的量測不是設定錯，是沒有人知道它什麼時候開始壞的。

誠實的部分

這個網站自己也出過錯

以下都是真的，而且每一個都是實際去驗證才發現的，不是讀程式碼看出來的。它們也剛好是我在客戶帳戶裡最常遇到的幾類問題。

同一批瀏覽被記進兩個分析資源

怎麼發現的　同一頁在自訂網域比在測試網址多 359 bytes。追下去發現有兩支 beacon，token 不同。

原因　我手寫的那支，token 因為字串跳脫加錯位置變成 {{"token": ...}}——不是合法 JSON，從網站上線起就一筆資料都沒收到。真正在運作的是 Cloudflare 在 zone 層級自動注入的另一支。

修法　拿掉手寫那支。保留自動注入的，因為歷史資料在它身上，而分析資源之間的資料無法合併。

頁首的主要 CTA 按鈕，文字是看不見的

怎麼發現的　把導覽列放大三倍截圖檢查對比度。一般瀏覽只會覺得「有點糊」。

原因　CSS 特異性：.navlinks a (0,1,1) 蓋過 .btn (0,1,0)，按鈕文字被塗成內文灰，配深藍綠底。桌機、手機、淺色、深色全部都壞，從第一版就是。

修法　把導覽列的規則限縮成 :not(.btn)。

五個 CTA 裡有四個回報「不知道在哪個區塊」

怎麼發現的　用無頭瀏覽器實際點擊每一種 CTA，把 dataLayer 收到的內容印出來。

原因　區塊名稱取自 id 或 class，而 <footer> 兩者都沒有，於是 Email、電話、LinkedIn、PDF 全部回報 unknown——而那正是大部分的聯絡管道。

修法　取不到 id 與 class 時退回標籤名稱。

預約頁寫 15 分鐘，網站三個地方都寫 30 分鐘

怎麼發現的　用 API 讀 cal.com 的實際設定，而不是相信介面上的印象。

原因　event 是從預設範本改的，時長沒改到，名稱還叫「Test」。客戶照網站的承諾預約，會拿到一半的時間。

修法　改成 30 分鐘，並加上 24 小時提前預約與事後緩衝。

sitemap 每次部署都謊報所有頁面「今天更新過」

怎麼發現的　部署後比對線上 sitemap 與本機產出，發現日期全部一樣。

原因　第一版用建置當下的時間。改成讀 git 日期之後本機正確、線上還是錯——建置容器是淺層 clone，所有檔案都算成同一個 commit 新增的。

修法　偵測到淺層 clone 就不輸出這個欄位。查不到就不要猜，沒有 lastmod 的 sitemap 完全合法。

這五個沒有一個是「設定錯了」，全部都是看起來正常、實際上壞掉。這就是為什麼健檢的第一步永遠是對帳，不是看儀表板。

這個網站自己的量測，全部攤開給你看