GA4 名單分級事件最容易做錯的地方，不是技術埋點，而是把整條名單流程都塞進 generate_lead。表單送出只代表有人留下資料，不代表這筆名單已經合格、有人開始跟進，或最後真的成交。對台灣中小企業來說，最小可用做法通常是先把 generate_lead、qualify_lead、working_lead、close_convert_lead 拆開，讓行銷、業務和老闆第一次能在同一條報表線上，看出送單量和可成交名單是不是同一件事。
Google 官方現在已經把 lead generation 的標準事件拆得很清楚。Analytics Help 說明，這組事件適合量測 online 與 offline 的完整 lead funnel，而且送出後會填入 Lead acquisition report；Google for Developers 則補上每個事件的語意、參數與範例。Google Analytics Help Google for Developers 也就是說，今天多數團隊卡住的，已經不是「GA4 有沒有事件可用」，而是「我們內部怎麼定義什麼叫合格、什麼叫開始跟進、什麼時候才算成交」。
為什麼 GA4 名單分級事件不能只記 generate_lead？
因為 generate_lead 只是在記「有人送出表單或提交資料」，它不會幫你判斷這筆名單值不值得追。若你把所有後續都停在這裡，最後只能比較誰送來的名單多，卻看不出哪個來源的名單比較像真商機。這對 B2B 服務、顧問、預約型商家、教育課程、裝修或高單價服務特別危險，因為名單數和成交機率常常差很遠。
Google Analytics Help 對 key event 的定義也很直接：只要這個動作對你的商業成功重要，就可以把它標成 key event，之後再看不同渠道如何帶出這些動作。Google Analytics Help 這代表如果你的生意是先收單、再篩選、再交給業務，真正重要的動作不會只有送單。你至少要能分出「已合格」和「已開始跟進」，不然同一個廣告或 SEO 頁面帶來的 30 筆表單，看起來都一樣，實際上卻可能只有 5 筆值得追。
六個標準 lead event 該怎麼分工？
| 事件 | 代表什麼 | 什麼時候送 | 最常見的誤用 |
|---|---|---|---|
generate_lead | 名單生成 | 表單送出、留下聯絡資料、線下資料進系統 | 把後續資格判斷也一起算進來 |
qualify_lead | 名單符合條件 | 符合你的 MQL、SQL 或最小商機條件時 | 只要送單就立刻標成合格 |
disqualify_lead | 名單不合格 | 確認不符合地區、需求、預算或對象時 | 沒有原因欄位，之後看不出為何淘汰 |
working_lead | 有人開始接手 | 業務已聯絡，或客戶已被聯絡 | 和 qualify_lead 混成同一件事 |
close_convert_lead | 名單變客戶 | 簽約、開始付費、正式成交 | 把報價送出就算成交 |
close_unconvert_lead | 名單結束但未成交 | 確認本次商機不會轉成客戶 | 沒有標失敗原因，後面無法優化 |
官方 recommended events 說得很明確：這六個事件本來就是給 lead funnel 用的，不是你自己發明的一套命名法。Google Analytics Help 若你的內部流程本來就會分送單、審核、聯絡、成交，最穩的做法通常不是另起爐灶命名 lead_submitted、lead_approved、lead_contacted，而是先吃 Google 已經定義好的語意。這樣之後看報表、做 audience、拉 key event 或交接代理商，比較不容易每個人講不同語言。
Google for Developers 也補了幾個很關鍵的細節。像 working_lead 的定義不是「團隊想追這筆名單」，而是「使用者聯絡代表或由代表聯絡」；close_convert_lead 則是合格名單成功變成客戶。Google for Developers 這兩個定義如果不先拆開，你很容易把「有意願」和「已經有人處理」混成同一層，之後就看不出到底是篩選標準有問題，還是業務接手太慢。
GA4 事件命名規則與最常踩的坑
如果你真的需要建立自訂事件，Google 的命名規則至少有四件事要先記住：事件名稱區分大小寫、事件名稱必須以字母開頭、只能用字母數字和底線、不能用保留前綴與保留事件名稱。Google Analytics Help 很多團隊不是不懂埋點，而是因為內部有人寫 Generate_Lead、有人寫 generate_lead、有人又自創 lead_generate，最後報表拆成三堆，看起來像三條不同漏斗。
另一個常踩的坑，是以為 GA4 後台 rename 一下事件就能把歷史資料一起洗乾淨。Google Analytics Help 寫得很清楚：modified and new events do not apply to historical data，而且修改生效要一小時以上。Google Analytics Help 這表示如果你今天才把 lead_submit 改成 generate_lead，過去那段資料不會自動變得乾淨。對老闆或代理商報告時，必須把「哪一天以前是舊事件、哪一天之後才開始可信」標清楚。
還有一個更容易被忽略的風險：如果你把已經標成 key event 的事件重新命名，原本那個 key event 狀態不會自動跟著新名字走。Google Help 在 rename 範例裡直接警告，若把已標成 key event 的事件改名，它就不再是 key event。Google Analytics Help 所以實務上比較穩的順序是：先定好命名，再標 key event，而不是反過來邊改邊補。
GA4 和 CRM 該怎麼分工？
| 系統 | 應該負責什麼 | 不該硬塞什麼 |
|---|---|---|
| GA4 | 記錄事件發生、渠道來源、頁面與 key event 表現 | 不要把完整業務筆記和商機責任都塞進去 |
| CRM | 記錄負責人、跟進進度、商機備註、成交細節 | 不要期待它自然還原網站前端行為漏斗 |
| 試算表或中繼流程 | 補例外狀況、欄位對照、臨時治理規範 | 不要長期拿來取代正式責任系統 |
GA4 比較適合回答「哪個頁面、哪個活動、哪個來源先帶來這批名單」，CRM 比較適合回答「這批名單後來是誰接、卡在哪、為什麼贏或輸」。如果你把這兩個層次混在一起，很容易出現一種假象：GA4 看起來送單很多，但業務端根本沒有人願意追；或者 CRM 裡說這波活動很有價值，GA4 卻因為事件命名亂掉而完全對不起來。
比較務實的做法，是讓 GA4 先維持事件語意乾淨，再由 CRM 決定誰來送出 qualify_lead、誰來送出 working_lead、什麼條件才送 close_convert_lead。這樣報表雖然不是 100% 全自動，但至少每一個狀態有責任人，不會變成「大家都覺得有在追，結果沒有人真的回寫」。
台灣 SME 7 天導入順序
第 1 天：先列出你現在有哪些 lead 事件
把網站、表單、LINE、電話預約、線下活動匯入名單全部盤點一次。很多團隊以為自己只有一個送單事件，實際上前台和後台各記一套，重複計數從這裡就開始了。
第 2 天：決定 generate_lead 只記哪一種動作
建議只記「名單真的產生」這件事，例如表單送出成功、線下名單被正式匯入。不要把點擊按鈕、打開表單、送出失敗都塞進來。
第 3 天：把 qualify_lead 的條件寫成一句話
例如「符合目標地區、需求明確、留有可聯絡方式，且願意在 30 天內預約或報價」就是一個夠用起點。這句話不寫清楚，團隊每個人心裡的合格名單都不一樣。
第 4 天：把 working_lead 綁到真人接手
只有當業務或客服真的已聯絡，或名單已被正式聯絡時，才送出 working_lead。這層很重要，因為它是「名單存在」和「有人接手」中間最常漏掉的一段。
第 5 天：決定哪些事件先標成 key event
不是每個 lead event 一開始都要標成 key event。對多數 SME 來說，先標 generate_lead 和 close_convert_lead 比較穩；若你的跟進流程已經成熟，再加上 qualify_lead 或 working_lead。
第 6 天：用 DebugView 和 Realtime 驗證
Google Analytics Help 明寫，recommended events 設定後可以先用 DebugView 檢查。Google Analytics Help 先驗證每個事件有沒有真的進來，再討論報表，通常會少掉很多無謂會議。
第 7 天：標註新舊命名切線
如果你有改名、重建或補事件，務必在文件和報表裡標明哪一天開始採新規則。因為後台 rename 不回補歷史資料，這條切線不寫，兩個月後你就很難跟任何人解釋數字為什麼突然變好或變差。
適合誰，不適合誰
這套做法最適合會先收名單、再由人跟進、最後才成交的台灣中小企業，像 B2B 顧問、教育培訓、裝修、醫療行政、在地高客單服務、軟體 demo 或需要預約諮詢的商業模式。這些情境本來就不該只看送單量，而要看送單後有多少真的往下走。
如果你的網站幾乎所有轉換都是即時購買，或團隊根本沒有 CRM、沒有任何跟進流程，那你先要補的不是名單分級事件，而是基本事件治理或商機流程。否則就算 GA4 事件排得很漂亮，後端也沒有任何責任節點可以接。
資料更新與來源
本文於 2026 年 6 月 20 日整理。與 lead funnel 事件語意有關的內容，優先依據 Google Analytics Help 與 Google for Developers；與命名規則、保留字、改名限制有關的內容，則依據 Google 官方 help center。這些規則與文件更新速度很快，實作前仍應以當前官方頁面為準。
- Google Analytics Help：Recommended events
- Google for Developers：Recommended events reference
- Google Analytics Help：About events
- Google Analytics Help：About key events
- Google Analytics Help：事件命名規則
- Google Analytics Help：Rename and generate new events
這篇不引用任何未經你帳號驗證的平均轉換率。對這個題目來說，真正有用的不是背別人的 KPI，而是先把自己公司的送單、合格、接手和成交定義拆乾淨。
結論
GA4 名單分級事件真正該做的，不是把 event list 越寫越長，而是讓每一個階段都只代表一件事。當 generate_lead 只代表送單、qualify_lead 只代表合格、working_lead 只代表有人接手、close_convert_lead 才代表成交，你第一次會看見同一個流量來源到底是帶來很多表單，還是帶來很多真商機。對台灣 SME 來說，這往往比再多買一套報表工具更有用。
FAQ
GA4 名單分級事件一定要全部六個都上嗎？
不一定。多數台灣中小企業可以先從 generate_lead、qualify_lead、working_lead、close_convert_lead 開始，等流程穩了再補 disqualify_lead 和 close_unconvert_lead。
qualify_lead 和 working_lead 最大差別是什麼？
qualify_lead 是這筆名單符合條件，working_lead 則是有人真的開始接手。前者是判斷，後者是動作，兩個層次不能混在一起。
GA4 事件改名後，舊資料會一起變嗎？
不會。Google Analytics Help 明寫 modified and new events 不適用於歷史資料，所以改名後要標註新舊資料切線。
GA4 名單分級事件都要標成 key event 嗎？
不一定。若你還在第一版治理，通常先標 generate_lead 和 close_convert_lead 比較穩；流程成熟後，再看 qualify_lead 或 working_lead 是否也值得做成 key event。
如果公司已經有 CRM，GA4 還需要記這些 lead event 嗎？
需要。CRM 比較擅長商機責任與跟進細節，GA4 則擅長看渠道、頁面和前端行為。兩邊一起用，才看得出哪個流量來源不只是送單，而是真的會走到成交。