給產品與數據負責人：建立可執行的 GA4 事件命名規範

給產品與數據負責人：建立可執行的 GA4 事件命名規範

可以。在建立第一個事件前，訂好一致且簡明的命名規範，就能避免後續資料斷裂與分析錯誤，並節省未來大量分析成本。

顧問：我們先從最常見的問題開始吧。業主：為什麼事件命名會變得那麼重要？顧問：因為命名決定你能否聚合、比較與移交資料。

為什麼命名不只是一個技術細節（真實代價）

顧問常見的說法和三項主要代價：

  1. 無法正確聚合數據
    – 同一動作被三個不同名稱記錄，會得到三組偏低數據，導致誤判成效或轉換率偏低。這不是理論，而是實務常見情況。
  2. 無法可靠比較趨勢
    – 命名漂移會讓時間序列圖出現斷點，分析者無法判斷是使用者行為改變還是記錄方式改變。
  3. 交接成本高
    – 沒有自我說明的命名，接手者需要原作者口頭說明；若原作者離職，理解與維運成本成倍增加。

限制說明：以上三點為普遍觀察與顧問經驗總結，具體數字請參見本文資料邊界。

四條不能違反的命名原則（簡潔可執行）

顧問：把規範縮成四條，團隊才會用得住。

  1. 一律小寫、底線分隔
    – 不使用中文、空格、連字號或混合大小寫。多數分析工具對大小寫敏感，會把不同寫法視為不同事件。
  2. 動詞在前、對象在後
    – 例如 submit_form，而非 form_submit。反向寫法可以造成報表排序與搜尋困難；選定一種風格後不要更動。
  3. 不把可變資訊放事件名稱
    – 商品名稱、活動代碼、頁面 ID 等會爆增事件種類的資訊，應作為參數而非名稱。判斷準則：若名稱會隨商品或頁面無限增加，就應放參數。
  4. 名稱要自說自話
    – 看到名稱能直接理解使用者做了什麼，不需要查語意文件或額外上下文。

這四條看似簡單，但一致執行可以直接避免大量後續清理工作。

四層分類與可直接沿用的範例（讓事件在報表中自然分群）

建議將事件分成四類，每類用固定動詞開頭，方便在報表中視覺聚合：

  • 第一類：瀏覽與內容互動（view_ 開頭）
  • 範例：view_product、view_price_block、view_article
  • 參數：page_type、content_category、scroll_depth

  • 實務建議：這類事件量最大，只記錄有分析價值的節點，不必把每個 UI 區塊都記錄。

  • 第二類：意圖表達（click_ 或 select_ 開頭）

  • 範例：click_cta、click_contact、select_plan
  • 參數：page_type、position、element_id

  • 實務建議：同一功能在不同頁面出現時必須同名，位置以參數區分，利於漏斗分析。

  • 第三類：流程進展（begin_、progress_、complete_ 三階段）

  • 範例：begin_checkout、progress_signup_step、complete_form
  • 參數：step_number（若長流程）、flow_id

  • 實務建議：三階段能直接計算每段流失率；長流程以 step_number 作為參數，而非建立多個事件。

  • 第四類：結果與價值（generate_ 或 purchase_ 開頭）

  • 範例：generate_lead、purchase_order
  • 參數：value、currency、product_id
  • 實務建議：僅把真正商業結果設為轉換；不要把所有點擊都標成轉換，會降低轉換指標的意義。

表格提示（文字版）：
– 開頭動詞：view_, click_/select_, begin_/progress_/complete_, generate_/purchase_
– 主要參數：page_type、object_id、value、step_number

參數的設計原則（事件以外的資料要怎麼帶）

每個事件至少應包含三個參數（範例命名皆採小寫底線）：

  1. 來源情境（例：page_type、referrer）
  2. 對象識別（例：product_id、plan_id）
  3. 狀態或數值（例：status、value）

其他要點：
– 參數名稱跨事件需一致，避免同一概念用多個名稱。
– 需要跨事件比較的維度一定要是參數（如商品分類、方案等級、頁面類型）。
– 避免把整段文字放入參數，長度限制會被截斷且不利分群。
– 敏感個資（姓名、電話、email、完整地址）絕對不可放入參數；這牽涉平台政策與個資保護，違規可能導致資料被移除或帳戶受限。

既有帳戶混亂時的補救路徑（四步並行期重點）

當事件已混亂，直接改名會造成歷史資料斷裂；顧問建議採穩健四步走：

步驟 1：完整匯出現有事件清單
– 標記每個事件的月觸發量與是否仍在使用。

步驟 2：對應到新規範
– 建立新舊對照表（mapping），並公開給所有相關人員。

步驟 3：並行記錄驗證期
– 新事件依規範建立，與舊事件並行記錄一段時間（通常一到兩個月），驗證數量是否吻合。

步驟 4：停止舊事件並建立報表合併規則
– 驗證通過後停止舊事件，並在報表工具中設定合併（mapping）規則，確保歷史資料可串接。

關鍵提醒：並行期不可省略。若直接切換，一旦新事件埋設錯誤，可能同時失去新舊資料，且通常要到月底或對帳週期才會發現問題。

把規範變成團隊習慣的三個做法

顧問常推行以下三個機制，能讓規範「活著」而非文件孤兒：

  1. 事件申請表（門檻與審核）
    – 申請表三欄：想回答的問題、使用者做了什麼、預計參數。若填不出第一欄，通常不應新增事件。
    – 審核人：指定一位固定負責人（不必為主管），負責核准新增事件。

  2. 測試環境驗證（快速檢驗）
    – 新事件在正式上線前於測試資料流觸發十次，確認名稱、參數與數值符合預期即可。

  3. 月度巡檢入例會
    – 把事件清單放進每月例會議程，花五分鐘掃過新增與異常，維持規範的能見度。

這三個做法可以把「規範建立」變成「規範執行」。

常見六個命名錯誤與正確寫法（實務對照）

  1. 把頁面名稱寫進事件名
    – 錯：click_button_pricing_page → 正：click_cta（page_type 作為參數）
  2. 使用中文或拼音混寫
    – 錯：anniu_click 或 按鈕點擊 → 正：click_button
  3. 同義詞併存
    – 錯：同一動作有人用 submit、send、post → 正：選一個動詞並全站統一
  4. 層級寫反
    – 錯：有些事件動詞在前、有些在後，造成報表排序混亂 → 正：動詞在前、對象在後
  5. 把測試事件留在正式環境
    – 錯：test_、tmp_、new_ 開頭的事件未清理 → 正：測試資料只留在測試環境
  6. 用編號取代語意
    – 錯：event_01 到 event_20 → 正：以描述性名稱命名，保留編號僅作內部參考

這些錯誤的共同點是：當下方便但未來成本高。命名規範的投資回報會在未來陸續顯現。

實務操作清單（上線前與維運檢查表）

上線前（短清單）：
– 是否有事件申請表？（含分析問題）
– 名稱是否小寫底線？
– 是否有至少三個參數（來源、對象、數值/狀態）？
– 在測試流觸發至少 10 次並確認資料一致？

維運檢查（每月）：
– 匯出事件清單並檢視新增項目
– 檢查是否有以商品或頁面為名稱的事件（應改為參數）
– 檢視高頻事件是否命名一致

範例事件申請流程：填表 → 審核 → 在測試流驗證 10 次 → 正式上線並監控 1–2 個月 → 停用舊事件並合併歷史資料。

限制與例外情況

  • 例外情況：若短期 A/B 測試需區分埋點，可在參數中帶入 test_variant，而非建立臨時事件。
  • 平台限制：不同平台（第三方 SDK、Tag 管理工具）在事件名稱長度或字元上可能有限制，命名規範應納入該平台限制。
  • 合規限制：敏感個資不可放入事件或參數，需遵守資料保護與平台政策。

顧問提醒：所有具體平台上限或法律合規細節需由執行或法務確認，本文提供操作式規範與流程框架。

FAQ（本文真實回答的問題）

Q1：我可以直接把舊事件改名來修正錯誤嗎？
A1：不建議。直接改名會造成歷史資料斷裂。建議採用新舊並行記錄並行驗證 1–2 個月，再停止舊事件並在報表工具建立合併規則。

Q2：事件名稱長度或字元有限制怎麼辦？
A2：在設計命名規範時，把目標平台的限制納入一條原則，必要時把冗長資訊移到參數，或使用約定縮寫但需有對照表。

Q3：敏感個資能放在哪裡？
A3：敏感個資（姓名、電話、email、完整地址）絕對不可放在事件或參數內。若需識別使用者，改用已去識別化或平台允許的識別碼，並經法務/資訊安全確認。

Q4：誰應該負責審核新增事件？
A4：指定一位固定的審核人即可，這人不必是主管但需具備命名規範與產品/分析情境的知識，負責核准與維護 mapping 表。

Q5：規範要多久檢視一次？
A5：建議每季檢視一次事件清單，並在月例會快速掃過新增與異常，保持能見度。

下一步（內連資源）

  • 若需外部協助檢視現有事件清單或導入流程，可參考我們的服務頁面：顧問與執行服務 /services/。
  • 若想了解如何把 AI 或規則化決策加入事件命名審核流程，可參考 AI 決策方案 /ai-decision-pod/。
  • 需要案例參考時，請查看我們的案例集 /cases/，理解同類問題的處理方式。
  • 想建立事件申請表或預約諮詢，可使用我們的表單 /contact/ 提交需求。
  • 對常見執行與工具問題的快速答覆，請參考常見問題 /faq/。
  • 若需了解團隊與專業背景，可參考關於我們 /about/。

本文資料邊界：文章中提出的流程、原則與範例來自顧問實務經驗與原始說明；若需具體數字或樣本範圍（如每月觸發量標準、並行驗證門檻），請由執行團隊在帳戶層級驗證並制定閾值。

延伸閱讀：

參考資源：Google Analytics