先講一個反直覺的事實：裝了 GA4，不等於你在追蹤電商。我看過太多店家，後台 GA4 裝好幾個月，能看到的只有「今天多少人來、跳出率多少」，卻回答不出最基本的商業問題——這支商品被看了幾次？看了以後有多少人加入購物車？進到結帳頁又流失了多少？這些答案不會自己出現，你必須主動把「加強型電子商務事件」一顆一顆埋進去。
加強型電子商務（Enhanced Ecommerce）的本質，是把使用者在你網站上的購物動作，翻譯成一組 GA4 聽得懂的標準事件。你埋得完整，GA4 就能自動長出購買旅程、購物漏斗、商品成效這些報表；你埋得殘缺，報表就是一片空白。這篇文章會帶你把最關鍵的四顆事件——view_item、add_to_cart、begin_checkout、purchase——從頭埋到位，並且教你怎麼驗證埋對了。
先建立一個記憶框架：五顆事件就是一條購物街
不要把幾十個電商事件死記硬背。你只要記住一條「購物街」的畫面：客人走進店裡看到商品（view_item）、把商品拿進籃子（add_to_cart）、走到收銀台前排隊（begin_checkout）、填完地址付款下單（purchase）。中間還有兩顆常被忽略但很有用的：看了商品列表（view_item_list）與從列表點進單品（select_item）。
這條街的順序，決定了你之後看漏斗的順序。只要事件名稱用官方保留名、參數結構對得上，GA4 就會自動把它們串成漏斗，你不必自己做任何加工。這也是為什麼「事件名稱絕對不能自己亂取」——你把 purchase 寫成 buy 或 order_complete，GA4 就當它是一個普通自訂事件，購買旅程報表永遠是空的。
共通地基：所有電商事件都靠 items 陣列
在動手埋任何一顆事件前，先把最重要的一塊地基打好：items 陣列。GA4 幾乎每一顆電商事件都靠一個 items 陣列描述「這次動作牽涉到哪些商品」，欄位命名全站必須一致。一個標準的 item 物件長這樣（用 gtag 語法示範）：
- item_id: 'SKU-1024'（商品唯一編號，必填，要跟你後台、跟 Google Merchant Center 的 id 對得上）
- item_name: '日式棉麻寬褲'（商品名稱，必填）
- price: 1280（單價，數字，不要帶貨幣符號或逗號）
- quantity: 1（數量）
- item_brand: 'ECPRO'（品牌，選填）
- item_category: '女裝'（主分類，選填，還可接 item_category2 到 item_category5 做多層分類）
- item_variant: '深藍 / M'（規格，選填）
這裡藏著一個高頻雷點：item_id 必須全站唯一且從頭到尾一致。如果你的 view_item 用商品編號、purchase 卻改用資料庫自增 id，GA4 就會把同一支商品拆成兩筆，商品成效報表會慘不忍睹。動工前先跟工程師約定：item_id 一律使用後台 SKU，不准中途換來源。
第一顆事件：view_item（看了商品頁）
只要使用者打開任何一個商品詳情頁，就要觸發 view_item。這顆事件是「商品曝光」的分母，之後算「看了以後有多少人加購」的加購率就靠它。用 gtag 直接寫的話，放在商品頁載入完成後執行：
- gtag('event', 'view_item', {
- currency: 'TWD',
- value: 1280,
- items: [{ item_id: 'SKU-1024', item_name: '日式棉麻寬褲', price: 1280, quantity: 1, item_category: '女裝' }]
- });
注意 currency 與 value 要成對出現。value 是這次事件的金額基準，view_item 時通常等於商品單價。台灣店家一律填 currency: 'TWD'，這是最常見的遺漏——沒填幣別，GA4 的金額欄位會是空的或被當成美金，你的營收數字整個歪掉。
第二顆事件：add_to_cart（加入購物車）
使用者點「加入購物車」的按鈕時觸發。這裡的 quantity 要抓「他這次實際加了幾件」，value 要等於單價乘上數量：
- gtag('event', 'add_to_cart', {
- currency: 'TWD',
- value: 2560,
- items: [{ item_id: 'SKU-1024', item_name: '日式棉麻寬褲', price: 1280, quantity: 2, item_variant: '深藍 / M' }]
- });
常見錯誤是把 value 寫死成單價、不乘數量，結果加購金額永遠偏低。另一個雷是「加購事件綁在頁面載入而不是按鈕點擊」——那會變成每次進頁面都算一次加購，數字灌水。加購一定要綁在點擊行為上，不是綁在頁面。
第三顆事件：begin_checkout 與 purchase（結帳與成交）
使用者從購物車按下「前往結帳」時觸發 begin_checkout，items 要帶上購物車裡所有商品、value 帶購物車總額。而最重要的一顆——purchase——要在「訂單成立、付款成功後的完成頁」觸發，而且必須帶齊交易層級的欄位：
- gtag('event', 'purchase', {
- transaction_id: 'ORD-20260714-0087',
- value: 2560,
- currency: 'TWD',
- tax: 122,
- shipping: 60,
- items: [{ item_id: 'SKU-1024', item_name: '日式棉麻寬褲', price: 1280, quantity: 2 }]
- });
purchase 的 transaction_id 是防止重複計算的救命欄位。GA4 會用 transaction_id 去重，同一個訂單編號傳兩次，第二次會被視為重複而不重複計營收。所以千萬不要用時間戳或亂數當 transaction_id，一定要用你後台真正的訂單編號。這樣就算使用者重新整理完成頁、或按上一頁又前進，營收也不會被灌水。
這裡要點名一個最痛的雷：purchase 事件放在「完成頁載入時觸發」，加上使用者重整頁面，就會重複計算營收。防呆做法有兩層：第一，用真實訂單編號當 transaction_id 交給 GA4 去重；第二，在前端自己記一個旗標（例如把已送出的訂單編號寫進 sessionStorage），送出前先檢查，同一筆不送第二次。兩層一起做才安全。
怎麼驗證你埋對了：DebugView 與即時報表
埋完不驗證，等於沒埋。GA4 提供一個超好用的工具叫 DebugView，能即時看到你這台裝置送出的每一顆事件與每一個參數。開啟方式：安裝 Chrome 擴充「Google Analytics Debugger」並開啟，或在網址加上 debug_mode 參數；接著進 GA4 後台「管理 → DebugView」，就能看到事件流一顆一顆跳出來。
驗證的重點清單：一，事件名稱是不是官方保留名（view_item 而不是 viewItem）；二，點開每顆事件，currency 有沒有帶、value 是不是正確金額；三，items 陣列展開後 item_id / item_name / price / quantity 是否齊全；四，走一次完整下單，確認 purchase 只送一次、transaction_id 是真實訂單編號。另外「即時」報表可以看到過去 30 分鐘的事件總量，適合上線後快速確認事件量有沒有正常進來。
用 AI 幫你產程式碼，但別直接上線
現在用 AI 產這些追蹤碼確實很快。你可以把「請幫我依 GA4 加強型電商規格，用 gtag 寫一顆 purchase 事件，帶 transaction_id、value、currency=TWD、tax、shipping 與 items 陣列」這樣的需求丟給 AI，它多半能生出結構正確的骨架，省下查文件的時間；要它解釋每個參數的意義、或把 gtag 版本改寫成 dataLayer 版本也都很在行。
但這裡要誠實說清楚限制：AI 產的追蹤碼一定要人工驗證，絕不能直接上線。AI 不知道你的 item_id 該接哪個後台欄位、不知道你的完成頁會不會被重整、也常常漏掉 currency 或把事件名稱拼成小駝峰。它產的是「格式正確的範本」，不是「接對你系統的成品」。正確流程是：AI 產骨架 → 你接上真實資料來源 → DebugView 逐欄驗證 → 確認 purchase 不重複 → 才上線。把 AI 當寫初稿的助手，別當可以放手的工程師。
劃重點總結
回顧這條購物街：view_item 是分母、add_to_cart 是興趣、begin_checkout 是意願、purchase 是成交，四顆事件串起來才有漏斗可看。地基是 items 陣列與全站一致的 item_id；救命欄位是 purchase 的 transaction_id；台灣店家最常漏的是 currency: 'TWD'；最痛的雷是 purchase 重複計算，要靠去重與前端旗標兩層防。埋完務必用 DebugView 逐欄驗過再上線。把這幾件事做對，你的 GA4 才算真的在追蹤電商，而不只是一個流量計數器。