追蹤設定通常是這樣長出來的：需要什麼就加一個事件，半年後有六十個事件，名稱風格各異，沒有人記得哪個是哪個。這篇提供一個先分層再命名的方式，讓事件表可以長期維護。
先建立分層。使用者從第一次接觸到成交，行為的價值遞增。把事件依價值分成五層，命名時帶上層級，報表就能自然聚合，也能一眼看出漏斗的形狀。
五層的比例本身就是診斷工具。曝光到互動的落差大，代表內容不吸引；意圖到提交的落差大，代表表單或流程有摩擦；提交到成果的落差大，代表銷售端或名單品質有問題。
建議格式：層級-物件-動作，全部小寫，用底線連接。例如 intent_contact_click、submit_inquiry_form、result_deal_closed。這個格式排序後會自然依層級分組，也讓新人一眼看懂。
事件名稱回答「發生了什麼」，參數回答「在哪裡、什麼情況」。常用的參數有四個：頁面路徑、來源、素材或版位、以及數值。把可變的資訊放在參數，可以避免事件數量爆炸。
反面例子是把每個表單各建一個事件：submit_form_a、submit_form_b、submit_form_c。正確的做法是一個 submit_inquiry_form 事件，用參數區分是哪一份表單。
建議控制在二十個以內。超過二十個通常代表有事件應該合併成參數。事件太多的代價不只是混亂，還包含每一個都需要維護、驗證與說明。
每個事件上線後必須驗證三件事：在正確的時機觸發、只觸發一次、參數值正確。第二項最容易出錯，特別是單頁應用或有動態載入的頁面，重複觸發會讓數字虛高。
驗證的最低要求是實際操作一次完整流程，逐步檢查即時資料。這件事應該由實作者以外的人做，因為實作者容易依照自己的預期去看。
第三項是最隱蔽的問題，因為報表看起來仍然正常。定期驗證是唯一的防範方式。關於資料落差的判讀，站內的 數字對不起來的五個原因 有更完整的說明。
以一個顧問型網站為例，二十個事件裡各層的分布大約是：曝光層三個、互動層五個、意圖層六個、提交層四個、成果層兩個。意圖層最多，因為那一層的細節最能說明使用者的考慮方向。
意圖層的六個事件是：點擊聯絡方式、開始填寫表單、下載資料、點擊價格區塊、展開常見問題、以及停留超過某個時間。六個事件搭配頁面路徑參數，就能畫出相當完整的考慮路徑。
第四項最常被跳過，卻是重複計數最常見的來源。
三個月沒有資料的事件先標記為待廢除，而不是直接刪除。標記後再觀察一個月，確認不是季節性因素。然後檢查是否有報表或自動化流程依賴它，確認沒有之後才停止。
直接刪除的風險是某些依賴不會立刻浮現。曾經有一個每季執行的報表因為事件被刪除而失效，但因為它每季才跑一次，三個月後才被發現，而那時已經缺了一整季的資料。
不同產業差異很大，但有一個通用的判斷方式：相鄰兩層之間的落差如果超過一個數量級，通常代表中間有摩擦。例如互動層一千、意圖層十五，這中間掉了將近兩個數量級，值得檢查。
另一個要看的是各層的絕對數量是否足以支撐分析。如果成果層每月只有三筆，那麼任何基於轉換率的比較都不可靠，這時候應該把分析重心放在意圖層。
把五層的月度數字畫成一張趨勢圖，六個月之後就能看出哪一層是長期的瓶頸，而那一層就是資源該投入的地方。
最後一個提醒：事件設計是一次性的投入、長期的資產。花兩天把分層與命名想清楚，可以省下未來三年反覆整理的時間，這個投入報酬率相當明確。
事件分類法最後的成敗，取決於有沒有人維護那份命名對照表。剛開始大家都會遵守，半年後新同事加了幾個自己命名的事件，一年後報表就開始對不起來。務實的做法是把對照表放在團隊每天都會經過的地方，並規定新增事件必須先登記再實作。這個流程聽起來麻煩，但它比日後花兩週回頭清理資料便宜太多，也讓歷史資料在改版之後仍然可比。