GA4 事件命名規則：一份可以交接的命名表

接手別人設定的分析帳戶時，最痛苦的不是資料量太大，而是看到一串像這樣的事件名稱：button_click、Click_CTA、cta-click-2、送出表單、form_submit_new。

這五個名稱可能記錄的是同一件事，也可能不是，沒有人說得準，因為當初設定的人已經離職，也沒有留下文件。於是報表只能重做，過去一年的資料等於作廢。

命名規則的價值不在設定的當下，而在於半年後、換人之後，報表還看得懂。這篇提供一套可以直接沿用的做法。

四個命名原則

一、全部小寫、用底線分隔

不要混用大小寫，也不要混用底線與連字號。系統對大小寫的處理不一定一致，混用會產生看起來一樣但實際上分開統計的事件。

這是最基礎也最常被打破的原則。定下來之後，任何新增事件都不例外。

二、動詞在後，對象在前

採用「對象_動作」的順序，例如 quote_request、pricing_view、video_play。這樣排序時同一個對象的所有事件會排在一起，找起來快很多。

反過來用「動作_對象」也可以，重點是全站只能有一種順序。實務上前者的可讀性通常較好，因為報表使用者關心的是「哪個東西」多於「什麼動作」。

三、名稱描述行為，不描述位置

避免 header_button_click 這種以版面位置命名的方式。網站改版之後，那個按鈕可能移到別的地方，名稱就變成誤導。

改用行為描述，例如 contact_start。位置資訊放在參數裡，而不是名稱裡。

四、不要在名稱裡放版本或日期

像 form_submit_v2、signup_2026 這種名稱，短期看起來清楚，長期會累積成一堆無法比較的碎片。版本差異一樣放參數。

參數怎麼設計

事件名稱要少而穩定，變化的部分放進參數。這是整套設計的核心觀念。

舉例來說，不要為每一個表單各建一個事件，而是統一用 form_submit，再用參數區分是哪一份表單、位於哪一頁、屬於哪一類需求。

  • form_id：這份表單的識別名稱。
  • form_location：出現在哪個區塊，例如 hero、sidebar、footer。
  • form_type：詢問、報名、訂閱、下載。
  • page_group：頁面所屬的類別，例如 service、article、case。

這樣設計的好處是，之後新增一份表單不需要新增事件，只要多一個參數值，既有的所有報表自動涵蓋它。

要注意的是參數值也要有命名規則，同樣小寫、底線分隔、不要中英混用。參數值最容易失控，因為它常常由不同的人在不同時間填入。

一份可以交接的命名表

文件不需要複雜，一張試算表就夠。建議欄位如下。

  1. 事件名稱
  2. 中文說明：一句話講清楚它記錄什麼行為。
  3. 觸發條件：具體到「點擊哪個元素」或「捲動到哪個位置」。
  4. 參數清單：每個參數的名稱、可能的值、以及誰負責填。
  5. 建立日期與負責人
  6. 用在哪些報表：這一欄決定了它能不能被刪掉。

最後一欄常被省略，但它非常實用。半年後要清理事件時，沒有任何報表用到的事件就可以下架，有用到的則要先確認影響範圍。

既有專案怎麼整理

如果接手的帳戶已經一團亂，不要一次全部重來。建議的順序是這樣。

  1. 先盤點：把過去九十天有資料的事件全部列出來，標上觸發次數。
  2. 找出真正在用的：對照現有報表與看板，標記哪些事件有被引用。
  3. 凍結新增：在規則定案前，禁止新增任何事件，避免問題繼續擴大。
  4. 新舊並行：新的命名開始記錄，舊的保留三個月，確認新事件資料正常後再停用。
  5. 寫下文件：整理過程本身就是文件的內容，不要等做完才補寫。

第四步的並行期不能省。直接切換會造成報表出現斷層，之後做同期比較時會非常麻煩。

三個常見的錯誤

一、把所有點擊都記錄下來

事件不是愈多愈好。記錄一堆沒有人會看的事件，只會讓報表更難用，也讓真正重要的事件被淹沒。

判斷標準很簡單：如果說不出這個事件會回答什麼問題，就不要記。

二、命名規則只有一個人知道

規則寫在某位同事的筆記本裡，等於沒有規則。文件要放在團隊共用的位置，而且新人上手時要看過。

三、外部廠商各自設定

廣告代理商、網站廠商、分析顧問各自加自己的事件，是混亂的主要來源。解決方式是明確規定：任何新增事件都要先在命名表上登記，由單一窗口核准。

小結

事件命名的四個原則：小寫加底線、對象在前動作在後、描述行為不描述位置、版本資訊放參數。

事件名稱要少而穩定，變化的部分交給參數處理。文件用一張試算表維護，並且記錄每個事件被哪些報表使用。

這件事沒有立即的成效回報，但它決定了一年之後你的資料還能不能用。多數公司是在換人接手的那一刻，才發現當初省下的那兩小時有多昂貴。

哪些事件是多數網站真的需要的

如果從零開始設定，先做這一組就足以支撐大部分的決策，之後再依需求擴充。

  • form_submit：任何表單送出，用參數區分類型與位置。
  • form_start：使用者開始填寫但尚未送出，用來計算表單的中途放棄率。
  • contact_click：點擊電話、通訊軟體、電子郵件連結。
  • pricing_view：捲動到價格或報價說明區塊。
  • content_deep_read：文章捲動超過七成且停留超過一定秒數。
  • file_download：下載表單、型錄、範本。
  • outbound_click：點擊外部連結，例如社群或地圖。

這七個事件涵蓋了從閱讀、興趣、到接觸的完整路徑。多數公司真正會拿來做決策的資料，都在這七個裡面。

特別推薦 form_start 與 pricing_view 這兩個。前者能告訴你表單設計有沒有問題，後者能告訴你哪些內容真的把人帶到了價格討論的階段，兩者都是很難用其他方式推測的資訊。

命名規則之外還要記錄的事

除了事件本身，有兩份紀錄同樣重要，卻幾乎沒有公司在做。

第一是變更日誌。任何時候調整了事件、參數、或轉換設定，都要記下日期與內容。半年後看到某個指標在某一天突然變化，第一件要確認的就是那天有沒有動過設定，沒有日誌就只能猜。

第二是資料範圍說明。哪些流量被排除、內部人員的訪問有沒有過濾、測試環境的資料有沒有混進來。這些條件會直接影響數字的解讀，卻常常只存在於某個人的記憶裡。

這兩份紀錄加起來也不過一頁，但它們是報表可信度的基礎。沒有它們，任何漂亮的看板都只是好看而已。

小型網站要不要做到這個程度

五頁的形象網站當然不需要七個事件與完整的命名文件。但即使只記錄兩個事件，命名規則仍然值得先定好。

原因是網站幾乎不會停在五頁。兩年後多了部落格、多了報名頁、換了一次廠商，那時候再來整理，成本會高出許多。先定好規則，等於用十分鐘買一份保險。

最精簡的版本是：只記錄 form_submit 與 contact_click 兩個事件，各帶兩個參數，寫在一張紙上，放進網站交接文件夾。這樣就足夠了。

延伸閱讀

關於作者與審稿

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

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

參考資源：Google Reference