事件命名不是工程師私事：行銷與分析要共享哪幾個欄位

事件命名不是工程師的私事，行銷與分析至少要和工程共享六個欄位：事件名稱、觸發條件、漏斗階段、關鍵參數、負責人、版本日期。下面用一場我實際主持過的對齊會議（對話經改寫）還原，為什麼少了任何一欄，報表就會在三個月後變成沒人看得懂的數字堆。

一場會議開頭的那句話：「這個 click_btn_2 是什麼？」

事件命名出問題的第一個徵兆，是行銷打開 GA4 時看不懂事件名稱在說什麼。那次會議一開場，行銷主管指著報表問：「click_btn_2 上個月多了四成，是好事嗎？」工程師回答：「那是首頁第二顆按鈕。」行銷追問：「首頁改版後第二顆按鈕換成什麼了？」現場安靜了大概十秒，沒有人答得出來。

這十秒說明了一件事：事件名稱只存在工程師的腦中，而且那個人的記憶並沒有跟著改版更新。數字漲了四成，可能是新的按鈕更吸引人，也可能只是把原本的「立即諮詢」換成了「看更多案例」，兩者的商業意義完全相反。當事件命名沒有被記錄成共用文件，每一次改版都等於重新定義一次指標，而報表上的趨勢線卻假裝什麼都沒變。

工程師說「名稱我來取就好」，行銷該怎麼回

名稱可以由工程師取，但命名規則必須由三方一起定，因為使用報表的人不是工程師。工程師在會中提出的顧慮很合理：「如果每個事件都要開會，我們會被拖垮。」我的回應是：不需要每個事件都開會，而是先定一次規則，之後照規則命名，只有例外才討論。

我們最後定的規則很簡單：一律小寫、用底線分隔、採「動作_對象」結構，例如 submit_consult_form、view_case_detail、download_price_sheet。名稱裡不放位置（不寫 btn_2、top_banner），因為位置會變；也不放活動名稱，活動用參數帶。這條規則寫成三行貼在共用表最上方，工程師取名時不必問人，行銷看報表時也能從名稱猜出八成意思。

六個必須共享的欄位，每一欄在防什麼

共用表的每一欄都對應一種三個月後會發生的誤讀，缺哪一欄就會出哪一種事。那場會議上，我把欄位一個一個攤開，請每個角色說出自己需要什麼，最後收斂成六欄：

1. 事件名稱：照命名規則，防止同一行為出現兩個名稱，例如 form_submit 與 submit_form 同時存在，報表加總時漏算一半。
2. 觸發條件：用一句中文寫清楚「在什麼情況下送出」，例如「表單通過前端驗證並收到伺服器成功回應後」。這欄防止把「按下送出」和「真的送出成功」混為一談，兩者在表單錯誤率高的頁面可能差兩到三成。
3. 漏斗階段：標示這個事件屬於認知、考慮、意向還是轉換。行銷看報表時需要知道哪些數字可以相加、哪些只能相比。
4. 關鍵參數：列出事件會帶的參數與可能的值，例如 service_type 只允許三種值。沒有這欄，同一參數會出現大小寫不一、中英混雜的值。
5. 負責人：寫一個人名（內部使用即可），當數字異常時知道找誰，而不是在群組裡問「有人知道嗎」。
6. 版本日期：記錄事件定義最後一次修改的日期與原因。這欄讓分析在看趨勢時，知道哪一天之後的數字不能直接和之前比。

其中最常被省略的是版本日期，也最致命。沒有它，任何一條折線圖上的轉折點都無法判斷是市場變化還是定義變化。

分析師插話：「那 GA4 裡的自訂維度誰來註冊？」

參數寫在共用表裡還不夠，必須在 GA4 註冊為自訂維度才會出現在報表中，這一步要指定由分析負責。會議中分析師提出這個問題時，工程師和行銷都以為是對方的事。結果是：工程師已經把 service_type 參數送進去半年，行銷在報表裡卻從來沒看過這個欄位，因為沒有人去後台註冊。

我們補上一條流程：工程師新增參數後，在共用表把該列標成黃色；分析在兩個工作天內完成自訂維度註冊並把顏色改回白色。這個動作花不到五分鐘，但它讓「資料有送」和「資料看得到」之間的落差被看見。也要提醒，自訂維度有數量上限，參數不能無限制地加，所以共用表裡還要有一欄隱性的判斷：這個參數真的會被用來做決策嗎？如果答案是否，就不要送。

行銷自己的功課：不要一次要二十個事件

行銷在事件命名上最大的責任，是把需求收斂到真正會影響決策的少數事件，而不是把所有能點的地方都埋起來。那次會議最後，行銷主管原本列了二十三個想追蹤的事件，我請她對每一個回答同一個問題：「如果這個數字下個月翻倍或腰斬，你會做什麼不一樣的決定？」答不出來的就先刪。

她一開始有點不服氣，說：「先埋起來以後總會用到。」工程師接著補了一句很實在的話：「每多一個事件，改版時我就要多測一次，測漏了你們的報表就會錯。」這句話讓行銷第一次意識到，事件不是免費的，每一個都有維護成本，而那個成本最後會以數據品質下降的形式回到行銷自己身上。

最後留下九個。這不是說其他十四個沒價值，而是團隊在初期沒有能力維護那麼多定義。事件數量一多，共用表就沒人更新，一旦共用表失真，大家又回到只問工程師的狀態。示意來說，一個五到十人的行銷團隊，核心事件維持在十個上下、每季檢討一次，是比較能長期維持的規模。

• 保留：會直接對應銷售線索或營收的事件，例如諮詢表單送出、報價單下載。
• 保留：能判斷內容是否有效的事件，例如案例頁閱讀到底部。
• 暫緩：純粹好奇、沒有對應行動的事件，例如頁首選單展開次數。
• 暫緩：可以用既有自動收集事件替代的行為，例如一般外部連結點擊。

會後一個月的驗收：三個問題問出真相

共用表有沒有真的被使用，一個月後用三個問題就能驗證。第一，隨機挑一個事件，請不是負責人的同事在五分鐘內說出它的觸發條件，答得出來代表表格可讀。第二，打開 GA4 即時報表，自己完成一次表單送出，確認事件名稱與參數值和表上寫的一致。第三，看版本日期欄最近一次更新是什麼時候，如果過去一個月有改版卻沒有任何更新，表示流程已經斷了。

那個案子在一個月後的檢查裡，第一題與第二題都過了，第三題卻發現有一次登陸頁改版沒有記錄。原因是那次改版由外包團隊負責，沒有人通知他們共用表的存在。我們後來把共用表連結放進外包合約的交付清單，才補上這個缺口。

什麼時候不必做到這麼細

如果網站一年只改版一次、只有一位兼任的行銷人員、核心轉換只有一個聯絡表單，那麼六欄共用表可能是過度設計。這種情況下，把事件名稱與觸發條件寫在一份簡單文件、每次改版時順手檢查即可。共用表的價值，出現在多人、多次改版、多個外包方同時碰網站的時候。

另外，事件命名規範解決的是「數字能不能被讀懂」，它不會告訴你網站策略對不對。銘望顧問所在企業顧問案裡常遇到的情況是，數據規範做得很整齊，但追蹤的指標本身與商業目標脫節。所以在定欄位之前，最好先確認團隊對「什麼算轉換」有一致的答案，否則再精準的命名，也只是把錯誤的東西量得很準。

← 回到新知列表