網站詢問旅程要量哪些事件？從進頁到成功送出建立事件表

從詢問頁載入、表單互動到送出成功，整理必要事件、命名字典與避免收集識別資訊的核對方式。

網站詢問表單的事件追蹤，目標不是把每次滑鼠移動都留下來，而是看清訪客從進入詢問頁到完成送出的必要步驟，並找出哪一段需要改善。先定義成功，再安排最少事件；每筆事件只帶回答問題所需的欄位，不記姓名、電話、電子郵件或表單原文。

界定訪客核心任務

網站詢問旅程不是把所有滑鼠事件都記下來，而是回答一個決策問題：訪客從哪個入口看到詢問頁，是否開始填寫，最後有沒有完成送出。開始前先選定一種任務，例如「聯絡團隊詢問網站改版」，不要把客服求助、下載型錄與預約展示混在同一張漏斗；它們的成功條件不同。列出訪客從入口到確認畫面會經過的頁面、表單步驟與分流，標示哪些步驟是必經、哪些只在特定版本出現。再定義成功的業務含義：資料通過必要欄位檢查並收到系統成功回應，或進入明確的確認頁；按鈕變色、點擊或瀏覽停留都不是完成。這個定義要和表單實際送出方式一致，否則改成非同步送出、嵌入表單或導頁後，報表可能仍只看到舊按鈕。最後把要回答的問題寫成一句話，例如「哪個入口帶來完成詢問？」或「手機上哪個步驟流失較多？」；若一個事件無法幫助回答問題或定位故障，先不要收集。範圍先限一個表單、一種訪客任務及一個成功終點，之後有明確決策需要再擴充。若同頁放了多個聯絡入口，先指定本次要追的表單，其他入口另列待辦，避免數字混成一個無法解讀的總和。如果網站有多個來訪入口，先以頁面路徑或人工定義的入口類別分開看，別把廣告、自然搜尋與電子報帶來的訪客放成同一批而誤讀差異。這不是要完整追蹤每位訪客，而是把比較範圍說清楚。先畫一張只有頁面框與箭頭的簡圖；若訪客可以跳過某步，就標成可選，事件表才不會假設每個人都走相同順序。

標記必要旅程事件

先把事件放在訪客確實跨過的節點，而不是替每個按鈕各取一個名稱。最小旅程通常包含：詢問頁已載入、第一次與表單互動、送出請求開始，以及系統確認接受或回報失敗。頁面載入要在內容可用時記一次；表單開始可定義成首次聚焦或首次輸入，但同一趟瀏覽只記一次，不能每換一欄就增加。送出嘗試要在通過前端必填檢查、即將送出請求時觸發，因為空白必填欄位被擋下不代表請求已送出。成功事件等伺服器或表單服務回覆接受後才觸發；失敗則只需記結果類別，例如驗證拒絕、網路中斷或服務錯誤。若要知道使用者卡在哪一欄，可另外量「欄位驗證錯誤」的類型，但先確認這項資訊會改變表單設計或除錯方式。每一事件都寫清觸發時機、每次訪客最多觸發次數、可能不觸發的情境與用途。接著沿著真實頁面流程逐點對照：訪客不需先展開說明就能填表時，不要虛構「展開說明」節點；若表單有兩步，才加入步驟完成事件。以「首頁入口→詢問頁→填寫→送出→確認」為主線，將非必經的成功提示或外連列為可選觀測。這樣事件數量能回答漏斗問題，也讓實作與後續解讀都能維持一致。事件不一定全要送到同一套分析工具：表單伺服器紀錄可能已能分辨請求結果，分析端只需用彙總事件理解哪個頁面或裝置群較常流失。先核對現有系統已能回答哪些問題，再補缺口，免得同一送出流程在兩個地方重複計數。若不需要逐欄診斷，就跳過欄位錯誤事件；必要事件維持精簡，才容易在每次改版後重新驗收。

建立事件名稱字典

為每個事件建立一張團隊共用字典，採穩定的英文小寫底線命名，例如 inquiry_page_view、inquiry_form_start、inquiry_submit_attempt、inquiry_submit_success、inquiry_submit_failure。名稱描述發生的業務動作，不塞頁面版本、活動名稱或日期；這些若確實需要比較，應放在有範圍限制的屬性裡。字典至少記錄事件名稱、觸發條件、必填屬性、允許值、去重方式、負責維護者與用途。下表是一個可依實際表單調整的假設範例：

屬性只放有限、可說明的值，例如頁面代碼、入口類別、裝置類別、步驟代碼或錯誤類別；不要把完整網址、任意查詢字串或自由文字原樣送進分析工具。若必須比較不同表單，採事先列出的 form_code；若表單改版，只有當改版會改變判讀時才增加 form_version。不要因某個工具的預設報表喜歡另一種寫法，就任意改變事件語意。前端程式、標籤管理與儀表板都依字典對齊；改名或退役時記錄日期與映射，避免同一事件在新舊拼法下被拆成兩條趨勢。每次新增屬性都說明要回答的決策與可接受值，答不出用途就不加入。由一人維護字典，提交時附上觸發規則，避免不同頁面各自實作出看似相同、實際定義不同的事件。事件要能跨頁面比較，所以同名事件保持同一時機；若某分流有不同流程，使用 flow_code 等有限值標記，不能另造拼法冒充新事件。字典發布前找一位實作者與一位報表使用者共同走讀，確認看欄位就能知道何時觸發、如何解讀。

避免收集直接識別值

分析事件通常只需要知道某類訪客走到哪一步，不需要知道這個人是誰。姓名、電子郵件、電話、公司名稱、完整訊息、地址與上傳檔名都不應放進事件名稱、屬性、網址參數或錯誤紀錄；表單輸入內容也不要隨事件一起自動擷取。以表單代碼、欄位類型、步驟代碼與結果類別替代原始答案，例如記「email 欄格式錯誤」而不記使用者輸入的地址，記「訊息欄超過上限」而不記訊息本身。實作時檢查三個出口：瀏覽器送出的分析請求、網站或標籤工具的除錯紀錄、伺服器錯誤日誌；任何一處出現原始欄位值，都要先修正再開始正式量測。特別檢查錯誤頁是否把表單內容帶到網址、是否有表單外掛自動追蹤輸入值，以及除錯工具是否保留完整請求本文。不要把電子郵件做雜湊後就當成非識別資料；同一值若能被長期比對，仍有不必要的連結風險。若業務真的需要將分析和案件系統對照，先分開用途：分析端只保留不含個資的事件，案件識別碼留在有權限的業務系統，並由負責人決定是否需要受控對照流程。任何隨機工作階段代碼也先問是否必要、保存多久及誰能讀取，再決定是否使用。送出前讓測試人員用明確的假資料檢查每個欄位，並以搜尋關鍵字確認沒有名稱、信箱、電話或完整訊息外流。若回答問題不需要識別某位訪客，就不要建立可回查個人的鍵值；最小化從資料設計開始，而不是等報表做好才刪欄位。先以資料流圖列出收集端、轉送端和保存端，再在每個節點確認哪些欄位會被複製。

區分成功失敗狀態

把「按下送出」和「送出成功」視為兩個不同狀態，才能分辨表單有人嘗試但系統沒有收到資料。一次有效流程可以是：前端欄位檢查未通過，顯示提示但不送出請求；檢查通過後記錄 attempt；請求送出後等待回應；只有收到明確接受結果，才記 success。若回應表示資料未被接受，記錄 failure 和有限的錯誤類別；若請求逾時、頁面關閉或回應不明，應標成未知或未確認，不要直接當成成功，也不要把「未收到成功訊號」統統說成服務故障。成功頁可當輔助訊號，但要確認它不能由直接輸入網址、重新整理或返回頁面重複觸發；如果表單在原頁以非同步方式完成，則應以實際成功回應為準。定義重複送出的處理方式：一次表單動作可能因重試產生多個 attempt，但若業務只接受一筆，success 應依系統回應或去重規則計算，不要用按鈕點擊次數推算案件數。用 status 或 result_type 保留可行動的狀態，例如 accepted、validation_rejected、network_error、server_error、unknown；不需把錯誤堆疊、伺服器訊息或輸入內容送入分析平台。若成功是「收到請求」而非「完成服務」，命名就寫 submit_success，不要寫成 deal_won 或 customer_converted。儀表板同時呈現嘗試、成功、已分類失敗與未知數，並註明分母採哪一種事件。這些定義讓團隊能找流程摩擦並定位傳輸問題，而不會把追蹤訊號誤讀為實際業務成果。若使用第三方表單嵌入，先確認完成訊號如何回到頁面；不要假設跨網域跳轉成功，就必然能將前後兩段接成同一趟旅程。多個系統回報結果時，先指定唯一權威來源，以免一筆詢問在回呼和確認頁各記一次。對未知狀態保留監測比例，若突然增加先查部署或連線；未知不該直接重送，以免重複建案。

用測試資料逐項核對

正式啟用前，在測試環境用虛構姓名、不可寄送的測試信箱及假電話走完整流程；不要拿真客戶資料「試看看」。逐筆檢查頁面載入、首次互動、有效送出與成功回應各只在預定時機出現，再測必填漏填、格式錯誤、網路中斷、伺服器拒絕、連按兩次、返回及重新整理。對每個情境記下預期事件、實際事件、次數與允許屬性，事件名稱拼字、大小寫和欄位型別都要一致；失敗時要檢查是前端沒觸發、請求沒送出、回應沒被辨識，還是工具設定沒收到。再從分析請求本文和日誌搜尋測試資料，確認姓名、信箱、電話及訊息沒有出現。假設一輪虛構測試有 20 次詢問頁載入、8 次開始填寫、5 次有效送出、4 次成功、1 次網路失敗，則測試樣本的開始到成功比率是 4÷8＝50%；這只是在驗算事件和算式，不是成效基準或預測。發現數字不合預期時，逐個比對觸發點，不要用調整儀表板篩選條件掩蓋漏記。驗收清單應包含事件字典版本、測試日期、測試環境、每種狀態的預期數量、個資檢查結果與修正紀錄；正式收集開始後，持續注意事件是否中斷；遇到表單改版或設定變更，再依同一份清單重走受影響的情境。再補測手機版畫面與返回頁面，確認成功訊號仍符合定義。最好將每個預期結果寫成表格中的一列，留存實際事件記錄的遮罩截圖或欄位摘要，方便之後核對；截圖先確認沒有輸入值和個資。只有關鍵分支都能在測試資料下呈現預期結果，才切換至正式收集。現在先選一個表單，照事件字典完成測試環境核對；若還要整理網站與後續工作流程的接手方式，可從 ZhenheAI 官網 查看相關資訊。