摘要
商品頁看起來有搜尋流量，購買報表卻很少。此時最容易犯的錯，是直接說「買家在結帳流失」。若加購事件漏送、付款成功頁重複觸發購買事件，或入口來源在跳轉時遺失，圖表本身就可能失真。
先選一個商品與一筆受控測試訂單，確認四個事件及參數能依實際操作出現；再看哪個購買節點值得調查。這篇提供的是量測驗收與問題定位順序，不是提高成交的保證。
先把四個動作量準，再看落差
Google Analytics 的電商量測指南列出商品瀏覽、加購、開始結帳與購買等建議事件。這些事件需要網站或應用程式實作；不是安裝 GA4 後每個站都自動完整收集。
| 買家動作 | GA4 事件 | 應檢查的最小證據 | 常見誤判 |
|---|---|---|---|
| 打開特定商品詳情 | view_item | 實際商品頁觸發；items 中的商品 ID 對得上頁面 SKU | 只有 page_view 就算成商品瀏覽 |
| 成功加入購物車 | add_to_cart | 加入成功後觸發；商品 ID、數量與購物車一致 | 點擊按鈕但加購失敗也送事件 |
| 真正進入結帳 | begin_checkout | 買家進入可填寫或確認訂單的結帳流程 | 只打開購物車就算開始結帳 |
| 訂單成立 | purchase | 訂單確認後觸發；交易 ID、幣別、金額與品項可核對 | 點付款按鈕或重新整理成功頁就重複計入 |
items 屬於品項資料；交易層級的 transaction_id、value、currency 則屬事件資料。Google 的電商 scope 說明有明確區分。若商品變體已選對，但事件送的是母商品或另一個 SKU，依商品拆漏斗時仍會看錯。
用一筆測試訂單驗收，不先調圖表
測試前記下日期、測試環境、商品頁 URL、SKU、變體、數量、預期幣別與測試訂單 ID。若會產生真實訂單，請依商店既有測試與取消流程處理，不要把測試購買混進營運收入。
- 從一個可辨認的入口打開指定商品頁，確認畫面與 SKU；在 GA4 DebugView 看
view_item和items。 - 實際加入購物車一次，確認購物車有該品項，再看
add_to_cart是否只對應這次成功動作。 - 進入結帳頁，確認
begin_checkout的時點、品項和幣別；不要用單純瀏覽購物車代替。 - 以受控方式完成測試訂單，核對訂單後台、付款狀態與
purchase的transaction_id、金額、幣別及品項。 - 重新整理完成頁、返回上一頁並再次進入，檢查是否重複送出購買事件；也檢查取消或付款失敗時是否誤送。
Google 的電商驗證文件建議以 DebugView 即時查看事件與參數，並提醒錯誤事件名稱、缺少必要參數、重複標籤及交易 ID 問題。DebugView 能協助確認資料有送達，仍需與訂單後台核對真實交易；報表也可能有處理時間，別用剛送出的事件立即判定日報錯誤。
漏斗落差是線索，不是原因
GA4 的Purchase journey 報表包含 session start、view product、add to cart、begin checkout、purchase。其預設封閉漏斗只計入按指定順序完成步驟的使用者；買家若跳過某步，仍可能購買，卻不會出現在後續封閉步驟。報表可切換開放漏斗作為另一種檢查方式。
因此先確認事件完整、漏斗設定、時間區間及比較的指標單位。事件次數、商品件數、使用者數與訂單數不能直接互相相減。 一個人可多次看商品、加購多件，也可能跨裝置完成付款；兩個柱狀圖的差額不是已知的流失人數。
| 看見的現象 | 先查量測 | 再查實際體驗 |
|---|---|---|
| 商品瀏覽多、加購少 | 加購成功後是否觸發；不同 SKU 是否一致 | 變體預選、價格庫存、加購按鈕與手機版 |
| 加購多、結帳少 | 購物車與結帳的事件時點是否正確 | 運費、配送限制、退貨條件及結帳入口 |
| 結帳多、購買少 | 付款失敗是否誤送；成功訂單是否漏送或重複送 | 付款方式、錯誤提示、地址或優惠碼流程 |
第一列可接著檢查商品變體連結與預選；第二列可檢查運費與退貨資訊的顯示順序。若價庫不一致，另用五站對帳流程追查。這些都是下一步假設，應用實測與客服、訂單資料確認。
依入口頁和可辨認來源切分
整站漏斗混合了不同商品、活動和來客。事件可信後，可先看商品落地頁、裝置與商品類別，再依可辨認的 session source / medium 比較。保持相同日期範圍、漏斗設定與指標單位；樣本過少時先記錄，不急著下結論。
來源欄位代表 GA4 能辨認的引薦或活動資訊。Google 的 direct 說明指出，缺少引薦資料、UTM 遺失或瀏覽器阻擋追蹤等情況都可能歸到 (direct) / (none)。它不能被整批改名為「AI 搜尋來客」。能辨認的特定引薦來源可以單獨觀察，但也不等於所有 AI 搜尋點擊都被完整捕捉。
若想評估搜尋入口，先確認 landing page、來源維度與標記路徑可用；再把 GA4 的站內互動與 Search Console 等各自能量到的資料並列，不要把兩套不同口徑強行對成一條精確的 AI 搜尋成交路徑。
常見問題
只裝 GA4，這四個電商事件會自動出現嗎？
一般網站仍需設定對應事件及參數。部分電商平台整合可能代為送出部分事件，但應依實際平台設定和 DebugView 核對，不要只憑報表名稱推定實作完成。
為什麼有人沒有加購，漏斗卻有購買？
可能是事件漏送、跨裝置、匯入交易，或買家走了不同路徑。GA4 的封閉漏斗要求依序完成步驟；先切換開放漏斗並核對測試流程，再判斷原因。
purchase 筆數和後台訂單數不同，先修哪裡？
先按同一時區與期間比對有效訂單，排除測試、取消、退款與付款未完成等狀態差異；接著查成功事件是否漏送、重複觸發，以及交易 ID 是否穩定。後台訂單與支付紀錄仍是交易核對的基礎。
GA4 的 direct 流量可以當成 AI 搜尋嗎？
不可以。direct 表示來源資訊不足或被歸為直接流量，成因不只一種。只能對有辨認依據的來源作有限分析，未知的仍標為未知。
參考來源與資料時間
以下 Google Analytics 第一方文件於 2026-10-16 查核。本文的四事件驗收表與調查順序是 FlyPig AI 的編輯整理；事件差異不保證代表買家流失，更不能保證調整後的銷售、搜尋曝光或 AI 搜尋引用結果。
- GA4：Measure ecommerce：電商事件與參數實作。
- GA4：Validate your ecommerce setup：DebugView、事件名稱與重複事件排查。
- GA4：Purchase journey report：購買旅程步驟與封閉／開放漏斗。
- GA4：Ecommerce scopes：事件與品項層級參數。
- GA4：Understand direct traffic：未知來源與
(direct) / (none)的限制。
下一步
今天先完成一筆可核對的測試訂單，交付一張「操作時間、事件名稱、SKU、交易 ID、訂單狀態」對照表。事件可信後，才挑落差最大的商品與入口頁，找出下一個要實測的購買障礙。若仍在整理整體商品頁路徑，可從行銷與轉換主題導覽繼續。