快速結論：多數人的事件設計順序是反的——先看「這個按鈕能不能埋」，能埋的都埋起來。正確的順序要整個倒過來：先想清楚你要回答什麼商業問題 → 再決定要看什麼行為 → 才把那個行為設計成事件 → 最後才碰工具。 一句話記住：沒有事件設計，數據只是流水帳。 你埋的每一筆，要嘛是回答問題的證據，要嘛是沒人看的雜訊。
這篇寫給 GA4 裡埋了一堆事件、真要用的時候卻一個都對不上想問的問題的你。
先招認我的黑歷史。早年我信奉「先把能埋的都埋起來，數據以後再說」，於是我的 GA4 裡躺了快兩百個事件——點擊、捲動，連滑鼠移過去都記。感覺很勤勞，對吧？結果某天老闆隨口問了一個超簡單的問題：「我們的結帳流程，大家都卡在哪一步？」我打開後台，兩百個事件裡，居然湊不出一組能乾淨回答這件事的（那一刻我才懂，埋得多跟埋得對，是兩件完全不同的事…）。從那次之後，我埋任何一個事件之前，都先強迫自己回答一句話：我埋這個，是為了回答什麼問題？
為什麼多數人的事件設計是反的
目的：先講清楚問題出在哪。多數人的順序是「工具驅動」——打開 GTM，看到可以埋點擊、可以埋捲動、可以埋停留，於是把能埋的都埋了。這個順序背後藏著一個假設：資料先收著，總有一天用得到。
有趣的是，這個假設，你在做生意的別的地方從來不信。**平移一下你已有的生意常識：**你不會沒想好要看什麼，就叫下屬生一份塞滿數字的報表——那種報表你自己都不會翻第二頁。你會先問「我要做什麼決策」，再回頭要對應的數字。埋事件是一模一樣的道理，只是換到數位場景，大家就忘了。
效果：順序反了的代價，是你會得到一個「什麼都有、什麼都用不上」的資料庫。事件多到你自己都不記得哪個是哪個，命名一團亂，真要回答一個具體問題時，才發現不是漏埋了關鍵那一步、就是埋了但參數不對。收集的動作很勤，能回答的問題卻很少。 我那兩百個事件就是活生生的展示品。
極限：這裡要誠實——反過來「先想問題」也不代表你一開始就想得到所有問題。商業問題會長、會變，事件設計本來就是要迭代的。重點也從來不在一次想齊，而在每一個事件都有一個當下要回答的問題。想不到問題的事件，就先別埋，真的。
正確的順序：先問題、後事件（四步）
把順序倒過來，事件設計其實就四步。平移你熟悉的「先有問題、才要數字」的決策習慣，落實到追蹤上：
- 先定商業問題：你想做什麼決策？（例：該不該改結帳流程？該加碼哪個廣告受眾？）
- 再定關鍵行為：什麼行為能回答這個問題？（想知道結帳卡在哪，就要看「進入結帳 → 填資料 → 付款」每一步的人數）
- 才設計成事件：把那個關鍵行為，變成一個可記錄的事件——新增的課題在這裡：一個好事件不只是「有沒有發生」，還要帶對「參數」（下一節細講）。
- 最後才碰工具：確定要追什麼、怎麼記，才打開 GTM 去實作。工具是最後一步，不是第一步。
目的：這個順序保證你埋的每一個事件，都掛在一個真實的商業問題上。
效果：你的 GA4 會從「兩百個沒人看的事件」，瘦身成「二十個每個都能回答問題的事件」——少而精，判讀時一目了然。
極限：這套順序治得了「埋錯方向」，治不了「問錯問題」。如果你的商業問題本身是虛的（老闆要一個看起來很忙的儀表板…），再好的事件設計也只是把虛的問題執行得很漂亮。
一個好事件長什麼樣：行為 ＋ 參數
目的：光記「事件發生了」還不夠。平移生意常識：你記一筆銷貨，不會只記「有人買了」，你會記金額、品項、數量、誰買的——那些「附帶資訊」才讓這筆紀錄有用。事件也一樣，新增的數位課題就是：一個好事件要帶對「參數」（parameter，事件的附帶資訊）。
舉個例。一個「加入購物車」事件，光知道「有人加購」用處有限；如果它帶上「哪個商品、什麼價位、從哪個頁面來」這些參數，你才回答得了「哪類商品最容易被加購卻不結帳」這種真正有決策價值的問題。
效果：帶對參數的事件，讓你能從「發生幾次」升級到「發生在誰身上、什麼情況」——這也是為什麼事件設計是名單分層的上游。名單要能分「高價值、高轉換、沉睡客」，分層的條件本來就來自這些事件參數（這條互鎖，在〈名單資產矩陣〉展開）。**極限：**參數也別貪多。帶一堆沒人會用的參數，跟埋一堆沒問題的事件是同一種病——回到第一步，每個參數也該對應一個你想回答的問題。
這條原則，之後你會一直用到
事件設計不是 C4 這個 cluster 的內部細節，它是好幾條線的共同源頭：GTM 要送什麼（〈GTM 事件能達到什麼效果〉）、GA4 記錄的是什麼（〈GA4 到底在記錄什麼〉）、名單怎麼分層（〈名單資產矩陣〉）——全部往回追，都追到「你當初把哪些問題設計成了事件」。往上，這一步接的是〈GTM 的存在理由〉——先有 GTM 才好把事件送出去；往外，它是〈數位行銷素養全地圖〉裡的一格。所以這一篇雖然不教你按哪個鈕，卻是整套追蹤裡最該先想清楚的一課。
老闆／廠商遲早會問的三題
一、我們每一個事件，當初是為了回答什麼商業問題設計的？（答不出來的，多半是「先埋著再說」的雜訊，該清）
二、關鍵行為（結帳每一步、關鍵加購）有沒有帶對參數？（只記「有沒有發生」，回答不了「發生在誰身上」）
三、我們是先想問題才埋，還是打開工具看到什麼就埋什麼？（順序反了，資料庫會胖、判讀會瞎）
三題答得清楚，你的追蹤才配得上「設計」這兩個字。接手一個舊網站要體檢事件設計，清單在〈追蹤健檢：接手一個網站，先看這 7 件事〉。
常見問題（FAQ）
事件是不是埋越多越好？
剛好相反。埋越多、又沒對應問題，只會讓你的資料庫又胖又亂、判讀更難。少而精——每個事件都能回答一個問題——遠勝多而雜。
我已經埋了一堆沒在用的事件，怎麼辦？
不用急著全砍。用「這個事件在回答什麼問題」去篩：答得出來的留、答不出來的標記起來、確定沒用的再清。清理的原則跟設計的原則是同一條。
這跟 GA4、GTM 的關係是什麼？
事件設計是上游的思考，GTM 是下游的實作。先用這篇的順序想清楚要追什麼，再去 GTM 裡把它做出來、送進 GA4 判讀。其實不只 GA4、GTM——送進 CAPI 的也是同一批事件（見〈你的 Pixel 為什麼失準〉），事件設計是它們共同的上游。順序別顛倒——工具永遠是最後一步。分工全圖在〈數據追蹤基礎建設全圖〉。
沒有工程背景，我也能做事件設計嗎？
能，而且這一步恰恰不是工程工作，是商業思考。決定「要回答什麼問題、追什麼行為」的人，該是懂生意的你；工程師負責把你設計好的事件實作出來。想清楚要什麼，是你的活。
「事件設計的反向順序」與定律「沒有事件設計，數據只是流水帳」，是本站「數位行銷素養」體系的核心方法之一，將隨各分析工具的事件模型更新持續迭代（建議每半年回訪本文）。想知道你的事件設計哪裡在收雜訊？幫你準備：數位廣告健檢表單傳送門。