GA4 電子商務追蹤是什麼：14 個標準事件、參數結構與報表解析

GA4 電子商務追蹤（GA4 Ecommerce Tracking）是透過在網站加入特定事件，讓 Google Analytics 4 記錄使用者從商品瀏覽到完成購買每個關鍵步驟的資料系統。這不是 GA4 的自動功能，需要開發端主動傳送事件，GA4 才會填入電子商務報表。本文從資料分析師的角度整理這套系統的事件結構、參數規格、報表判讀方法，以及 SEO 分析師在電商追蹤中應該優先關注的數據節點。

GA4 電子商務追蹤是什麼？

GA4 電子商務追蹤是一套以「事件」為基礎的商業數據收集機制，透過 14 個 Google 預定義的電子商務事件，記錄使用者在購物流程中每個關鍵行為，並自動填入 GA4「營利總覽」與「電子商務購買」報表。GA4 不會自動收集這些事件，收到後才會解讀並更新報表。

與 Universal Analytics 的加強型電子商務不同，GA4 電子商務追蹤基於 GA4 的事件模型，每個行為都是一個獨立的「事件 + 參數」組合，不再依賴 hitType: transaction 這類舊有結構。

和 GA4 轉換事件設定的差異在於：轉換事件（key events）可以是任意自訂事件，電子商務事件則必須使用 Google 規定的命名，GA4 才能自動對應到電子商務報表的維度與指標。兩者可以重疊，例如 purchase 事件既是電子商務事件，也通常設為轉換事件。

資料延遲：GA4 電子商務報表最多需要 24 小時才會完整填入，實時報表中的電子商務數據不完整，不應作為當日判斷依據。

GA4 電子商務的 14 個標準事件是什麼？

Google 定義了 14 個推薦電子商務事件，依購物漏斗可分為四個層次：商品展示、加購考慮、結帳轉換、售後管理。每個層次的事件各自填入不同的報表維度。

商品展示層（Impression）

• view_item_list：使用者查看商品列表（分類頁、搜尋結果頁）
• select_item：使用者從列表點擊特定商品
• view_promotion：使用者看到促銷活動（banner、推薦欄）
• select_promotion：使用者點擊促銷活動

商品考慮層（Consideration）

• view_item：使用者查看商品詳情頁
• add_to_cart：加入購物車
• remove_from_cart：從購物車移除
• view_cart：查看購物車頁面

結帳轉換層（Checkout）

• begin_checkout：開始結帳流程
• add_shipping_info：填入配送資訊
• add_payment_info：填入付款資訊
• purchase：完成購買（必設）

售後管理層（Post-purchase）

• refund：退款（全額或部分）

備注：Google 將 generate_lead 也列於推薦事件文件中，但多數電商場景以上述 13 個為主要追蹤對象。

14 個事件中哪些應該優先設定？

GA4 電子商務事件的設定優先順序，應依「分析價值」與「設定成本」共同決定，而非所有事件一次設定完成。以下 P0/P1/P2 分類為分析實踐歸納，屬推論框架，不同電商平台的設定難度可能有差異。

GA4 電子商務事件優先順序：P0/P1/P2 事件分類

優先級	事件	分析價值	設定難度	說明
P0（必設）	purchase	最高	中	沒有 purchase 事件，電子商務報表完全無法啟用；是轉換追蹤的核心
P1（建議）	add_to_cart	高	低	購物車加入率是商品吸引力的直接指標；與 purchase 搭配可計算加購-購買轉換率
P1（建議）	begin_checkout	高	低	結帳開始率揭示「加購 → 放棄」的落點；是購物漏斗的關鍵轉折點
P1（建議）	view_item	高	低至中	商品詳情頁瀏覽數；搭配 add_to_cart 可計算商品頁轉化率
P2（可選）	view_item_list	中	中	分類頁和搜尋結果的商品展示追蹤；影響 GA4 商品清單分析
P2（可選）	add_shipping_info	中	中	配送資訊填寫率；找出結帳流程中的物流摩擦點
P2（可選）	add_payment_info	中	中	付款資訊填寫率；診斷付款方式相關的放棄問題
P2（可選）	refund	中	高	退款追蹤需要後台觸發；對 GMV 準確性有影響
P2（可選）	view_promotion / select_promotion	中	中	促銷活動效益分析；適合有定期促銷活動的電商

對於剛開始建置電子商務追蹤的站點，建議先完成 P0 + P1 四個事件，確認數據穩定後再擴充 P2 事件。

每個事件的必要參數是什麼？

GA4 電子商務事件的參數分為事件層級（event-level）和商品層級（item-level）。缺少必要參數的事件不會被 GA4 識別為電子商務事件，會退化為自訂事件，導致報表空白。

主要事件的必要與選用參數對照

事件	必要參數（event-level）	必要參數（item-level）	選用參數
purchase	currency, value, transaction_id	item_id 或 item_name（擇一）	tax, shipping, coupon, affiliation
add_to_cart	currency, value	item_id 或 item_name（擇一）	items 詳細欄位
begin_checkout	currency, value	item_id 或 item_name（擇一）	coupon
view_item	currency, value	item_id 或 item_name（擇一）	items 詳細欄位
view_item_list	item_list_id 或 item_list_name	item_id 或 item_name（擇一）	index（列表位置）
refund	currency, value, transaction_id	-（可不傳 items 做全額退款）	items（部分退款時需要）

currency 必須使用 ISO 4217 格式，台灣為 TWD，不能填「台幣」或「NTD」。value 的單位為該幣別的最小主要單位（TWD 直接填數字，不需乘以 100）。

transaction_id 在 purchase 事件中是去重機制的關鍵，同一個 transaction_id 的 purchase 事件只會計算一次，避免使用者重新整理頁面造成重複計算。

items 陣列的欄位有哪些用途？

items 陣列是電子商務事件的商品資料容器，每個事件可攜帶多筆商品記錄。了解每個欄位的分析用途，有助於在設定階段決定哪些欄位值得投入工程資源。

GA4 items 陣列欄位及分析用途

欄位	類型	分析用途	是否必要
item_id	string	商品 SKU 識別；跨報表關聯商品表現；GA4 商品報表的主要 key	必要（item_name 二擇一）
item_name	string	商品顯示名稱；GA4 後台顯示文字	必要（item_id 二擇一）
price	number	單品售價；AOV（平均訂單金額）計算基礎；商品單價分析	選用（強烈建議）
quantity	number	購買數量；計算商品銷售量；庫存與需求分析	選用（建議）
item_category	string	商品分類；分類層級 CTR 與轉換率比較；GA4 商品分類報表	選用
item_brand	string	品牌維度；多品牌平台的品牌績效分析	選用
item_variant	string	商品規格（顏色、尺寸）；規格層級轉換率分析	選用
coupon	string	商品層級折扣碼；區分促銷效果是商品還是全單折扣	選用
index	number	商品在列表中的位置；分析不同排序位置的點擊與轉換率	選用（view_item_list 時建議）
discount	number	折扣金額；計算實際折扣幅度對轉換率的影響	選用

items 陣列中同一個事件最多可以傳送 200 筆商品記錄。單筆事件的參數總量有上限（200 個 event-level 參數 + items），超過會被截斷。

GA4 購物漏斗報表怎麼看？

GA4 電子商務的購物漏斗數據可以從兩個入口查看：「報表」中的電子商務報表，以及「探索」中的漏斗探索功能。兩者提供不同層次的分析視角。

路徑 1：報表 → 營利 → 電子商務購買

此報表顯示商品層級的電子商務數據：商品名稱、商品瀏覽次數、加入購物車次數、購買次數、購買收益，適合快速查看哪些商品表現最好。詳細欄位說明可參考 GA4 電子商務購買報表說明。

路徑 2：探索 → 自由形式 / 漏斗探索

在GA4 探索報表中建立漏斗探索，依序加入 view_item → add_to_cart → begin_checkout → purchase 的事件節點，可視化每個步驟的完成數量與放棄率。

各階段放棄率參考值（來源：Baymard Institute 研究與業界觀察；以下屬於參考基準，不同產業和平台差異顯著）：

購物漏斗各階段放棄率參考基準

漏斗節點	事件	全球平均放棄率參考	診斷意義
商品詳情頁 → 加入購物車	view_item → add_to_cart	約 75-85% 放棄（加購率 15-25%）	商品頁說服力、價格定位
加入購物車 → 開始結帳	add_to_cart → begin_checkout	約 40-60% 放棄	購物車頁 UX、時機問題（稍後購買）
開始結帳 → 完成購買	begin_checkout → purchase	約 50-70% 放棄	結帳流程複雜度、付款方式、配送費用
整體購物車放棄率	add_to_cart → purchase	全球平均約 70%（2024 Baymard）	整體轉換效率基準

GA4 漏斗探索中的「重新計算」設定會影響漏斗數字的計算方式：開放式漏斗（Open Funnel）允許使用者從任何步驟進入，封閉式漏斗（Closed Funnel）要求按順序完成。電子商務分析建議使用封閉式漏斗，以確保數字的一致性。

GA4 電子商務數據與實際訂單差異怎麼診斷？

GA4 的 purchase 事件次數幾乎總是低於後台訂單數。這是正常現象，但差異若超過 10-15% 通常代表設定問題，需要診斷。以下是最常見的 4 個原因（此為實作累積的推論框架，各站點情況不同）。

GA4 電子商務數據 vs 實際訂單差異的常見原因與診斷方式

原因	機制說明	診斷方法	典型差異幅度
廣告封鎖器 / 隱私設定	使用者安裝 AdBlock、uBlock 或瀏覽器隱私模式封鎖 GA4 請求	與後台訂單比對，若台灣用戶差異大於歐美，相關性低；若差異穩定，可能是封鎖率造成	3-8% 低估
transaction_id 重複去重	GA4 對同一 transaction_id 只記錄一次；若訂單確認頁可重複載入，正常，不是錯誤	在 GA4 事件報表中查看 purchase 事件的 transaction_id 欄位，確認無異常重複	0-3% 差異
事件設定錯誤（缺少必要參數）	purchase 事件未傳 currency 或 transaction_id，GA4 收到但不寫入電子商務報表	開啟 GA4 Debug View，完成一次測試購買，確認事件中包含所有必要參數	可能導致 100% 遺失
頁面載入失敗（payment redirect）	使用者點擊付款跳至第三方頁面，回來時訂單確認頁已失效，GA4 事件未觸發	檢查付款閘道 redirect 流程；考慮改為 server-side 事件（GA4 Measurement Protocol）	5-20%，取決於付款方式比例

診斷優先順序建議：先確認 Debug View 中 purchase 事件的參數完整性（排除原因 3），再比對差異比例與封鎖率估算（排因 1），最後檢查付款流程的 redirect 問題（原因 4）。

GA4 電子商務數據怎麼和 SEO 分析結合？

GA4 電子商務數據讓 SEO 分析從「自然流量有多少」升級到「自然流量帶來多少真實購買轉換」。結合方式的核心是交叉篩選：在 GA4 中以 session_source / session_medium 過濾自然搜尋，再查看這段流量的 purchase 事件數與 revenue。

操作路徑（在 GA4 探索報表中）：

1. 建立自由形式探索，加入維度「第一個 session 媒介 / 來源」（First user medium / source）
2. 加入指標「交易」（Transactions）、「購買收益」（Purchase Revenue）
3. 在區隔中篩選 medium = organic
4. 查看不同自然搜尋來源帶來的購買次數與金額

這份資料可以回答的問題：

• 哪些 SEO 關鍵字帶來的流量實際購買率最高？（需要 GSC 搭配）
• 哪些到達頁面的自然流量轉換率最低，值得優化？
• 自然搜尋的 ROAS（Return On Organic Acquisition）是多少？

這套分析與 GA4 SEO 分析教學中的流量分析框架結合使用，可以建立從搜尋曝光到購買轉換的完整數據鏈路。自然流量帶來的購買轉換，也是自然流量真實商業價值的最直接量化指標。

注意：GA4 與 Google Search Console 的數據來自不同系統，查詢維度不互通。GSC 提供搜尋查詢和曝光數，GA4 提供進站後的行為數據。如需關鍵字層級的轉換數據，需透過 Looker Studio 或 BigQuery 將兩個數據源合併。

更多 GA4 與 Google Analytics 4 整體架構的關聯，可參考 GA4 主題指南。

GA4 電子商務追蹤有哪些常見設定錯誤？

GA4 電子商務追蹤完成設定後，最常見的問題是事件有觸發但報表數字不正確。以下五個設定錯誤涵蓋多數常見異常情境，每個都有明確的診斷方法。

GA4 電子商務常見設定錯誤清單

錯誤	症狀	修正方式
currency 參數缺失或格式錯誤	purchase 事件有觸發，但 GA4 電子商務報表中 revenue 顯示 $0 或為空	確認 currency 使用 ISO 4217 格式（TWD），且每筆 purchase 事件都有帶入
items 為空陣列或格式錯誤	電子商務購買報表有購買次數，但商品明細報表為空	確認 items 為陣列格式（不是字串或物件），且每個 item 至少有 item_id 或 item_name
transaction_id 缺失	每次整理頁面刷新都觸發新的 purchase 事件，導致購買次數異常膨脹	在 purchase 事件加入唯一的 transaction_id（訂單編號）；GA4 對同一 ID 只計一次
在正式環境直接 Debug	Debug View 測試數據混入正式報表，造成指標異常	使用 GTM 的 Preview 模式，或在 Debug View 中透過 debug_mode=1 參數區隔測試流量
以即時報表判斷電子商務數據	即時報表顯示有 purchase 事件，但電子商務報表中數字為 0 或偏低	電子商務報表有 24 小時延遲；應在事件觸發後隔天再查報表確認

驗證電子商務追蹤是否正確的最佳方式是：在非正式環境完成一次測試購買，在 GA4 Debug View 即時確認 purchase 事件中每個必要參數均存在且格式正確，再上線。事後修正比事前驗證的成本高出許多。

如需更深入了解 GA4 整體報表架構與數據分析方法，Google Analytics 4 完整指南提供了 GA4 事件模型與報表體系的系統性介紹，是建立 GA4 電子商務分析能力的基礎。