Google Ads 名單沒進 CRM時，真正要先查的通常不是廣告有沒有人填，而是名單從 Google Ads lead form 送出後，在哪一個交接點斷掉了。對台灣中小企業最常見的斷點有 5 個：webhook key 沒對上、根本沒送成功測試資料、端點沒有回 HTTP 200、CRM 欄位 mapping 或 dedupe 規則錯誤、以及誤以為漏掉的名單之後還能無限補抓。先把這 5 個點查清楚，才知道要修 webhook、修 CRM，還是回頭補 30 到 60 天的名單補救。
Google Ads 名單表單有填，為什麼業務還是說沒收到？
因為 Google Ads lead form 的「有人送出」和 CRM 的「有人真的入庫」中間，本來就隔著一條交接鏈。Google for Developers 的 webhook 概覽寫得很直接：廣告主可設定一個 URL path 與 key，使用者送出 lead form 後，Google 會以 HTTP POST 把名單資料送到指定 URL，之後資料才會進入你的 CRM。來源：Google for Developers: Lead Form Webhook Overview。
也就是說，只要 URL、key、回應碼、欄位解析或 CRM 寫入其中一段出錯，廣告後台看到的 lead submission 並不代表前線真的接到單。這也是很多台灣 SME 會誤判的地方：投手覺得廣告有帶名單，客服卻說沒資料，最後老闆只看到「表單有填、成交沒跟上」。
Google 官方文件其實已經講清楚最小可用路徑
Google Ads Help 的設定教學把最小可用流程寫得很明白：編輯 lead form 後，展開「Export leads from Google Ads」與「Other data integration options」，填入 webhook URL 與 webhook key，再按 Send test data 驗證 CRM 是否真的收到。來源：Google Ads Help: How to set up a webhook integration for a lead form。
同一篇說明也列出錯誤狀態：如果沒有成功送測試資料、資料沒有送出、Google 沒收到回應，或收到的不是 HTTP 200，都不算成功。這個訊號很重要，因為它告訴你排查順序應該先看「Google 有沒有送、你的端點有沒有回、CRM 有沒有存」，而不是一開始就怪廣告品質。
| 交接步驟 | Google 官方說法 | 台灣 SME 該檢查什麼 |
|---|---|---|
| 1. 送出表單 | 使用者提交後，Google 會送出 HTTP POST | 廣告後台是否確實有 lead submission |
| 2. webhook 驗證 | URL 與 key 要正確，key 用來驗證名單 | key 是否和 Google Ads 後台一致、是否曾被改過 |
| 3. 端點回應 | 成功狀態需回 HTTP 200 | 有沒有 timeout、401、403、500 或非 200 |
| 4. 寫入 CRM | payload 內含 lead_id、user_column_data 等欄位 | 欄位 mapping、必填規則、重複單邏輯是否把名單擋掉 |
| 5. 補救與追查 | CSV 只保留 30 天，API 最多可自動匯出 60 天到 CRM | 漏接後能補幾天、由誰補、補完如何去重 |
最常見的 5 個 webhook 斷點
1. webhook key 不一致，Google 有送但你的系統不認
Google 的 implementation 文件說得很清楚，payload 內會帶 google_key，而且官方建議在處理名單前先驗證這個 key 是否與 Google Ads 後台配置一致。來源：Google for Developers: Lead Form Webhook Implementation。如果你的 CRM 或中介工具裡留的是舊 key，或外包曾改過設定沒同步，最常發生的結果就是 Google 送了，端點卻因驗證失敗直接丟掉。
這種情況常見於多人共管帳號、代理商交接、或同一個 CRM 測過多個表單。比較穩的做法，是把每個 lead form 的 key、對應 URL、負責人和最後測試時間寫成一張交接表，而不是只留在某個人記憶裡。
2. 後台存檔了，但根本沒有成功送過測試資料
Google Ads Help 列出的錯誤狀態 A 很有代表性：有人把表單存起來，但沒有成功送出測試資料。來源：Google Ads Help: How to set up a webhook integration for a lead form。對台灣小團隊來說，這通常不是技術問題，而是流程問題。投手以為設定完就算交件，CRM 管理者以為之後自然會收到，結果正式名單一進來才第一次發現根本沒通。
如果你現在正要接新活動、換新表單或換 CRM，測試不該只做一次，也不該只看 Google 後台顯示成功。你至少要確認測試單真的出現在 CRM、欄位沒有亂掉、負責人看得到、通知有發出去。
3. 端點有收到，但沒有正確回 HTTP 200
Google 的文件把這件事講得很直接：成功狀態必須是 HTTP 200，非 200 都會落在錯誤狀態。Google 的 implementation 也列出回應邏輯，4XX 表示不可重試的請求錯誤，5XX 則屬可重試的間歇錯誤。來源：Google for Developers: Lead Form Webhook Implementation。
這代表名單沒進 CRM 時，不要只看資料庫裡有沒有資料，還要看 webhook 日誌到底回了什麼。很多中小企業用 no-code 平台、中介服務或自建端點時，常見的是 401 權限錯、403 驗證錯、500 寫入失敗，或是雖然寫進 queue 了，但端點回應太慢被當成 timeout。這些都會讓 Google 判定交接不完整。
4. 欄位 mapping、必填規則或 dedupe 把名單擋掉了
Google 的 payload schema 說明指出，使用者資料會放在 user_column_data，其中要依 column_id 與 string_value 解析，不該只依賴 human-readable 欄位名稱。來源：Google for Developers: Lead Form Webhook Implementation。如果你的 CRM 只接受固定欄位、欄位型別沒轉好，或把 email / phone 視為強制必填，就可能在寫入時被擋掉。
LeadsBridge 的實作建議補了一個很實用的觀點：raw payload 要先保留，mapping 要明確，並在寫入前驗證 email 或 phone、form ID、timestamp 等必要欄位；若做 dedupe，也應以穩定規則而不是猜測式比對處理。來源：LeadsBridge: Google lead form webhook integrations。對台灣 SME 來說，這表示你要分清楚「名單沒收到」和「名單被 CRM 規則吃掉」其實是兩回事。
另一個常被忽略的點是 Google 官方明說 webhook delivery 不保證 exactly once，因此建議用 lead_id 做 dedupe。換句話說，如果你的系統沒去重，可能重複建立；如果去重規則寫得太粗，也可能把真新名單誤判成舊資料。這一層最好先測清楚。
5. 以為漏掉的名單之後隨時都能補抓
Google Ads Help 在 lead form assets 說明裡明寫：你可下載最近 30 天內提交的 leads；若要自動匯出到 CRM，Google Ads API 最多支援 60 天的 lead form data。來源：Google Ads Help: About lead form assets。這個限制很重要，因為它直接決定補救節奏。
如果你是一週後才發現 CRM 沒接到名單，通常還有機會靠 CSV 或 API 補抓；但如果你兩個月後才回頭查，很多資料可能已超過手動可下載範圍。對台灣 SME 比較務實的做法，是把「每次改 webhook 必須留測試紀錄、每週抽查一次入庫、每月核對 Google leads 和 CRM 筆數」寫成 routine，而不是等業務抱怨才補救。
哪些台灣中小企業適合先做 webhook，哪些不要急著串
如果你已經固定在 Google Ads 用 lead form 收表單，而且詢問後需要客服、業務或門市在 1 個工作天內跟進，那 webhook 幾乎是基本配備。尤其是課程報名、B2B 諮詢、裝修估價、診所自費預約、加盟詢問、在地服務型生意，名單進 CRM 的速度會直接影響成交率。
但如果你現在連 CRM 欄位都還沒定好、誰負責跟單也不清楚、表單送出後只會寄到某個共用信箱，那先把 webhook 串上去也不會自動變好。你真正該先補的是最小欄位、回覆時限、負責人通知和 dedupe 規則。否則 Google Ads 名單只是從「掉在信箱裡」改成「掉在 CRM 裡」。
7 天修復順序：不要先改廣告，先把交接線拉直
第 1 天：盤點所有 lead form、URL、key 與負責人
先把正在跑的 Google Ads lead form 列出來，確認每個表單對應哪個 webhook URL、哪個 key、哪個 CRM pipeline、誰收通知。這一步的目的是讓你知道錯在單一表單，還是整個交接系統。
第 2 天：逐一送測試資料，確認 CRM 真有入庫
不要只看 Google 後台的按鈕有沒有按過。每個表單都送一次測試資料，並在 CRM 裡確認名單出現、欄位正確、通知發出、負責人看得到。若 CRM 是透過中介平台再轉一次，也要看中介平台日誌。
第 3 天：核對 HTTP 回應與錯誤日誌
把非 200 的回應全部抓出來，分類為驗證錯誤、逾時、欄位錯誤、端點失敗或服務中斷。這一天先求找出主要斷點，不用急著全部優化。
第 4 天：補欄位 mapping 與 dedupe 規則
把 FULL_NAME、EMAIL、PHONE_NUMBER、COMPANY_NAME 等常用欄位對應到 CRM，確認必填規則不會把有效名單擋掉。若你有去重規則，優先檢查是不是把不同表單來源的新名單合併掉。
第 5 天：補 30 到 60 天內漏接名單
若前幾天已確認曾漏接，立刻安排手動 CSV 或 API 補抓。補資料時同時標記來源與補抓日期，避免業務把舊名單當成剛進來的新單。
第 6 天：把 Google leads 與 CRM 筆數做週對帳
建立一個簡單表，每週對比 Google Ads lead submission 與 CRM 新增筆數。只要兩邊差距開始擴大，就能比業務口頭反映更早發現問題。
第 7 天：再回頭決定要不要放大投放
只有當名單真的能進 CRM、責任人會跟進、欄位能回寫時，才適合再加預算或加新 lead form。否則只是把更多漏接放大。
資料更新、限制與實作提醒
本文依 2026 年 6 月 25 日可查資料整理，核心事實優先採 Google for Developers 與 Google Ads Help。LeadsBridge 只作為非官方 benchmark，用來補足欄位 mapping、raw payload 保存與 idempotent 這類實作提醒。若你的帳戶介面語系不同、是第三方整合商代管，實際設定位置與日誌畫面可能不同，但排查順序不會差太多。
- Google for Developers: Lead Form Webhook Overview
- Google for Developers: Lead Form Webhook Implementation
- Google Ads Help: How to set up a webhook integration for a lead form
- Google Ads Help: About lead form assets
- LeadsBridge: Google lead form webhook integrations
結論
Google Ads 名單沒進 CRM 時，最危險的不是短暫漏掉幾筆，而是團隊以為名單流程本來就有接好，結果一直拿錯數字做決策。對台灣中小企業來說，最值得先做的不是重寫廣告，而是先把 URL、key、測試、HTTP 200、欄位 mapping、dedupe 和 30 到 60 天補救流程排清楚。交接線一拉直，廣告名單才會真的變成可跟進的商機，而不是後台裡一個看起來很漂亮的數字。
FAQ
Google Ads 名單表單有填寫，CRM 卻沒收到時，第一個要查什麼？
先查 lead form 的 webhook URL、webhook key 和 Send test data 是否真的通過，再看端點是否正確回 HTTP 200。這三個點通常比改廣告更早找出問題。
Google Ads webhook 一定要自己開發嗎？
不一定。Google Ads Help 也列出第三方整合商與 Zapier 等替代路徑。但不論你是自建還是用工具，都還是要確認 key、mapping、測試與 CRM 寫入規則。
為什麼測試資料有收到，正式名單還是可能漏掉？
因為正式流量可能觸發不同欄位、不同表單、不同去重規則，或端點在正式流量下出現 timeout、驗證錯誤與非 200 回應。所以測試通過後仍要做週對帳。
漏接名單還能補抓多久？
Google Ads Help 說明，CSV 只能下載最近 30 天名單，而 Google Ads API 最多可自動匯出 60 天 lead form data 到 CRM。超過這個範圍，補救空間會明顯變小。
Google Ads 名單進 CRM 後，還要再做什麼才不算白接？
至少要補上負責人通知、回覆時限、去重規則和每週對帳。否則名單只是從廣告後台搬到 CRM，沒有真的變成可追的商機。