GA4 追蹤錯誤為什麼報表看不出來？
GA4 不會替錯誤的資料報錯。Md Zubayer Islam 在 2026 年 8 月 23 日的文章中稱，GA4 只照收到的資料記錄，referral 標頭被剝除或標籤觸發兩次時，它會把錯誤結果當成正確資料記下。
他在網站上自稱行銷歸因、轉換追蹤與伺服器端追蹤專家，文末也推銷他的稽核服務。他把多數壞資料歸到五個實作缺口：沒掛 UTM、沒開 Google Ads 自動標記、標籤太早觸發、購買事件沒帶 transaction ID、沒設定跨網域 linker。他說這五種問題每一種都會安靜地讓智慧出價與報表依賴的數字失真。
| 問題 | Islam 列出的原因 | 在報表上的樣子 |
|---|---|---|
| 直接流量過高 | 電子報連結沒掛 UTM、WhatsApp 或 Telegram 私訊分享、QR code 沒加追蹤參數 | 直接流量占比偏高，來源資訊實際上已遺失 |
| Google Ads 被算成自然流量 | 自動標記沒開、手動 UTM 覆蓋 GCLID、GCLID 在轉址時遺失 | 付費點擊顯示為 google / organic，而非 google / cpc |
| 來源顯示 not set 或未歸類 | 標籤在頁面載入完成前觸發，或轉址先剝除了 referral 標頭 | 有流量進來，卻沒有來源資料 |
| 重複交易 | 顧客重新整理感謝頁、同一頁有多個 purchase 標籤 | 購買次數與營收高於實際 |
| 跨網域追蹤斷裂 | 結帳移到另一個網域，卻沒設好跨網域追蹤 | 工作階段重置，歸因退回 referral 或直接流量 |
Islam 稱，GA4 會自動排除 24 小時內重複的相同 transaction ID，但前提是每一筆 purchase 事件都帶了這個欄位，而且值一致。
跨網域的部分，他的修正步驟之一是在 Google Tag Manager 設定 linker，讓 _gl 參數在網域之間自動傳遞。他也建議把訪客在轉換過程中會經過的每個網域列成清單，包括到達頁、結帳頁、預約工具與金流平台，新增網域時就更新設定、重測整條路徑。
要怎麼知道問題出現了，他在同一篇文章裡給了兩種說法。他在正文建議每月用三個基準稽核：直接流量低於 15%、未歸類流量低於 5%、GA4 營收與商店或 CRM 相差在 2% 以內。同一篇文章的常見問題段落又稱，沒有適用所有網站的通用百分比，應該以自己網站的歷史基線觀察突增。
我們的判斷是，這五種問題都和上線前沒寫下來的設定有關：哪些連結要帶 UTM、purchase 要帶哪些參數、結帳會經過哪些網域。把這些寫下來的文件，就是下一節的事件追蹤計畫。
事件追蹤計畫要寫進哪些欄位
字節跳動數據平台在 2022 年 9 月 15 日發表於博客園的文章，把埋點設計文件定義為給開發人員的需求說明書：讓開發人員知道在什麼情況下採集哪些埋點，以及屬性參數的型別與取值。
事件追蹤計畫記錄網站要收哪些使用者行為，以及每個行為要帶哪些資料。簡中技術圈常稱為「埋點設計文件」。
這篇文章以火山引擎（字節跳動對外提供數據產品與服務的品牌）自家的增長分析產品為例，文末也導向該產品。它列出的事件表要素如下。
| 欄位 | 文章的說明 |
|---|---|
| 序號 | 每個事件一個固定編號，唯一且不可修改 |
| 事件名稱 | 中英文一一對應，英文名用統一規範 |
| 事件屬性名稱 | 中英文一一對應 |
| 屬性類型 | 例如布林值 |
| 屬性值含義或示例 | 讓研發人員看懂欄位意思與特殊情況 |
| 觸發時機 | 每個事件何時觸發；有多個入口就逐一列出 |
| 埋點形式 | 前端或後端 |
| 備註 | 排期優先級與其他特殊情況 |
命名規則是最容易出現分歧的地方。字節跳動數據平台的文章稱，事件英文名可以用底線（regist_submit）或駝峰（registSubmit），重點是統一採用動詞_名詞或名詞_動詞。GA4 與 GTM 教學網站 Analytics Mania 的 Julius Fedorovicius 則稱，GA4 事件名稱的最佳做法是只用小寫的 snake_case。兩邊都同意的是大小寫敏感：前者提醒傳了 Name 就不要再傳 name，Fedorovicius 也寫明 GA4 參數名稱嚴格區分大小寫。
Fedorovicius 還提到，GA4 事件名稱上限 40 個字元，超過就無法標記為關鍵事件。他建議命名前先查自動收集事件、加強型評估事件與推薦事件的命名慣例，都不符合才自己取名。
「埋點形式」這一欄也有講究。字節跳動數據平台的文章舉註冊為例：前端在送出時觸發，無法確定註冊成功或失敗；一般情況下，產品購買、註冊成功這類核心業務流程事件建議由後端埋點，以保證資料準確。
規模大的公司把清單管得更嚴。火山引擎數智平台的文章稱，埋點在字節跳動廣泛使用，峰值流量超過每秒 1 億。該公司加上上報管控後，埋點要先登記到「允許上報」清單，只有清單內的埋點才能正常上報；治理順序是先控制新增埋點，再處理既有資料。
GA4 自訂參數沒登錄就進不了報表
參數送進 GA4 不等於報表看得到。Julius Fedorovicius 在 2026 年 8 月 26 日更新的 GA4 自訂事件教學中寫道，自訂參數只會出現在即時報告與 DebugView，除非登錄成自訂維度。
Even though you will see your custom parameters in Real-time reports and DebugView in GA4, you will not be able to see them in other GA4 reports. Unless you register those parameters as custom dimensions in Google Analytics.
中文意思是：自訂參數在即時報告與 DebugView 看得到，在其他 GA4 報告看不到，除非登錄成自訂維度。為出海品牌提供 Google 數據工具導入與分析顧問的觸脈諮詢，在 2024 年 6 月 4 日的文章也稱，要在 GA4 查看和使用事件參數，必須在資源中登錄自訂維度或自訂指標。
時間點也有影響。Fedorovicius 稱，GA4 不會把自訂維度的定義回溯套用到登錄之前收到的事件；他把「太晚登錄」和「GTM 標籤與 GA4 管理介面的參數名稱不一致」都列為自訂維度顯示 (not set) 的常見原因。標籤發布後，標準報表與探索報告還需要 24 到 48 小時才會完整處理自訂參數值。
| 項目 | 說法 | 出處 |
|---|---|---|
| 每個事件的參數數量 | 最多 25 個；作者依實驗稱 page_location 等自動收集參數也算在內 | Analytics Mania |
| 登錄數量 | 每個資源最多 50 個自訂維度、50 個自訂指標 | Analytics Mania |
| 維度或指標 | 送文字登錄成自訂維度；送要計算的數字登錄成自訂指標 | Analytics Mania |
| 範圍 | 事件、使用者或商品 | 觸脈諮詢 |
我們的判斷是，規格表上的「屬性類型」欄位，同時決定了上線當天要在 GA4 登錄成自訂維度還是自訂指標。表上先寫清楚，登錄這一步就不會漏，也不會等到資料進來一段時間後才補登錄。
如何把事件追蹤計畫對上行銷漏斗
字節跳動數據平台的文章稱，埋點需求來自業務需求，不能為了埋點而埋點，也不要一味追求多而全。它建議先從要觀察的指標出發，再把指標拆成事件。
該文以支付轉換率為例：先把它定義為應用啟動、進入商品列表頁、瀏覽商品詳情頁、提交訂單、支付成功這一串的轉化，再把每個行為抽象成一個事件，然後補上商品價格、店鋪、商品分類等屬性，方便之後拆維度看。
這套由行銷漏斗往回推事件的做法，到了 GA4 還有一關。Fedorovicius 稱，自訂參數要用在漏斗報表、探索報告或標準報表卡片，都必須先加為自訂定義。也就是說，漏斗要切的維度，得在上一節的登錄步驟就處理好。
驗收方面，Fedorovicius 稱開啟 GTM 預覽模式會自動把 debug_mode 設為 true，事件就會出現在 GA4 的 DebugView。觸脈諮詢也建議實施參數後用 DebugView 驗證參數是否照預期收到。字節跳動數據平台的文章則建議在技術驗收之前，先加一道業務驗收，讓需求方在上線前發現不符。
規格表上線後還要維護。字節跳動數據平台建議定期清理近半年沒有資料進來或沒被查詢的事件，經業務確認後隱藏或停用；LoisDailyAI 的模板也把依業務與技術變化定期迭代列為維護項目。Islam 則提醒，新的轉址、外掛更新、網域變更或 GTM 修改，都可能讓同樣的問題安靜地再出現，所以他建議每月重跑同一份稽核。
銷波快觀點：設定改完要回讀，沒報錯不代表對
我們上個月查一個客戶的 Meta 廣告帳號，撈出兩顆同名像素。活動實際掛的那顆在 2016 年建立，當天還在觸發，Purchase 事件的 EMQ 評分是 9.2／10。另一顆在 2026 年 9 月 7 日新建，最後觸發時間顯示 1969-12-31，也就是從來沒收過任何事件。
那次掛對了，但我們很清楚那是運氣。設定選單裡有兩個一模一樣的選項，選錯不會跳警告，也不會中斷。報表只會安靜地印出一整排 0，而 0 在轉換活動剛上線的前幾天看起來完全正常。我們現在的做法只有一條：改完轉換設定，就回頭讀 adset 掛的 pixel_id，確認是哪一顆。
這跟前面 GA4 的自訂維度是同一種形狀。它不是程式錯誤，也不是資料錯誤，是人機介面讓錯的選項看起來和對的一樣。事件追蹤計畫在這裡的角色，就是給回讀一個比對基準：表上寫的是哪顆像素、哪個事件、哪些參數，回讀時就照表核對。
Meta 那邊的對應做法是雙軌追蹤。Pixel 從瀏覽器端收行為，Conversions API 從伺服器端送含顧客識別資料的事件。我們把 CAPI 看成再行銷的基礎建設，EMQ 分數決定廣告系統能把受眾切多細。
第三方 Cookie 越來越靠不住，第一方資料的收集能力就成了門檻。我們一直建議行銷人提早評估這件事，而第一方資料要收得乾淨，前提就是事件規格先寫清楚。
我們自己也踩過「看起來正常」的坑。舊一批文章的目標關鍵字靠語意分析挑選。查 GSC 才發現其中一篇鎖定的「情感行銷」一次曝光都沒有，真正在排名的是 formhd。猜的設定不回讀，就會一直錯下去。追蹤設定是同一回事。
結論：先寫事件追蹤計畫，再打開 GTM
Islam 稱，GA4 只照收到的資料記錄，五種常見的設定缺口都會安靜地讓數字失真。字節跳動數據平台把埋點設計文件定義為給開發人員的需求說明書，事件名稱、屬性類型、觸發時機與埋點形式都要寫進去。Fedorovicius 則提醒，自訂參數沒登錄成自訂維度，標準報告與探索報告就看不到，而且登錄之前的資料不會回溯。
我們的判斷是，把這三件事放在同一張規格表上：先寫事件與參數，再依型別登錄維度或指標，上線後用 DebugView 照表驗收。
喜歡這篇？讓行銷變好懂，訂閱銷波快。
資料來源
- GA4 Data Quality Issues: Fix 5 Common Tracking Problems（Md Zubayer Islam）zubayerislam.com
- How to Track Custom Events with Google Analytics 4（Analytics Mania）analyticsmania.com
- 如何設計企業級數據埋點採集方案（字節跳動數據平台）cnblogs.com
- 一文讀懂字節跳動埋點數據治理（火山引擎數智平台 VeDI）developer.volcengine.com
- 埋點方案模版，含完整示例（CSDN，LoisDailyAI）blog.csdn.net
- 一文了解 Google Analytics 4 事件參數配置及最佳實踐（觸脈諮詢）truemetrics.cn
