電商行銷漏斗追蹤怎麼做？從曝光到購買的數據架構與事件設定清單

什麼是電商行銷漏斗？先把「漏斗」從商品意圖中消歧

這裡的漏斗不是實體用品，而是電商網站追蹤使用者從曝光、點擊、到站、瀏覽、加入購物車、結帳到購買的轉換漏斗。

電商行銷漏斗的價值，在於把「訂單有沒有增加」拆成一連串可量測的行為。使用者看到廣告，點進商品頁，閱讀規格，加入購物車，開始結帳，完成付款，每一步都可能流失，也都需要不同的資料來判斷。

漏斗階段	使用者行為	主要觀察重點
曝光	看到廣告、搜尋結果、社群貼文或 EDM	素材是否吸引正確受眾
點擊	點進網站或活動頁	訊息是否讓人願意進一步了解
到站與瀏覽	進入商品頁、活動頁或分類頁	頁面是否承接原本的期待
購買	加車、結帳、付款、完成訂單	價格、付款、運費與信任感是否順暢

電商漏斗和一般行銷漏斗差在哪？

一般行銷漏斗常停在認知、考慮、購買等概念層級；電商漏斗必須落到事件、指標與訂單資料。只說使用者在「考慮階段」沒有太大用處，真正能執行的是知道他是否看過商品、選過規格、加入購物車、開始結帳，或卡在付款前。

我會把電商行銷漏斗視為營收系統的儀表板，不是簡報上的模型。沒有事件與參數，漏斗只是好看的圖。

為什麼只看訂單數會誤判問題？

訂單數是結果，不是原因。訂單下降可能來自廣告流量變差、商品頁說服力不足、價格競爭力下降、結帳流程出錯，或付款頁追蹤漏記。只看 purchase 或後台訂單，很容易把錯誤問題交給錯誤的人處理。

例如訂單少了，不一定是廣告投手投錯，也可能是活動頁載入變慢、折扣碼不能用、手機版結帳按鈕被遮住。漏斗追蹤的任務，就是把這些問題分層拆開。

完整電商漏斗應該分成哪些階段？

完整電商漏斗至少要分成曝光、點擊、到站、商品互動、加入購物車、開始結帳、購買與回購，並讓每一層對應資料來源和指標。

階段	使用者行為	資料來源與主要指標
曝光	看到廣告、搜尋結果、社群內容、EDM	廣告後台、Search Console、EDM 報表，觀察曝光、觸及、開信
點擊	點擊素材或連結進站	廣告後台、UTM、GA4，觀察 CTR、CPC、來源媒介
到站	進入登陸頁或商品頁	GA4，觀察工作階段、參與度、登陸頁表現
商品互動	瀏覽商品、篩選、搜尋、選規格、收藏	GA4 電商事件、dataLayer，觀察 view_item、select_item、站內搜尋
購買流程	加車、查看購物車、開始結帳、付款	GA4、GTM、Meta Pixel、Google Ads，觀察 add_to_cart、begin_checkout、purchase
回購	會員登入、EDM 回訪、LINE OA 點擊、再行銷購買	CRM、EDM、LINE、廣告受眾，觀察回購率與 LTV

曝光層：廣告、社群、自然搜尋、EDM

曝光層回答的是「哪些人看到了商品」。Google Ads、Meta Ads、TikTok Ads、自然搜尋與 EDM 都會產生曝光資料，但它們的定義不完全相同，不能直接混成一個數字比較。電商行銷漏斗在這一層要保留來源、活動、素材與受眾標記。

到站層：工作階段、登陸頁、來源媒介

到站層要確認使用者是否真的進入網站，以及進來後是否有互動。GA4 的工作階段、登陸頁、來源媒介與 UTM 是這裡的核心。常見誤判是廣告後台有點擊，但 GA4 到站很少，這時要查頁面載入速度、追蹤碼是否正常、UTM 是否被轉址吃掉。

商品互動層：商品瀏覽、篩選、搜尋、加入收藏

商品互動層能看出使用者是否真的進入購買思考。只進首頁不等於有購買意圖，真正接近下單的是 view_item、select_item、站內搜尋、規格選擇與 wishlist_add 這類事件。這一層資料愈細，愈容易判斷商品頁是否需要調整。

購買層：加車、結帳、付款、完成訂單

購買層是電商漏斗最容易出現技術與商業問題的地方。add_to_cart 高但 begin_checkout 低，通常要看購物車設計、免運門檻與價格揭露。begin_checkout 高但 purchase 低，則要查付款方式、運費、帳號登入要求與錯誤訊息。

回購層：會員、EDM、LINE、再行銷受眾

回購層不能只交給廣告平台。會員資料、CRM、EDM、LINE OA、訂單後台與再行銷受眾都會影響長期營收。若只看單次 ROAS，很容易砍掉短期不漂亮但能帶來高回購的流量。

每個漏斗階段要追蹤哪些事件？

電商漏斗要能診斷問題，必須把每個階段轉成事件追蹤，至少包含事件名稱、觸發時機、必要參數與常見錯誤。

階段	建議事件	觸發時機	必要參數	常見錯誤
流量	session_start、click	使用者進站或點擊主要連結	source、medium、campaign、content	UTM 命名不一致，活動無法比較
商品列表	view_item_list、select_item	看到分類頁或點選商品卡	item_list_name、item_id、item_name	列表名稱缺失，無法判斷推薦區表現
商品頁	view_item	商品頁載入且商品資料可取得	item_id、item_name、price、currency	頁面載入就觸發，但商品資料尚未寫入
購物車	add_to_cart、remove_from_cart、view_cart	加車、移除商品、查看購物車	items、quantity、value、currency	重複觸發造成加車率失真
結帳	begin_checkout、add_shipping_info、add_payment_info	進入結帳、填配送、選付款	items、value、shipping_tier、payment_type	付款跳轉後事件中斷
購買	purchase	訂單成立頁或後端確認訂單成立	transaction_id、value、currency、items	重新整理感謝頁導致 purchase 重複

曝光與流量事件：impression、click、session_start

曝光事件多半來自廣告平台或 EDM 系統，網站端通常從 click 與 session_start 開始承接。關鍵不是把所有曝光塞進 GA4，而是確保點擊後的 UTM 能被保留，讓來源、媒介、活動與素材可以追到後續 add_to_cart 與 purchase。

商品事件：view_item、select_item、view_item_list

商品事件要讓分析者知道使用者看過哪些商品、從哪個列表點進來、商品價格與品項是否正確。view_item_list 適合分類頁、搜尋結果頁與推薦區；select_item 用來記錄商品卡點擊；view_item 則是商品頁的核心事件。

購物車事件：add_to_cart、remove_from_cart、view_cart

購物車事件可以判斷商品頁是否成功推動下一步。add_to_cart 必須帶 items、quantity、value、currency，否則只能看次數，不能看金額與品項。remove_from_cart 也值得追，因為大量移除可能代表價格、規格或運費資訊在加車後才被揭露。

結帳事件：begin_checkout、add_shipping_info、add_payment_info

結帳事件用來拆解使用者卡在哪一步。begin_checkout 代表進入結帳流程，add_shipping_info 代表配送資訊完成，add_payment_info 代表付款方式選擇完成。這些事件不能只靠按鈕點擊，最好以系統狀態或表單成功送出作為觸發依據。

購買事件：purchase、transaction_id、value、currency

purchase 是整個電商漏斗最重要也最不能亂的事件。transaction_id 必須唯一，value 要與訂單金額規則一致，currency 建議固定使用 TWD 或實際交易幣別。若同一張訂單送出兩次 purchase，ROAS、CPA 與商品營收都會被污染。

自訂事件：coupon_apply、size_select、search_no_result、wishlist_add

自訂事件適合補足標準事件看不到的問題。coupon_apply 可以檢查折扣碼是否影響結帳，size_select 可判斷規格選擇是否卡住，search_no_result 能找出站內搜尋需求落空，wishlist_add 則適合觀察還沒購買但有興趣的人。

電商漏斗的資料架構：GA4、GTM、廣告平台與後台要怎麼串？

可落地的電商數據追蹤架構，應由網站前端產生事件，透過 GTM 與 dataLayer 傳給 GA4、廣告平台，再用訂單後台校正營收。

• 網站前端負責產生使用者行為與商品參數。
• GTM 負責部署事件、觸發條件與平台標籤。
• GA4 負責分析工作階段、事件、漏斗與來源媒介。
• Meta Pixel、Google Ads 轉換追蹤負責廣告平台最佳化訊號。
• CRM、EDM、LINE OA 與訂單後台負責會員、回購與實際營收。
• BigQuery 適合保存明細資料與做跨來源分析。

網站前端：dataLayer 與事件觸發

網站前端是資料品質的源頭。商品 ID、商品名稱、價格、數量、類別、折扣與訂單編號，應由網站系統寫入 dataLayer，再由 GTM 讀取。若直接在 GTM 用頁面文字硬抓商品名稱，後續改版很容易壞掉。

分析層：GA4 與 BigQuery

GA4 適合看標準報表、探索分析與漏斗路徑；BigQuery 適合保留事件明細，處理跨天、跨來源、客製分群與資料稽核。中小型電商不一定第一天就要 BigQuery，但當每月要反覆回答同樣的漏斗問題時，資料明細會變得很有價值。

廣告層：Google Ads、Meta Ads、TikTok Ads

廣告層需要轉換訊號，但不能把廣告後台當成唯一真相。Google Ads、Meta Ads、TikTok Ads 都有自己的歸因視窗與模型，因此同一筆訂單可能被多個平台認列。電商行銷漏斗應同時保留平台報表與網站端事件，避免只聽單一平台說法。

會員與訂單層：CRM、EDM、LINE OA、後台訂單

會員與訂單層負責回答「誰買了、買了什麼、之後有沒有再買」。CRM、EDM 與 LINE OA 的點擊資料應盡量帶上 UTM，訂單後台則是營收校正基準。GA4 的 purchase 可以用來分析行為，但財務與出貨仍應回到訂單後台確認。

伺服器端追蹤與資料遺失風險

伺服器端追蹤可以降低部分瀏覽器限制、廣告阻擋與前端漏送造成的資料遺失，但它不是萬用解方。若網站事件本身命名混亂、transaction_id 不唯一，改成 server-side tagging 只會把錯資料更穩定地送出去。

漏斗 KPI 怎麼看？每一層不是只看轉換率

漏斗 KPI 要分層看，曝光看 CTR 與 CPC，到站看參與度，商品頁看加車率，結帳看完成率，購買後看回購與退款。

漏斗位置	主要 KPI	常見解讀	優先檢查
曝光到點擊	CTR、CPC、曝光品質	素材或受眾不匹配會讓點擊偏低	廣告文案、素材、搜尋字詞、受眾設定
點擊到到站	工作階段、登陸頁參與度	點擊與到站落差大，可能是載入或追蹤問題	頁速、轉址、UTM、追蹤碼
商品頁到加車	加車率、商品互動率	商品頁無法說服或規格選擇有阻力	價格、圖片、規格、庫存、評價
加車到付款	購物車放棄率、結帳完成率	運費、付款、信任感常造成流失	免運門檻、付款方式、錯誤訊息
購買後	AOV、ROAS、CPA、LTV、退款率	單次訂單漂亮不代表長期獲利好	客單價、回購、退貨、客服原因

曝光到點擊：CTR、CPC、流量來源品質

CTR 與 CPC 只能說明流量取得效率，不能直接代表購買品質。很多低價點擊會讓報表看起來熱鬧，但若後續 view_item、add_to_cart 與 purchase 都弱，這批流量可能只是便宜，不是有價值。

到站到商品頁：跳出、互動、商品頁瀏覽率

到站後要看使用者是否真的進入商品內容。若登陸頁參與低、商品頁瀏覽少，常見原因是頁面承諾與廣告不一致、手機版資訊太難找、載入太慢，或活動頁把主要商品藏得太深。

商品頁到加車：加車率、價格接受度、規格選擇

商品頁到加車是商品說服力的關鍵段落。加車率低時，不要只改按鈕顏色，應先檢查價格、規格、庫存、運費揭露、評價與保固。我的判斷是，很多電商把問題歸因給流量，其實是商品頁沒有回答購買前的基本疑慮。

加車到付款：購物車放棄率、結帳完成率

加車後流失，通常不是使用者沒興趣，而是流程出現阻力。常見問題包含運費最後才出現、付款方式不足、強制註冊、折扣碼失效、錯誤訊息不清楚，或第三方付款跳轉讓使用者不安。

購買後：回購率、LTV、退款率

購買後指標決定投放能不能放大。ROAS 高但退款率也高，代表前端承諾可能過度；CPA 偏高但 LTV 更高，可能仍值得投。只用單次 CVR 管理電商，容易低估會員、訂閱、補貨型商品與高客單商品的價值。

實例：一個電商品牌如何建立從曝光到購買的追蹤表

單品電商活動頁可以用一張追蹤表管理漏斗，欄位包含階段、事件、指標、問題判斷與改善動作，讓行銷與工程對齊。

範例背景：單品電商活動頁

假設一個台灣電商品牌販售保健食品，主要流量來自 Google Ads、Meta Ads、EDM 與自然搜尋。活動頁包含商品介紹、評價、FAQ、加入購物車按鈕與結帳流程。這類單品頁不需要一開始就做大型資料倉儲，但一定要把從點擊到 purchase 的事件先定義好。

追蹤事件表：從廣告點擊到 purchase

階段	事件或資料	主要指標	問題判斷	改善動作
曝光	廣告曝光、EDM 開信	曝光、觸及、開信率	曝光不足或受眾太窄	調整受眾、關鍵字、名單分眾
點擊	ad click、UTM	CTR、CPC	素材吸引錯誤人群	拆分素材與受眾，統一 UTM 命名
到站	session_start、page_view	工作階段、登陸頁參與	點擊多但到站少	檢查頁速、轉址、追蹤碼
商品瀏覽	view_item	商品頁瀏覽率	使用者未看到核心商品	調整首屏訊息與商品區位置
規格互動	size_select、coupon_apply	規格選擇、折扣使用	方案或折扣理解成本高	簡化方案、提前揭露折扣條件
加入購物車	add_to_cart	加車率、加車金額	商品頁說服不足	補強評價、成分、保證與價格理由
開始結帳	begin_checkout	購物車到結帳比率	購物車阻力過高	檢查運費、免運門檻、按鈕可見性
付款	add_payment_info	付款方式完成率	付款選項不符需求	補上常用付款方式並檢查錯誤訊息
購買	purchase	CVR、CPA、ROAS、AOV	營收與追蹤不一致	用 transaction_id 對照後台訂單

判讀方式：哪一層掉最多就先修哪一層

追蹤表的重點不是蒐集更多事件，而是找出優先順序。若 CTR 差，先修素材與受眾；若 view_item 低，先修登陸頁承接；若 add_to_cart 低，先修商品頁；若 begin_checkout 到 purchase 掉很多，先修結帳流程。不要在結帳壞掉時加碼廣告，這只會放大浪費。

如何把追蹤表交給工程師或代理商執行

交付追蹤需求時，不能只說「幫我裝 GA4 電商事件」。比較好的格式是列出事件名稱、觸發時機、dataLayer 欄位、必要參數、驗證方式與完成標準。工程師負責事件穩定送出，行銷負責 UTM 與活動命名，數據人員負責驗證 GA4、廣告後台與訂單後台是否能對得上。

如何判斷漏斗哪一層出問題？

漏斗診斷要用「症狀、可能原因、檢查資料、改善方向」判斷，並分來源、裝置、商品類別檢查，不要只看平均轉換率。

症狀	可能原因	檢查資料	改善方向
曝光多但點擊少	素材無吸引力、受眾不準、搜尋意圖不符	CTR、搜尋字詞、素材分組、受眾分群	重寫賣點、拆分受眾、排除低意圖字詞
點擊多但到站少	頁面太慢、轉址錯誤、追蹤碼漏裝	GA4 工作階段、頁速、UTM、伺服器紀錄	修正轉址、壓縮資源、確認 GTM 觸發
到站多但加車少	商品頁說服不足、價格疑慮、規格不清	view_item、scroll、size_select、add_to_cart	改善首屏、評價、規格、運費揭露
加車多但購買少	結帳流程複雜、付款不足、運費衝擊	view_cart、begin_checkout、add_payment_info、purchase	簡化結帳、增加付款方式、提前揭露費用
廣告 ROAS 好但後台營收沒成長	平台重複歸因、purchase 重複、退款增加	transaction_id、後台訂單、退款、平台歸因	校正事件、檢查退款，分平台看輔助效果

曝光很多但點擊少：素材與受眾問題

曝光很多但點擊少，優先檢查素材、標題、搜尋字詞與受眾。這通常不是網站問題，因為使用者還沒有進站。若自然搜尋曝光高但點擊低，也要檢查標題是否清楚承接搜尋意圖。

點擊很多但加車少：登陸頁或商品頁問題

點擊很多但加車少，代表使用者來了，但沒有被商品說服。要分開看登陸頁與商品頁，確認使用者是否看得到商品、是否理解價格與規格、是否看到評價與保證。這段若只提高預算，通常不會讓訂單健康成長。

加車很多但購買少：價格、運費、付款與信任問題

加車很多但購買少，常見問題在結帳階段。運費最後才揭露、付款方式太少、需要先註冊、折扣碼失效、頁面看起來不可信，都會讓使用者放棄。此時應逐步比對 view_cart、begin_checkout、add_shipping_info、add_payment_info 與 purchase。

不同來源、裝置、商品類別要分開看

平均數會掩蓋問題。桌機結帳正常，不代表手機正常；品牌字流量轉換高，不代表冷流量有效；熱銷商品加車高，不代表全站商品頁都好。電商行銷漏斗應至少依來源媒介、裝置、商品類別、活動檔期分開看。

不要把平均數當成唯一答案

平均轉換率適合做總覽，不適合做決策。真正要改網站或調預算時，應找出哪一群人、哪個來源、哪個裝置、哪個商品、哪個步驟出現異常。沒有分群的漏斗報表，常常只會讓團隊吵方向。

常見追蹤錯誤：為什麼漏斗數字會不準？

漏斗數字不準通常來自事件重複、漏送、UTM 混亂、跨網域設定錯誤、付款跳轉污染來源，以及平台歸因規則不同。

問題	症狀	原因	檢查方法	修正方向
purchase 重複	GA4 購買數高於後台訂單	感謝頁重新整理或事件觸發兩次	用 transaction_id 比對事件明細	以唯一訂單狀態觸發，避免重複送出
purchase 漏記	後台有訂單但 GA4 沒有 purchase	付款跳轉、追蹤碼未載入、同意模式影響	測試完整付款流程與 DebugView	調整觸發時機，必要時評估後端回傳
來源變 referral	付款平台成為主要來源	跨網域或 referral 排除未設定	檢查來源媒介與付款網域	設定跨網域追蹤與排除不該計入的 referral
UTM 混亂	同一活動被拆成多種名稱	大小寫、命名規則、媒介格式不一致	匯出 campaign、source、medium 清單	建立 UTM 命名規範與發稿前檢查
平台數字不一致	GA4、廣告後台、訂單後台各說各話	歸因視窗、事件定義、退款與重複認列不同	用 transaction_id、日期、金額對照	定義各報表用途，不強求完全相同

purchase 重複或漏記

purchase 重複會讓營收、ROAS 與 CVR 虛高；purchase 漏記會讓投放與網站表現被低估。最基本的檢查方式是用 transaction_id 對照 GA4 事件與訂單後台，確認同一張訂單只出現一次，而且金額與幣別規則一致。

付款頁跳轉造成來源變成 referral

很多電商使用第三方金流，付款完成後再回到網站。若跨網域與 referral 排除沒有設定好，GA4 可能把付款平台當成購買來源，導致原本的 Google Ads、Meta Ads、EDM 或自然搜尋來源被覆蓋。

UTM 命名混亂導致活動不可比

UTM 命名混亂會讓資料後續無法整理。同一個 Meta 活動若有人寫 facebook、有人寫Meta、有人寫 fb，報表就會被拆開。建議固定 source、medium、campaign、content 的命名規則，並讓所有廣告、EDM、LINE OA 連結都照同一套格式。

GA4、廣告後台、訂單後台數字不一致

這三種數字本來就不會完全一樣。GA4 看網站事件與來源，廣告後台依自己的歸因規則認列轉換，訂單後台則看實際成立訂單、取消與退款。成熟的做法是定義各自用途，而不是要求每個平台的購買數完全一致。

Cookie、同意模式與瀏覽器限制的影響

Cookie、同意模式、瀏覽器限制與廣告阻擋都會影響追蹤完整度。這不代表資料不能用，而是要理解誤差來源。當資料品質受到限制時，更應該加強第一方資料、事件一致性、UTM 規範與訂單對照，而不是盲目追求單一平台的漂亮數字。

2026 年電商漏斗追蹤要注意什麼？

2026 年的電商漏斗追蹤更依賴第一方資料、事件品質與網站端資料治理，廣告平台歸因不能取代完整追蹤架構。

第一方資料比第三方 Cookie 更重要

第一方資料包含會員 ID、訂單、EDM 點擊、LINE OA 互動、站內行為與客服紀錄。這些資料由品牌自己掌握，比外部 Cookie 更穩定。電商行銷漏斗若要長期可用，應優先把會員、訂單與網站事件串成可比對的資料結構。

廣告平台歸因不能取代網站事件追蹤

廣告平台會為了最佳化投放提供歸因資料，但它不會完整回答網站哪一步壞掉。Meta Pixel 或 Google Ads 轉換能幫助演算法學習，GA4 與後台資料則能讓團隊判斷商品頁、結帳流程與營收品質。把廣告平台當作唯一真相，是 2026 年仍然常見的管理錯誤。

Server-side tracking 適合誰，不適合誰

Server-side tracking 適合已經有穩定事件命名、固定工程資源、廣告預算較高、且需要降低資料遺失的電商。不適合事件還沒整理、商品資料不乾淨、UTM 命名混亂的小型團隊。先把前端事件、purchase 去重、訂單對照做好，通常比急著導入伺服器端追蹤更有效。

AI 搜尋與內容漏斗的關係

AI 搜尋讓使用者可能在進站前就取得部分答案，因此內容漏斗也要納入追蹤。自然搜尋頁面、比較頁、FAQ、教學內容與商品頁之間的內部連結，應該用事件與 UTM 或站內參數觀察。內容不只帶流量，也可能影響後續商品瀏覽與購買。

漏斗是什麼？電商行銷漏斗和實體漏斗有什麼不同？

漏斗在電商情境中是使用者從接觸品牌到完成購買的階段模型，例如曝光、點擊、到站、商品瀏覽、加入購物車、結帳與購買。它和實體用品無關，重點是用數據追蹤每一層的流失與轉換。

電商漏斗一定要從曝光追到購買嗎？

理想上要從曝光追到購買，因為只看網站內行為會少了流量品質判斷。若資源有限，最小可行版本至少要追到站來源、view_item、add_to_cart、begin_checkout 與 purchase。

GA4 電商事件一定要設定哪些？

優先設定 view_item、add_to_cart、begin_checkout、add_shipping_info、add_payment_info 與 purchase。若有分類頁、搜尋頁或推薦區，建議再補 view_item_list、select_item 與 search 相關事件。

為什麼 GA4 的 purchase 和後台訂單數不同？

常見原因包含 purchase 重複或漏記、付款跳轉、同意模式影響、退款與取消訂單規則不同，以及日期歸屬差異。GA4 適合分析行為，訂單後台仍是營收與出貨的主要依據。

加入購物車很多，但購買很少，應該先查什麼？

先查 view_cart、begin_checkout、add_shipping_info、add_payment_info 與 purchase 的落差，再檢查運費、付款方式、折扣碼、強制註冊、錯誤訊息與手機版結帳流程。加車後流失通常代表結帳阻力，而不只是流量問題。

廣告後台已經有轉換數，還需要自己做漏斗追蹤嗎？

需要。廣告後台的轉換數主要服務投放最佳化，不能完整說明網站哪一層流失。自己的漏斗追蹤能比較不同來源、裝置、商品與結帳步驟，也能用訂單後台校正平台歸因。

小型電商沒有工程師，也能做漏斗追蹤嗎？

可以先做簡化版。使用電商平台內建 GA4、GTM、Meta Pixel 與 Google Ads 轉換設定，並統一 UTM 命名。等到廣告預算提高或問題變複雜，再補 dataLayer、BigQuery 或伺服器端追蹤。

2026 年還能靠 Cookie 做完整追蹤嗎？

不能完全依賴 Cookie。瀏覽器限制、同意模式與廣告阻擋都會影響追蹤完整度。比較穩健的做法是強化第一方資料、會員與訂單對照、事件品質，以及必要時評估 server-side tracking。

Server-side tracking 一定要做嗎？

不一定。若事件命名、purchase 去重、UTM 與訂單對照都還沒做好，先導入 server-side tracking 的效益有限。它適合已有基本追蹤架構、廣告預算較高、且需要降低資料遺失的電商。

本文會推薦哪一種廚房漏斗或機車漏斗嗎？不會，本文只討論電商行銷漏斗。

不會。這裡討論的是電商網站的行銷漏斗與數據追蹤架構，範圍包含 GA4、GTM、dataLayer、Meta Pixel、Google Ads、UTM、事件追蹤、KPI 與漏斗診斷。