AO2 FIELD GUIDE · N073 · 數據量測與成效判讀
有效詢問定義需分開定義網站事件與業務確認。附事件、需求及狀態對照，核對成功提交、資料品質與服務適配，避免把送出點擊當成果。
- 使用者有互動，不代表需求已送達。
- 提交成功，不代表資料完整或沒有重複。
- 可聯絡，不代表需求符合服務範圍。
- 需求合格，也不等於已報價或成交。
有效詢問定義：從一個常見爭議開始：行銷說有名單，業務說沒商機
這不一定代表任何一方做錯。行銷可能統計表單成功事件，業務則只把已有明確專案、資料足夠且在供應範圍內的需求稱為商機。若名稱都叫「有效詢問」，報告就會持續爭論，而不是找到流程問題。
先為每個狀態寫操作定義：誰可以判定、需要什麼證據、何時更新，以及不確定時放在哪個狀態。這份定義應放進事件規格與 CRM 欄位說明，而不是只在月會口頭約定。
用五個狀態連接網站與業務
| 狀態 | 可核對的事實 | 判定責任 |
|---|---|---|
| 已互動 | 點選 CTA、開始填寫或下載資料 | 網站量測規則 |
| 已收到 | 提交被系統接受，存在可追查需求紀錄 | 表單／後端流程 |
| 待確認 | 資料不足、重複待核對或需補問 | 營運／業務 |
| 符合初步條件 | 需求與供應範圍具適配性，可安排下一步 | 指定業務或產品角色 |
| 後續進展 | 技術討論、報價、暫緩、結案等已定義狀態 | 業務流程 |
這是建議的工作模型，不是 GA4 強制的狀態。企業可以使用自己的名稱，但不能讓狀態隱含互相衝突的意思。尤其「資料不足」不應自動等同無效；初次接觸者可能還需要網站協助他釐清條件。
GA4 事件名稱可以參考，但不會自動完成業務判斷
Google 的建議事件文件提供 generate_lead 與 qualify_lead 等事件，用以描述不同階段的名單行為；這些事件需要適當設定，並不會自行判斷企業的服務適配性。事件名稱與參數應依實際使用的官方文件核對。[1]
先用企業定義判斷哪個真實狀態適合對應哪個事件，再設計觸發時機。不要只因為某個名稱看起來比較接近成交，就在表單按鈕上觸發「合格」。也不需要在缺乏依據時替每筆詢問填入假想金額；價值估算與真實營收必須分清楚。
表單成功事件要在哪一刻觸發？
原則上應對應你能確認的完成事實。只按送出按鈕可能遇到欄位驗證失敗、連線中斷或伺服器錯誤；看到成功畫面也需核對它是否真的代表資料已接受。若表單與 CRM 是兩套系統，應分別處理「已收到」和「已寫入 CRM」。
測試正常、失敗、重送與部分成功情境，並對照表單紀錄、系統執行狀態與分析事件。若使用者在提交後重新整理成功頁，不應因此產生非預期的重複詢問計數。具體做法需依目前網站、同意設定與工具能力設計。
電子產業示例：不要用頭銜直接代替需求適配
以下為虛構詢問示例。甲詢問者是工程人員，已提供應用、版本與介面條件，但尚無確定採購日期；乙詢問者留下完整公司職稱，內容卻與供應範圍無關。若只以表單完整度或職稱評分，可能把甲排除、把乙標為合格。
更適合的初步條件是：需求類型是否可服務、基本應用是否清楚、哪些關鍵資訊仍需確認、是否有合理的下一個動作。預算或時程可以逐步釐清，不能在沒有背景時把未知值視為否定答案。人工判定也要留下原因，讓行銷知道該補哪種內容。
報告至少分開計數單位、時間與分母
| 項目 | 應說明的規則 |
|---|---|
| 計數單位 | 事件次數、提交筆數、去重需求數或已判定商機數 |
| 時間基準 | 提交日期、判定日期或進展日期 |
| 資料範圍 | 網站、展會、業務轉介等來源是否一起計算 |
| 待確認項目 | 尚未完成判定的數量與原因 |
| 分母 | 使用相同定義的需求群體，並說明觀察窗口 |
例如「本月收到、截至某日已完成初步判定的需求」和「本月被判定合格的需求」可能是不同群體。若直接相除，就可能把跨月判定與尚在等待的需求混在一起。先把群體寫清楚，再討論比例與趨勢。
回饋欄位與資料範圍：保留工作脈絡，避免傳送不必要資訊
CRM 可以保留業務需要的聯絡與需求資料，分析系統則應使用適合的事件與分類。Google Analytics 的政策禁止傳入其可辨識的個人識別資訊，例如電子郵件地址；應同時檢查事件參數、頁面網址、標題與自由輸入內容。[2]
不要把整份表單或完整客戶對話丟進 GA4 當成便利的自訂參數。若要串接跨系統狀態，需要由負責人確認同意、資料使用範圍、識別方式與實作規則。本文提供的是量測分工，不代表任何連接方式都已符合你的組織要求。
量測演練：一筆提交在不同系統裡代表什麼？
虛構測試情境：一筆需求送出後，網站成功接受，CRM 隨後寫入失敗。網站端可以有「已收到」紀錄，但不能把它報成 CRM 已建立。第二次重試完成後，應核對是否仍是同一筆需求，而不是報告中突然增加兩筆。
| 核對欄位 | 要回答的問題 |
|---|---|
| 來源提交識別 | 能否辨認這是同一次需求？ |
| 事件觸發 | 是否對應已確認的事實？失敗時是否誤觸發？ |
| CRM 狀態 | 未寫入、待確認、已判定是否分開？ |
| 計數規則 | 報告算事件次數，還是去重後需求筆數？ |
| 判定日期 | 與提交日期不同時，如何呈現？ |
再用相同需求做一次業務判定：如果只是缺少應用環境，狀態應保留待補問，原因也要回到內容或表單。這樣報表才能區分來源問題、資料問題與跟進問題，避免用一個合格比例掩蓋整條流程。
這份演練可先在去識別測試資料上完成，不需要把真實客戶內容送進分析工具。要串接實際資料時，再由系統與資料責任人核對識別、同意與使用規則。
常見問題
流量很小，還需要分這麼多狀態嗎？
可以簡化，但至少分開系統已收到、需要補資料，以及依業務條件可繼續處理。為每種狀態指定確認依據與負責人，先逐筆檢查需求是否被接手、卡在哪裡。資料量少時，同時呈現筆數與案例原因，避免只看少量事件形成的大幅百分比。若狀態從未影響分派或下一步，就調整它，而不是為了報表建立一套無人維護的分類。
所有詢問都要送回 GA4 嗎？
不一定。先列量測問題與需要的最小資料，將案件細節、聯絡資訊和業務判斷留在適當的 CRM 或內部系統；分析工具使用符合政策與同意安排的事件或彙整。檢查網址、事件參數與頁面標題，避免把姓名、電子郵件或表單原文送進 GA4。若設計關聯識別，仍需確認資料規則與存取，不能因為換成代碼就自動視為沒有風險。
如何知道定義有沒有幫助？
用既有去識別案件做獨立判定，請不同人列出符合或不符合的理由，再看分歧來自條件還是缺資料。接著檢查這些狀態是否真的決定補問、分派與跟進。若大家能分類但案件仍沒人處理，問題在流程；若反覆缺相同欄位，就改善蒐集方式。保存定義版本與修改理由，後續比較成效時使用相同範圍，不把分類改變造成的差異說成業務改善。
相關閱讀與下一步
了解對應 AO2 服務，或帶著目前的資料與工作問題，先確認適合開始的範圍。
參考資料與查核範圍
資料查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台規則；工作表、決策流程與虛構示例為本文整理。Johnny Wu 的公開分享作為作者工作觀點來源，未以此推定客戶成果或產品資格。
