先分清四個數字
入口點擊係訪客按過聯絡；網站確認係系統回應已處理；實際接收係接收方有需求記錄；合資格查詢／成交係業務按已約定準則核實結果。呢四層可以互相驗證，唔應混成一個「轉化」總數。WhatsApp 開啟或電話連結點擊尤其唔證明已有對話。
按症狀找證據，唔好一次過改晒設定
| 觀察到甚麼 | 先核對甚麼 | 下一個測試 |
|---|---|---|
| 平台顯示多次成功，接收只得一次 | 同一行動是否由主題、外掛、GTM 或其他整合多處送出；計數定義是否相同。 | 保留現況後，用一次測試逐層記錄事件來源同次數。 |
| 按提交但接收冇記錄 | 前端驗證、網絡回應、表單接收及通知流程。 | 測正常、漏填同接收失敗；錯誤時唔應記成功需求。 |
| 網站收到需求，但分析見唔到 | 量度目的地、事件條件、同意狀態、裝置限制及測試期間。 | 確認讀緊正確資源，用支援嘅偵錯方式追一條路徑。 |
| 改版後數字突然變 | 按鈕／路徑條件、感謝頁、舊新代碼並存、表單及同意流程。 | 對照發布版本，先重現一項受影響事件。 |
| Meta、Google Ads、GA4 同接收表各有不同數字 | 各自事件定義、期間、時區、歸因窗口、計數及資料範圍。 | 先做定義對照，再比較共同範圍；唔靠改名令總數睇落一致。 |
重複事件、去重同計數設定係不同問題
先問「同一個業務行動由邊度送出」，再問「目的地點處理」。如果一項事件同時由瀏覽器、外掛及伺服器整合送出，要按正在使用嘅整合文件核對去重方法；見到兩條請求，唔足以判斷平台最後一定記兩次。亦唔應為咗少一條請求就直接停掉仍有用途嘅整合。
Google Ads 可按每項轉化動作選 One 或 Every。One 係每次廣告點擊下該轉化動作嘅計數方式，唔係跨渠道辨認唯一客戶。選項應配合業務定義；修正重複安裝同選擇計數方式要分開驗收。
重要事件同廣告出價目標亦要分開核對
GA4 把一個事件標示為重要，唔代表所有廣告活動就會採用佢出價。Google Ads 要同時核對轉化動作設定同活動使用嘅目標。一般主要／次要動作有不同報告及出價用途；自訂目標亦有例外，唔應只見「次要」兩個字就推斷所有情況都唔參與出價。
一個可交畀團隊執行嘅排查次序
- 保留版本與定義：記低問題開始日期、改版／容器版本、事件來源、目的地及目前報告條件。
- 重現一次行動：在獲授權範圍內用清楚標示嘅測試資料，記錄裝置、網址、步驟同時間；唔將測試當真實新客。
- 先查接收：由相應接收方確認有冇建立需求、通知同分派；發現功能故障先處理功能。
- 再查訊號：對照網站成功條件、GTM 預覽或平台支援嘅測試方式，列出每項事件由誰送出。
- 比較共同範圍：統一報告期間與事件定義，記錄同意、裝置及來源辨識限制。
- 一次修一項並回測：保留可回復版本，重測成功、漏填、失敗及重試，先交接再觀察正式數據。
示範：收到一張名單，卻出現三種「轉化」
以下係示範情境，唔係客戶案例。訪客先按 WhatsApp，再用表單查詢；網站同時記錄聯絡點擊、表單互動及成功需求。如果報告把三者直接相加，三個訊號唔等於三個客戶。排查要先保留每個事件嘅用途，再決定邊個代表觀察、成功接收或業務階段，而唔係刪到數字剛好等於一。
常見問題
改用伺服器端追蹤就會準確到一樣嗎？
唔會自動解決事件定義、接收故障、重複來源或報告範圍差異。先確認要改善嘅缺漏、已確認可使用嘅資料範圍、整合責任同驗收方法，再決定技術方案。
可以把全部表單資料送去方便查錯？
唔應咁做。一般 Analytics 事件唔應包含姓名、電話、電郵或自由文字；用受控接收記錄驗證業務結果，並只傳經確認需要嘅非個人分類。
數字突然跌，第一步係加預算？
先分辨流量減少、真實需求減少，定量度失效。用相同期間、定義及可追查證據確認問題，避免用媒體預算掩蓋接收或追蹤故障。
由排查結果決定下一步
官方參考與更新說明
本文事件表、驗收表同示範情境由 ITOB Group 編輯整理，唔係客戶成果；實際介面及支援方式要按使用中帳戶確認。最後實質更新：2026 年 10 月 26 日。
