GA4 電商事件概念示意：加購到購買的抽象漏斗（非官方介面）

GA4 電商事件教學：purchase、add_to_cart 與網店／WooCommerce 設定要點

ByLiftmerce

GA4 不會自動送出完整電商事件；你需在網站、應用程式或 Google Tag Manager 實作建議事件（例如 view_item、add_to_cart、begin_checkout、purchase），並帶上 items 與金額等參數。purchase 應在付款成功後觸發並含 transaction_id。本文整理事件意義與核對步驟，並說明與 UTM／Meta Pixel 的分工——不教虛假 ROAS。

GA4 電商事件：重點一覽

項目可核對事實（核對至 2026-10-23）
是否自動收集電商建議事件不會自動發送；需在網站／應用程式或 GTM 實作（Set up ecommerce events）
常見漏斗事件view_item、add_to_cart、begin_checkout、purchase 等（完整清單見 Developers）
items 最低要求每個品項需 item_id 或 item_name（兩者都提供更佳）；未設 quantity 時預設為 1
value／currency設 value 時應設 ISO 4217 currency；官方：value＝各品項 price × quantity 總和，不含 shipping／tax
purchase 關鍵必填 transaction_id 以降低重複；另帶 items、value、currency；可選 tax、shipping、coupon、customer_type
驗證啟用 debug_mode 後用 DebugView 即時核對；報告／探索通常約 24 小時後才有完整數據
命名原則優先用建議事件；purchase 取代舊 ecommerce_purchase，並與自動 in_app_purchase 不同
禁止事項不虛構 CTR／ROAS；不宣稱 WooCommerce 未裝外掛／GTM 就會自動送完整電商事件

若你已會用 UTM 標記活動來源（見〈UTM 參數教學〉），下一步是讓加購與購買在 GA4 有可對帳的事件；兩者分工不同，不可互相取代。

為什麼 GA4「有流量卻沒電商數據」？

設定碼（Google tag／資料串流）主要負責工作階段與許多自動／加強評估事件。電商建議事件則需要額外脈絡（例如哪些商品、多少金額、哪一筆訂單），因此 Help 明言不會自動送出。結果是：即時報告可能已有使用者與頁面瀏覽，但「電商購買」報告或漏斗探索仍空白，直到你在結帳成功路徑實作 purchase（以及上游的 add_to_cart 等）。

Shopify 等部分平台可能透過其 Pixel／整合自動追蹤部分事件；WooCommerce 或自架站則通常需要外掛、GTM 或開發者在關鍵點呼叫 gtag('event', …)。請以實際 DebugView 為準，不要假設「裝了 GA4 就等於有營收」。

核心事件有哪些？add_to_cart 與 purchase 何時送？

依 Measure ecommerce，典型實作會涵蓋：從列表選取／檢視商品、加入或移出購物車、開始結帳、填寫運送與付款資訊、完成購買或退款，以及站內促銷曝光／點擊。常用事件名稱包括 view_item_list、select_item、view_item、add_to_cart、view_cart、remove_from_cart、begin_checkout、add_shipping_info、add_payment_info、purchase、refund，以及 view_promotion／select_promotion。

  • add_to_cart：使用者將商品加入購物車時發送；必填 items。若要計算金額相關指標，應同時提供 value 與 currency。
  • begin_checkout：進入結帳流程的第一個步驟時發送（可帶整單 coupon）。
  • purchase：確認交易成功之後發送（感謝頁載入或可靠的成功回調／伺服器確認），並帶唯一 transaction_id。教程亦示範可綁在購買按鈕，但實務上應避免在付款尚未成功時就記入營收。

參數細節以 Recommended events 為準；本篇不貼完整程式碼範例，重點是「何時觸發」與「必帶什麼」。

items、value、currency、transaction_id 各代表什麼？

參數層級意義（依官方文件）
items事件商品陣列；多數電商事件必填。每項至少 item_id 或 item_name
price／quantity品項單價與數量；未設 quantity 時預設 1
value事件事件金額＝各品項 price×quantity 總和；官方要求不要把 shipping、tax 算進 value
currency事件ISO 4217 三字碼（例如 HKD）；設 value 時通常必填，營收指標才正確
transaction_id事件（purchase／refund）交易唯一識別碼，用來避免重複計算購買
shipping／tax事件（purchase 等）運費與稅金，與 value 分開傳送

品項層也可帶 brand、category、variant、coupon、discount 等；官方建議有資料就盡量填，以便報表維度更完整。自訂參數有上限，需注意自訂維度／指標配額。

gtag／GTM／WooCommerce 外掛路徑怎麼選？

三條常見路徑，選一條當「真相來源」並用 DebugView 驗證即可；本文不把某一版外掛後台按鈕名稱當成唯一真相：

  • gtag.js：在商品頁、加購動作、感謝頁直接呼叫建議事件。適合可控主題與少量自訂程式碼的站。
  • Google Tag Manager：把電商物件推進 dataLayer，再以 GA4 Event 代碼讀取。適合行銷／開發分工、需頻繁改觸發條件的團隊（Help 有 GTM 設定概述）。
  • WooCommerce／平台外掛或整合：若選用官方或可靠外掛，請依現行外掛文件啟用電商追蹤，並用 DebugView 確認事件名稱與參數是否符合 GA4 建議事件。不要假設「安裝 WooCommerce 後 GA4 會自動有完整 purchase」。

決策原則：能穩定帶出建議事件名稱與 items／transaction_id 的路徑，優於「看起來有很多自訂事件」卻對不上電商報告的路徑。

如何用 DebugView／即時報告驗證，又如何與 UTM、Meta 後台交叉看？

依 Set up a purchase event：在 config 加上 debug_mode: true（或官方其他啟用方式）後，於 DebugView 點擊加購／完成一筆測試單，確認事件名稱、參數與 items 是否出現。報告與探索通常約 24 小時後才會填滿；不要只用「今天報表空白」判定實作失敗。

對帳三角建議固定口徑後再比較，而不是把三個後台數字直接相減：

  • GA4 電商報告：看 purchase／營收與商品維度（本篇焦點）。
  • UTM 工作階段來源：先標記活動再看購買歸因於哪個 campaign；見〈UTM 參數教學〉。
  • Meta／廣告後台：Meta 的 Purchase 與 GA4 purchase 是兩套系統；像素設定見〈Meta Pixel 教學〉。跨工具對帳時請固定歸因與時間範圍，見〈Meta 廣告歸因教學〉。

常見錯誤：感謝頁重複發送、缺少 transaction_id、自訂事件取代建議事件

  • 感謝頁每次重新整理都再送 purchase：若沒有穩定唯一的 transaction_id，營收會被重複計算。應以訂單編號等唯一值作為 transaction_id，並避免在未成功付款的按鈕點擊就送出。
  • 缺少 transaction_id：官方將其列為 purchase 必填，用於降低重複事件。
  • 只用自訂事件名稱（例如 my_buy）而不送建議事件：Help 說明建議事件會自動填入維度與指標並參與計算；自訂事件通常無法完整取代電商報告體驗。
  • value 含運費稅金，或設了 value 卻漏 currency：與官方參數定義不符，營收指標可能失真。
  • items 空白或只有名稱沒有可對帳 SKU：商品報表與退款對帳會變困難；至少維持 item_id 或 item_name，並盡量兩者都填。

常見問題

只裝 GA4 設定碼，電商報告就會有購買嗎？

通常不會。電商事件需額外實作或由電商平台／外掛送出。Help 亦說明這類事件因需要更多脈絡，不會自動發送。請用 DebugView 確認是否已出現 purchase 與 items。

purchase 應該綁在「按下購買按鈕」還是「付款成功頁」？

應在確認交易成功之後（或可靠的成功回調）發送，並帶唯一 transaction_id，避免重複計算。按鈕點擊當下付款可能失敗，過早送出會讓營收與訂單系統對不上。

GA4 的營收能否直接當 Meta ROAS？

不能直接等同。來源定義、歸因、退款與時間窗都可能不同。請與 UTM、訂單系統、廣告後台交叉看，不要用單一數字對外承諾。

來源

Similar Posts