我們建議的起點是下一筆測試訂單。Tagada 建議先在 GTM 預覽模式確認代碼只觸發一次、items 陣列裡的商品和畫面一致；Spilno Agency 則建議每個新事件都先進 DebugView，看它有沒有觸發、帶了哪些參數、有沒有重複。
電商漏斗事件：purchase 有追蹤的占 48%，結帳中段只剩兩成多
Tagada 引述 Digital Applied 的實作分析：有追蹤 purchase 的電商 GA4 實作占 48%，add_to_cart 44%、view_item 41%、begin_checkout 37%、add_payment_info 28%、add_shipping_info 26%。
Tagada 引述 Google 的 GA4 電商文件，電商模型圍繞 view_item、add_to_cart、begin_checkout、add_payment_info、purchase、refund 等事件。Spilno Agency 列出的線上商店標準漏斗，則依序是 view_item、add_to_cart、begin_checkout、add_shipping_info、add_payment_info、purchase。
Tagada 寫到，Universal Analytics 在 2023 年 7 月 1 日停止處理新資料，商家只能轉用 GA4 的事件模型；它也觀察到，很多團隊搬了資源，卻從沒把實作做完。
漏斗中段的事件有沒有收，會影響怎麼讀數字。該站的說法是，view_item 到 add_to_cart 之間的落差可能是真實的購買行為；如果結帳之後突然斷掉，後台訂單卻照常進來，比較可能是實作失效，不是顧客放棄。它也稱，事件序列完整，能提升 Google Ads 最佳化、排除已購買者、再行銷受眾與顧客終身價值分析的品質。
Spilno Agency 把 GA4 事件分成四類。自動收集事件不需設定就會收，例如 session_start、first_visit、page_view；增強型衡量事件在設定裡打開一個開關就會收，涵蓋捲動、外連點擊、站內搜尋、YouTube 影片互動與檔案下載；推薦事件是 Google 提供的標準事件名稱，要自己用 GTM 或程式碼實作；自訂事件則是為特定業務需求自行定義的事件。
電商漏斗事件屬於推薦事件。Spilno Agency 稱，照 Google 的命名慣例送資料，可以解鎖額外的內建報表；GA小站也寫到，推薦事件是 Google 預先定義的一套事件名稱與參數。znbo 則提醒，GA4 預設會記錄部分事件，但加入購物車、結帳這類關鍵電商事件需要手動設定。稽核、追蹤除錯與歸因的其他整理，收在行銷數據分析分類頁。
名稱對了，參數也要齊。Tagada 引述 Google 的 purchase 事件說明：缺少必要的電商參數，事件可能被當成自訂事件，也不會出現在購買報表裡。
items 陣列沒放對，商品報告就用不了
Tagada 引述 Google 事件參考文件：每個商品物件必須帶 item_id 或 item_name 其中之一，沒帶 quantity 時預設為 1。它的表格把 purchase 的必要參數列為 transaction_id、value、currency、items。
該站的分法是，商品識別與價格、數量放在 items 陣列裡，交易、促銷與列表位置等脈絡放在事件層。它整理出三種常見失效：
- 缺商品資料：purchase 帶了 transaction_id 與 value，卻沒有有效的 items 陣列，收益可能在訂單層看得到，商品報告卻無法使用。
- 放錯層：item_id、price 或 quantity 被放在 items 旁邊，而不是放進每個商品物件裡，GA4 收得到資料，卻無法正確對應商品屬性。
- 去重複沒做好：感謝頁重新整理、金流重試，或前端與伺服器端同時實作，都可能讓同一筆 purchase 送出不只一次。
“Treat the purchase payload as a financial data contract, not as a marketing tag.”
把 purchase 送出的資料當成財務資料合約，而不是一個行銷代碼。
欄位格式也有講究。Tagada 建議確認 currency 用的是 GA4 採用的三碼 ISO 幣別格式，value、price、quantity 是數值，不是格式化後的顯示文字。Spilno Agency 則稱，電商事件缺 currency 欄位時，GA4 報表不會顯示金額。
transaction_id 在廣告端也派得上用場。Stape 在伺服器端 GTM 設定 Google Ads 轉換代碼的步驟裡，建議把 Transaction ID 對應到唯一的訂單編號變數，以避免重複轉換。
Tagada 建議的檢查方式：在 GTM 預覽模式確認 items 陣列裡的商品和畫面上顯示的一致，而不只看事件名稱有沒有出現。
事件命名：大小寫和空格都會讓事件分家
Spilno Agency 的事件設定指南要求一律用 snake_case，並稱 FormSubmit 這種 camelCase 寫法 GA4 不支援，submit form services 這種帶空格的名稱是 bug 的來源。
該公司也寫到，GA4 區分大小寫，Purchase 和 purchase 是兩個不同的事件。NiceLookingData 的稽核清單給的改法相同：事件名稱用小寫、底線、不留空格。
| 寫法 | Spilno Agency 的評語 |
|---|---|
| form_submit_services_ua | 可行：看得出是表單、服務頁、語言 |
| newsletter_signup | 可行：動作加對象 |
| FormSubmit | 不可行：camelCase，GA4 不支援 |
| submit form services | 不可行：事件名稱帶空格是 bug 來源 |
Spilno Agency 在封存過時事件的規則裡寫到，GA4 介面無法刪除事件，只能篩選或忽略；它建議用 Google 試算表記錄每個事件的名稱、觸發條件、觸發位置、參數、設定人、日期與狀態，經手的人不只一位時更需要。
後台名稱也改過。該公司稱，Google 已把 GA4 的「轉換」改名為「關鍵事件」，用意是和 Google Ads 的轉換區隔開來。
上線前用 GTM 預覽和 DebugView 驗一次
Spilno Agency 稱，GA4 標準報表有 24 到 48 小時延遲，即時報表與 DebugView 則會立即出現事件；Tagada 則提醒，觸發測試事件到在 DebugView 看見之間有短暫延遲，剛送出沒看到不代表代碼失效。
Tagada 與 Spilno Agency 建議的驗證步驟，整理如下：
- 開 GTM 預覽模式，確認預期的事件有出現、代碼只觸發一次、變數取到當下的值，items 陣列裡的商品和畫面一致（Tagada）
- 進 DebugView，看事件有沒有觸發、帶了哪些參數、有沒有重複（Spilno Agency）
- 用瀏覽器開發者工具看網路請求有沒有送出、巢狀參數有沒有完整保留（Tagada）
- 重新整理感謝頁、重複金流返回流程，確認同一筆交易不會產生重複的 purchase（Tagada）
- 透過 Data API 查 GA4 事件資料，拿 purchase 與 refund 紀錄和後台訂單比對（Tagada）
重複觸發是驗證時要抓的重點。Spilno Agency 列的常見錯誤之一，是增強型衡量和 GTM 追蹤同一件事，例如 page_view 觸發兩次；NiceLookingData 則稱，重複的轉換事件會灌高指標並破壞歸因。
驗完之後，還有一個後台設定。NiceLookingData 稱 GA4 資料保留期間預設為 2 個月，超過之後探索報表就沒有歷史資料，建議到管理、資料設定、資料保留，把期間改成 14 個月。
關鍵事件標幾個：Haalytics 說 2 到 5，Spilno 說不超過 10
Haalytics 稱 GA4 可以標到 30 個轉換，但只應該標 2 到 5 個。Spilno Agency 同樣寫 GA4 最多允許 30 個關鍵事件，建議的上限則是 10 個。
“GA4 lets you flag up to 30, but you should only flag 2–5.”
GA4 讓你標到 30 個，但你只應該標 2 到 5 個。
兩家的理由不同。Haalytics 稱標超過這個數量，轉換率就失去意義；Spilno Agency 則稱超過 10 個代表缺乏優先順序。Spilno Agency 同一篇在介紹關鍵事件的段落另有一種寫法：技術上 GA4 可以把任意數量的事件標成關鍵事件，實務上建議維持 5 到 10 個。上限是 30 個還是不設限，兩段說法並不一致。
關鍵事件也會用在廣告端。Spilno Agency 稱，GA4 的關鍵事件可以匯入 Google Ads，供自動出價演算法使用；它也建議，事件在 DebugView 驗證成功之後，才標成關鍵事件。
名額之外，設定本身也需要回頭檢查。NiceLookingData 稱其手動版 GA4 稽核清單有 23 項檢查、分 6 類，其中 7 項是可能弄壞資料的關鍵項目；另外提供的 CSV 範本含全部 61 項檢查。
銷波快觀點：不報錯的設定，才是最貴的設定
前陣子查一個廣告帳號底下的資料集，撈出兩顆名字一模一樣的像素。活動實際掛的那顆是 2016 年建的，當天還在觸發，購買事件的資料品質分數 9.2 分；另一顆是幾天前新建的，最後觸發時間顯示 1969-12-31，也就是從來沒收過任何事件。這次掛對了，但那是運氣。
值得記下來的是這種錯誤的形狀。它不是程式寫錯，也不是資料算錯。設定選單裡並排著兩個選項，看起來一模一樣。選錯不會有警告、不會報錯、不會中斷。報表只會安靜地印出一整排零，而零在轉換廣告的前幾天看起來完全正常。過去碰到的失敗多半在程式或排程層，這一種在人機介面層。防法只有一條：改動之後，回讀實際掛上去的那組 ID。
我們的判斷是，GA4 電商事件也有同樣的形狀。Tagada 描述的缺商品資料與放錯層，事件都照樣進得來，問題要到打開商品報告才看得出來，所以驗證要放在上線前的測試訂單，而不是等報表。
同一個道理在 SEO 那邊踩過更貴的版本。有兩篇文章，目標關鍵字都是憑判斷填上去的。回頭查 Search Console 才發現，猜的那個詞一次曝光都沒有，真正在排名的詞完全沒寫進文章。第一篇是寫完才查，等於做完才知道主題錯了；第二篇記得先查，但仍然是寫完之後補兩節。驗證動作放在流程的哪一格，決定它救不救得回來。
最後一個提醒跟工具無關。有一次改寫網站分類描述，把語氣從教學調成對話，順手把「GA4」三個字拿掉了。後來查關鍵字工具才發現，那個詞是每月 6,600 次搜尋、難度 2、年增 83%，是那個分類底下最大的市場。修飾文字看起來只影響風格，但它會同時刪掉策略資產。設定、命名、描述，這幾件事的共同點是改動成本低、誤改的代價要很久以後才浮出來。
結論：先下一筆測試訂單，再談其他分析
Tagada 引述 Digital Applied 的統計，有追蹤 purchase 的電商 GA4 實作只有 48%，add_shipping_info 與 add_payment_info 更只有 26% 與 28%。就算 purchase 有收到，Tagada 說 items 陣列缺漏或放錯層，商品報告一樣無法使用。
能先做的有四件：在 GTM 預覽模式與 DebugView 下一筆測試訂單，確認 items 有內容、purchase 只觸發一次；把事件名稱統一成小寫加底線；關鍵事件只留最重要的幾個，Haalytics 建議 2 到 5 個，Spilno Agency 建議不超過 10 個；NiceLookingData 建議把資料保留期間從預設的 2 個月改成 14 個月。
喜歡這篇？讓行銷變好懂，訂閱銷波快。
資料來源
- GA4 Ecommerce Events: The Complete Implementation Guidetagada.io
- How to Set Up Events in Google Analytics 4: Complete Guide 2026spilnoagency.com.ua
- How to Set Up GA4 Conversion Tracking Without Losing Your Mindhaalytics.com
- GA4 Audit Checklist 2026nicelookingdata.com
- Google Analytics 4 中事件跟蹤全解析（2026）ichdata.com
- 獨立站 Google Analytics 4 埋點指南znbo.com
- How to set up Enhanced Conversions for Google Ads and GA4stape.io
