GA4 事件命名規範：四條原則、四層分類與既有帳戶的補救路徑

事件命名這件事，通常在專案初期被當成小事，由當時手邊在做的人隨手決定；等到半年後要做分析，才發現同一個按鈕在不同頁面被記成三個名字，而某個關鍵動作因為名稱裡有錯字，資料躺在報表最底下沒人看得懂。到了這個階段，重新命名意味著歷史資料斷裂，多數團隊會選擇忍耐，然後繼續忍耐下去。

好的命名規範不需要複雜，但需要在第一個事件被建立之前就存在。這篇提供一套可以直接沿用的規範、四條不能違反的原則、以及既有帳戶已經混亂時的補救路徑。

一、命名混亂的真實代價

第一個代價是無法聚合。當「加入購物車」被記成三個不同名稱時，你永遠得到三個各自偏低的數字，而不是一個正確的總數。分析者若不知道有三個版本，得到的結論會直接偏誤。

第二個代價是無法比較。跨頁面、跨活動、跨時期的比較都建立在命名一致之上，命名一旦漂移，趨勢圖上的斷點就無法區分是行為改變還是記錄方式改變。

第三個代價最容易被低估：交接成本。人員異動時，一套自我說明的命名可以讓接手者在一小時內看懂，而一套隨機命名需要原作者口頭解釋，而原作者通常已經離職了。

二、四條不能違反的原則

  1. 一律小寫加底線，不使用中文、空格、連字號或大小寫混用。這不是美感問題，許多分析工具對大小寫敏感，會把兩種寫法視為不同事件
  2. 動詞在前、對象在後，例如提交表單記為submit_form而非form_submit的反向寫法要全站一致，選定一種就不再更動
  3. 不把可變資訊寫進事件名稱，例如不要為每個商品建立一個事件，商品名應該放在參數裡
  4. 名稱要能在沒有上下文的情況下被理解，看到名稱就知道使用者做了什麼，不需要查文件

第三條特別重要。把可變資訊寫進名稱，是事件數量爆炸的主因，也會很快撞上平台的事件數量上限。判斷方式很簡單：如果一個名稱可能隨著商品、活動或頁面增加而無限增生，它就應該是參數而不是名稱。

三、一套可以直接沿用的分層命名

建議把事件分成四類，每一類用固定的動詞開頭，這樣在報表清單裡會自然依類別排在一起。

第一類：瀏覽與內容互動

使用view_開頭。例如檢視商品頁、檢視價格區塊、閱讀完整文章。參數帶入頁面類型、內容分類、捲動深度。這一類事件量最大，建議只記錄有分析價值的節點，不要每個區塊都記。

第二類：意圖表達

使用click_或select_開頭。例如點擊聯絡按鈕、選擇方案、展開常見問題。這一類是漏斗分析的骨幹，也是最需要命名一致的一類——同一個功能在不同頁面出現時必須同名，用參數區分位置。

第三類：流程進展

使用begin_、progress_、complete_三個階段動詞。例如開始填表、完成第一段、送出表單。三階段的好處是可以直接算出各段流失率，而不需要事後拼湊。長流程建議把progress_加上步驟編號參數，而不是建立多個事件。

第四類：結果與價值

使用generate_或purchase_開頭，並且務必帶入數值參數。這一類事件數量最少但最重要，建議設定為轉換並限制只有真正的商業結果才能列入。把所有點擊都設成轉換，是讓轉換這個詞失去意義最快的方式。

四、參數的設計原則

  • 每個事件至少帶三個參數：來源情境、對象識別、狀態或數值
  • 參數名稱同樣使用小寫底線，且跨事件重複使用相同參數名，避免同一概念有多個參數名
  • 需要跨事件比較的維度一定要成為參數，例如商品分類、方案等級、頁面類型
  • 避免把整段文字放進參數，長度限制會截斷，且無法有效分組
  • 敏感個資絕對不放進參數，包含姓名、電話、電子郵件、完整地址

最後一條不只是規範問題，也涉及個資保護與平台政策，違反可能導致資料被移除或帳戶受限，沒有任何分析價值值得承擔這個風險。

五、既有帳戶已經混亂時怎麼辦

不建議直接改名，因為歷史資料會斷。比較穩健的路徑分成四步：

  1. 第一步：完整匯出現有事件清單，標記每一個的每月觸發量與是否仍在使用
  2. 第二步：把仍在使用的事件對應到新規範，建立一張新舊對照表並公開給所有相關人員
  3. 第三步：新事件依規範建立並與舊事件並行記錄一段時間，通常一到兩個月，用來驗證兩者數量是否吻合
  4. 第四步：驗證通過後停止舊事件，並在報表工具裡建立合併規則，讓歷史資料仍可與新資料串接

並行期是這個流程的關鍵。跳過並行直接切換，一旦新事件有埋設錯誤，你會同時失去新舊兩份資料，而且往往要到月底看報表才會發現。

六、規範要活著才有用

文件寫好放在雲端資料夾，三個月後就沒有人記得它存在。要讓規範持續有效，需要三個機制：新增事件必須經過一個人審核，這個人不必是主管但必須固定；每季匯出一次事件清單檢查有無違規命名；以及把命名規範寫進與外部合作方的工作說明裡，因為新事件經常是外部團隊建立的。

命名規範的價值不會在建立當下顯現，它的回報全部發生在未來——某次分析可以直接得到答案而不用先清理資料，某位新同事第一週就能獨立看報表，某個問題在發生的當週就被發現而不是季底。這些看不見的節省加起來，遠超過當初多花的那幾個小時。

七、常見的六個命名錯誤與正確寫法

  • 把頁面名稱寫進事件名：不要用click_button_pricing_page，改成click_cta並以page_type參數區分
  • 用中文或拼音混寫：不要用anniu_click或按鈕點擊，一律使用英文小寫底線
  • 同義詞併存：submit、send、post三個動詞描述同一件事，選定一個並全站統一
  • 層級寫反：有些事件用對象在前有些用動詞在前，混用會讓報表排序完全失去意義
  • 把測試事件留在正式環境：test_、tmp_、new_開頭的事件如果沒有清理，半年後沒有人敢刪
  • 用編號取代語意：event_01到event_20這種命名等於把資料鎖在建立者的腦袋裡

這六個錯誤有一個共同點：它們在建立當下都非常方便，成本全部延後到未來才支付。命名規範的本質就是拿當下的一點麻煩，換未來的大量省事，而這個交換的匯率非常划算。

八、把規範落實到協作流程的三個做法

第一個做法是建立事件申請表。任何人要新增事件，先填一張三欄表格：想回答什麼問題、使用者做了什麼動作、預計用哪些參數區分。填不出第一欄的事件通常不需要存在，這張表本身就過濾掉相當比例的冗餘埋設。

第二個做法是在測試環境先跑一輪。新事件在正式上線前，先在測試資料流裡觸發十次，確認名稱、參數、數值都符合預期。這一步只需要十幾分鐘，卻能避免整個月的資料作廢。

第三個做法是把事件清單放進每月例會的固定議程。不需要每次都深入討論，只要花五分鐘掃過新增與異常，就能讓命名規範持續被看見。規範失效幾乎都不是因為有人刻意違反，而是因為太久沒有人提起它。

延伸閱讀

關於作者與審稿

冠誠數位行銷（GuanCheng Martech）的顧問團隊撰寫這篇文章。團隊累積 295 個專案，服務 308 家客戶，操作範圍包含 SEO 自然排名、AEO 答案引擎、GEO 與 LLMO 佈局、Google 與 Meta 廣告投放、電商維運與數據歸因分析。

文章裡的數字來自冠誠數位行銷實際經手的客戶帳戶與後台報表，客戶名稱與可識別資訊都已經移除。內容由負責該領域的冠誠顧問審稿後發佈，最後更新日期為 2026 年 9 月 5 日。讀完有問題，可以到冠誠數位行銷官方網站的預約諮詢頁面留下聯絡方式，我們會用你提供的時段回電。