GA4 電商埋點 playbook
你店裏每個轉化決策都站在這套管道上。相當多的店跑著一條重複計數、丟步驟、錯歸因的漏斗——還在垃圾上自信地做決定。
GA4 的電商模型是一串事件——view_item、add_to_cart、begin_checkout、add_shipping_info、add_payment_info、purchase——各自攜帶 items 數組與金額參數。做對了，下游所有分析都成立；錯得微妙，下游一切都在禮貌地撒謊。這份 playbook 實現模型、對照事實校驗、裝上隨店舖變化保持誠實的檢查。
階段一：完整實現事件模型
不完整的實現是常態也是問題：有 purchase 沒 begin_checkout 等於沒有漏斗；事件缺 items 數組等於沒有商品級分析；缺 value 和 currency 等於對不上賬的收入報表。完整實現整條序列與參數，能用平台原生集成就用，但即便如此也要審計——原生集成會漂移。
從 view_item 到 purchase 的完整事件序列
每個商務事件帶完整 items 數組：id、name、category、price、quantity
每個帶錢的事件帶 value 和 currency
與訂單系統嚴格一致的 transaction ID——去重全靠它
階段二：對照事實校驗
檢驗就是對賬：同一窗口的 GA4 購買收入對實際訂單。同意模式和攔截器會留一個小缺口；超出的部分要查。然後以顧客身份在桌面和手機端走一遍漏斗，在 DebugView 裏看事件觸發——每一步、各一次、參數正確。重複觸發的 purchase 和幽靈結賬步驟會在這裏現形。
階段三：保持可信
埋點和一切一樣會衰退：主題更新弄掉標籤、新模板不帶事件上線、應用注入重複。按計劃重新對賬、每次重大主題或結賬變更後重走漏斗、把驗證過的狀態記錄在案——漂移因此可檢測，而不是在對數字信心崩塌時才被發現。
運作方式
完整實現模型
每個事件、完整參數、匹配的 transaction ID——走平台集成，加審計。
對賬並走查
收入對到訂單，漏斗在 DebugView 裏、兩類設備上走一遍。
排上覆查
按節奏對賬，每次結構性店舖變更後重新驗證。
你會得到甚麼
每一步都真實、只觸發一次的漏斗
能和訂單系統對上賬的收入報表
真正有數據可用的商品級分析
按計劃抓住的漂移，而不是靠危機
由這些 Agent 負責
可配合使用
常見問題
平台有原生 GA4 集成，我是不是就完事了？
更接近開了個頭。原生集成完整度參差——結賬步驟和 items 數組質量是常見缺口——而且隨平台更新漂移。信之前先審計實際觸發的東西。
GA4 收入該和訂單對到多準？
在你流量結構下同意模式與攔截器能解釋的缺口內——通常低報 5% 到 15%。穩定且被理解的缺口沒事；不穩定或擴大的缺口是缺陷。
服務端埋點值得上嗎？
它收窄攔截器缺口、提升數據持久性，代價是實打實的搭建成本。先修基礎——一條忠實傳輸壞事件的服務端管道，是昂貴的垃圾。
哪些 Agent 跑這個？
Analyst 負責審計、對賬與計劃性重驗，對壞掉的部分產出精確修復方案——它在報告之前必先校驗，因為在壞數據上報告比不報告更糟。