廣告追蹤程式碼診斷：電商獨立站指南（2026）

如何使用本指南

本指南適用於成效行銷人員、電商營運人員、分析師、開發人員，以及需要審核代理商、外掛、應用程式或內部方案所安裝追蹤程式碼的團隊。請在預發布環境中測試，或使用可以取消和退款的測試訂單。不要反覆使用真實顧客訂單進行測試。

完成本指南後，您應該能夠

• 區分程式碼存在、標籤觸發、請求傳送、平台接收，以及轉換是否符合出價資格。
• 驗證訂單ID、營收、幣別、產品ID和事件ID等關鍵欄位。
• 診斷重複購買、購買事件缺失、零價值轉換、跨網域歸因丟失和同意設定問題。
• 針對Shopify、WordPress、WooCommerce或自訂電商技術棧選擇正確的診斷方法。
• 為行銷、開發、分析或管理團隊產生清晰的診斷報表。

為什麼已經安裝的追蹤程式碼仍可能產生不可靠的資料

當獨立電商網站開始在Google Ads、Meta Ads、Microsoft Ads或TikTok Ads上投放廣告時，每個平台都會要求安裝追蹤標籤或像素。僅在頁面原始碼中找到這些程式碼，並不能證明轉換追蹤執行正常。

• 廣告平台將標籤顯示為未驗證、未啟用或近期無活動。
• GA4記錄了訂單，但Google Ads沒有顯示轉換。
• 商店後台只有一個訂單，廣告平台卻回報了兩次購買。
• 轉換次數看起來合理，但營收、幣別或產品資料不正確。
• 首頁能偵測到像素，但在結帳流程或訂單確認頁面中消失。
• 瀏覽器和伺服器事件都已傳送，但沒有正確去重。
• 廣告追蹤未按照訪客的同意選擇執行：在行銷同意為denied後，廣告儲存仍被寫入或讀取，或者廣告識別碼或使用者資料仍被傳送。在進階同意模式下，即使ad_storage或analytics_storage為denied，也仍可傳送無 Cookie 的同意 ping；僅出現這種行為並不代表實作失敗。
• 訪客同意同意後，標籤沒有恢復執行。

完整的審核不能止步於「程式碼是否存在？」還要確認每項真實業務動作都以正確的事件名稱、參數、價值、幣別和訂單ID到達正確的平台，並且瀏覽器端和伺服器端的傳送在去重後合併為一次邏輯轉換。

1. 廣告追蹤診斷實際檢查什麼

廣告追蹤可以從五個層級進行評估。只有五個層級全部通過，資料才適合用於效果分析、ROAS計算和自動出價。

GTM中的「標籤已觸發」消息只能證明觸發條件已滿足，不能證明轉換資料準確。請繼續檢查資料層、網路請求、平台測試工具和對應的後台訂單。

2. 先制定電商事件追蹤方案

在排查問題之前，先確定網站真正需要衡量的顧客行為。典型的電商實作至少應涵蓋查看產品、加入購物車、開始結帳和購買。

在本指南的2026年8月版本中，TikTok使用Purchase作為標準電商purchase事件，並使用Lead表示潛在顧客提交。CompletePayment和SubmitForm是分別對應到Purchase和Lead的相容舊名稱；沒有遷移計劃時，不要重新命名正在正常執行的舊版實作。僅在確有聯繫行為時使用Contact。GA4使用purchase，並建議提供transaction_id、value、currency和items陣列等參數。

purchase事件所需的最低資料要求

3. 準備診斷測試

不要將真實顧客訂單作為主要測試。建立一個可以取消或退款的測試訂單，並在開始前記錄以下資訊。

進行主要實作測試時，請停用瀏覽器的廣告封鎖擴充功能，但不要停用網站的同意橫幅。廣告封鎖測試和同意測試應分開進行，否則無法判斷究竟是瀏覽器擴充功能還是同意設定阻擋了標籤。

至少測試三種同意場景

• 尚未選擇Cookie設定的新訪客。
• 接受所有相關Cookie的訪客。
• 拒絕行銷Cookie的訪客。

對於Google 同意模式，請在相關標籤執行前設定預設同意狀態，並在訪客作出選擇後於同一頁面及時更新。請分別驗證ad_storage、analytics_storage、ad_user_data和ad_personalization。進階同意模式可能在儲存狀態為denied時傳送無Cookie的ping；請確認沒有違反訪客選擇而傳送廣告儲存、廣告識別碼或使用者資料。

診斷工具集

1. Google Tag Assistant和GTM Preview

Google Tag Manager預覽會顯示頁面事件、已觸發和未觸發的標籤、觸發條件、變數以及同意狀態。它回答兩個關鍵問題：網站上發生了什麼，以及GTM為何觸發或未能觸發標籤？

2. GA4 DebugView

GA4 DebugView可確認GA4是否確實收到事件，並顯示其參數。它有助於區分GTM實作問題與傳送或GA4資料收集問題。

3. Chrome DevTools Network面板

Network面板會顯示瀏覽器實際傳送的請求。您可以按平台網域、請求類型、檔名、標籤ID或衡量ID篩選。它是回答「瀏覽器是否傳送了資料？」這一問題的關鍵工具。

4. 平台專用測試工具

在Meta Events Manager中使用Test Events和診斷；TikTok使用Pixel Helper、Test Events和診斷；Microsoft Advertising使用UET Tag Helper；Shopify自訂像素使用Shopify Pixel Helper。

4. 完整的廣告追蹤診斷工作流程

步驟1：盤點所有追蹤實作

重複轉換往往源於同一平台被安裝了多次，而不是某個標籤本身損壞。

• GTM在主題中安裝了一次，又通過外掛安裝了一次。
• 官方Shopify Meta應用程式安裝了一個像素，同時還存在單獨的自訂Meta pixel。
• WordPress外掛傳送Purchase，而GTM又傳送了相同的Purchase。
• 原生Google Ads購買動作和匯入的GA4購買動作都被設為主要目標。
• Meta Pixel和Conversions API在沒有有效去重的情況下傳送同一筆購買。
• TikTok應用程式、GTM和主題程式碼各自安裝了同一個像素。

建立一份實作清單。為便於閱讀，請將安裝方式、基礎標籤位置、購買事件來源和伺服器事件狀態合並到一個實作說明欄位中。

在頁面原始碼、GTM標籤清單、WordPress外掛、主題自訂程式碼區域、Shopify Customer Events、Shopify應用程式、Cloudflare Zaraz、伺服器端GTM及任何自訂後端整合中搜尋每個ID。

步驟2：確認基礎標籤正確載入

對於GTM，請勿先直接開啟訂單確認頁面。應從首頁或廣告到達網頁連接預覽，然後沿著真實顧客路徑依次經過產品查看、購物車、結帳和付款。

• 確認預覽已連接到正確的網域。
• 確認頁面載入時出現預期的GTM容器。
• 確認容器ID與當前啟用的帳戶和環境一致。
• 確認基礎Google tag在所有必要頁面載入。
• 檢查付款成功頁面是否仍處於同一偵錯工作階段。
• 檢查重新導向或跨網域重新導向後工作階段是否中斷。
• 檢查Consent Initialization及任何會阻擋標籤的同意狀態。

同時開啟Chrome DevTools，在Network面板中搜尋GTM容器ID、GA4衡量ID、Google Ads轉換ID、Meta pixel ID、TikTok像素ID或Microsoft UET標籤ID。由於請求路徑可能變化，搜尋實際ID比依賴固定端點更可靠。

完全沒有出現請求時，先檢查以下項目

• 程式碼缺失或設定的ID錯誤。
• GTM容器尚未發布，或載入了錯誤的環境。
• 同意設定阻擋標籤執行。
• 內容安全政策阻擋了外部指令碼或端點。
• 廣告封鎖器或瀏覽器隱私權設定阻擋了請求。
• 追蹤程式碼執行前發生JavaScript錯誤。
• 快取或CDN仍在提供舊版網站程式碼。

步驟3：驗證資料層或顧客事件

資料層是電商活動與廣告標籤之間的橋梁。Google Tag Manager和gtag.js從這個結構化層讀取事件和變數。應使用可預測的結構化資料，而不是讓標籤從無關的頁面元素中抓取值。

一個簡化的GA4風格purchase事件如下所示：

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

對於GA4電商，事件層級的value通常應等於items陣列中各項price乘以quantity後的總和，且不應包含shipping或tax，除非您記錄的報表定義與目標平台明確要求採用其他價值定義。

在Chrome主控台中使用以下命令進行初步檢查：

window.dataLayer

僅顯示purchase事件：

window.dataLayer?.filter(item => item.event === "purchase")

驗證以下六點

1. 事件在正確時間發生：Purchase應在訂單真正成功後產生，而不是僅在顧客點選「立即付款」或「提交訂單」時產生。
2. 訂單ID唯一：頁面重新整理後，同一訂單應保留相同ID；不同訂單絕不能共用同一ID。
3. 價值為數值：使用129.90，而不是「$129.90」「USD 129.90」或包含千位分隔符號的字串。
4. 幣別與訂單一致：對於多幣別商店，請比較顯示幣別、結算幣別以及傳送至平台的幣別。
5. items陣列完整：產品ID、價格、數量和折扣應能與後台訂單核對一致。
6. 不保留舊值：單頁應用程式、購物車側欄以及AJAX結帳流程可能會誤用上一個事件的資料。

步驟4：檢查GTM觸發條件和變數

在GTM Preview中完成一次真實測試路徑，選擇purchase事件，然後檢查Tags Fired、Tags Not Fired、Variables、Data Layer和同意。

觸發條件過於寬泛

「頁面URL包含thank-you」之類的規則，會在訪客重新整理、收藏或再次開啟確認頁面時重新觸發。電商購買最好使用真實的訂單完成事件和唯一訂單ID。

觸發條件過於嚴格

實際URL可能是/en/checkout/success，而觸發條件只允許/checkout/success。語言目錄、查詢字串和備用結帳路徑都會使過於嚴格的規則失效。

自訂事件名稱不匹配

資料層傳送event: “checkout_completed”，但GTM監聽purchase。事件名稱必須完全一致，包括大小寫和下劃線。

標籤在資料到達前觸發

標籤在頁面載入期間執行，但value、currency和訂單ID要在幾百毫秒後才進入資料層。標籤看似觸發成功，實際卻傳送了空參數。

AJAX或單頁應用程式沒有產生傳統頁面載入

購物車側欄、彈出式結帳，以及React或Vue應用程式可能不會產生一般頁面瀏覽。應根據業務事件觸發追蹤，而不要只依賴頁面載入或URL變化。

步驟5：使用Network確認請求已傳送

開啟Chrome DevTools -> Network，啟用Preserve log，然後重複完整測試。依平台ID或網域篩選，開啟匹配的請求並檢查Headers和Payload。

• 驗證目標平台及標籤或像素ID。
• 驗證事件名稱、價值、幣別和訂單ID。
• 確認產品ID、數量和items陣列均已提供。
• 確認瀏覽器端和伺服器端事件使用平台所需的相同去重識別碼：Meta和TikTok要求事件名稱或類型與event_id匹配，而GA4和Google Ads的購買使用transaction_id。
• 檢查請求是否被取消、阻擋或回傳錯誤。
• 檢查請求發生在頁面重新導向之前還是之後。

觀察到內容合理的請求，只能證明瀏覽器嘗試傳送，或某個端點接受了請求。它不能證明平台已處理、完成歸因、符合出價資格或業務資料準確。value為0的Purchase請求仍可能成功傳送。

GTM顯示標籤已觸發，但Network中沒有請求

• 同意狀態和內建同意檢查。
• 廣告封鎖或瀏覽器隱私權設定。
• 內容安全政策限制。
• 標籤模板損壞或JavaScript執行時錯誤。
• 立即重新導向導致請求被取消。
• Shopify Pixel Sandbox限制。

步驟6：確認各廣告平台已收到事件

GA4

開啟DebugView，選擇測試裝置，並確認事件順序合理：

page_view
view_item
add_to_cart
begin_checkout
purchase

開啟purchase並驗證transaction_id、value、currency和items。

Google Ads

開啟Goals -> Conversions -> Summary，檢查相關動作的追蹤狀態。若狀態為「未驗證」「標籤無效」或「需要處理」，請從轉換動作中啟動Tag Assistant。修復後帳戶狀態可能需要一些時間才會更新，因此請使用Tag Assistant和實際請求進行即時驗證。

Meta Ads

在事件管理員工具中選擇正確的資料源，並檢查「概覽」、Test Events、診斷、Event Deduplication和Event Match Quality。Test Events用於確認瀏覽器端和伺服器端傳送；診斷用於識別重複事件、無效參數或資料品質問題。

TikTok Ads

使用TikTok Pixel Helper檢查瀏覽器標籤、事件和參數；使用事件管理員工具 -> Test Events檢查即時接收；使用事件管理員工具 -> 診斷檢查持續存在的實作錯誤。

Microsoft Advertising

使用UET Tag Helper驗證UET標籤ID、頁面載入事件、自訂事件、可變營收、幣別和轉換目標條件。Microsoft Advertising中的UET狀態可能需要更多時間才會更新。如果同時使用Microsoft Advertising Conversions API，請驗證其event_id，並確認瀏覽器端和伺服器端傳送不會造成重複統計。對於可變營收，請嚴格依照目標平台要求保留revenue_value和currency。

5. 診斷重複的Conversions和Event Deduplication

重複購買會誇大報表中的ROAS，並向自動出價輸入錯誤訊號。應同時檢查瀏覽器端、伺服器端、外掛、應用程式、GTM和匯入目標，而不是只審核其中一個層級。

Google Ads去重

Google Ads建議為每筆購買傳送唯一交易ID。如果重新整理確認頁面，並把同一訂單再次傳送到同一個轉換動作，Google Ads可以利用相同的交易ID識別重複。交易ID不會自動對不同Purchase轉換動作進行去重。

• 不同訂單不得共用同一交易ID。
• 交易ID不得為空。
• 不要使用顧客電子郵件或電話號碼作為訂單ID。
• 瀏覽器標籤和後端上傳應為同一筆交易使用相同訂單ID。

Meta Pixel和Conversions API去重

當同一個Purchase通過Meta Pixel和Conversions API傳送時，瀏覽器端和伺服器端事件必須共享同一event_name和event_id。不同訂單必須使用不同的event_id值，否則一筆訂單可能被計為兩個事件。

• 瀏覽器端和伺服器端事件是否使用相同的event_name？
• 同一訂單的兩個版本是否使用相同的event_id？
• 每筆不同訂單是否都獲得不同的事件ID？
• 伺服器重試是否產生了新的事件ID，從而意外產生第二個事件？
• Shopify應用程式和自訂CAPI實作是否都在傳送同一筆購買？

TikTok Pixel和Events API去重

當TikTok Pixel和Events API傳送同一事件時，兩端必須使用相同的事件名稱或類型以及相同的event_id，TikTok才能識別這對事件並保留一個邏輯事件。

重新整理訂單確認頁面

僅使用確認頁面的頁面瀏覽來觸發Purchase風險很高。重新整理、收藏或重新開啟頁面都可能再次觸發事件。請使用唯一訂單ID；在條件允許時，應由真實的訂單完成事件觸發，而不是依賴普通頁面載入。

6. 檢查轉換Goals、跨網域結帳和歸因

Primary與次要轉換動作

在Google Ads中，主要轉換動作通常顯示在Conversions欄中，並且當廣告活動使用相關目標時可用於出價。Secondary動作主要用於觀察，通常顯示在All conversions中。不過，當次要動作被納入廣告活動正在使用的自訂目標時，也可以用於出價。

如果事件出現在帳戶中，但廣告活動沒有據此進行優化，請確認該動作是主要動作，並且廣告活動正在使用對應目標。

Every與One

Purchase動作通常需要統計每筆交易。Lead表單常使用One，因為同一次廣告點選產生的重複提交不一定代表多個有價值的潛在顧客。對於銷售，請使用唯一交易ID移除重複訂單。

重複的主要購買目標

一個帳戶可能同時包含原生Google Ads Purchase、匯入的GA4 Purchase，以及Shopify應用程式建立的Purchase。如果三者都被設為主要動作且由廣告活動使用，Conversions列可能會針對一筆訂單包含多個購買訊號。

增強型Conversions

啟用增強型Conversions後，請確認符合資格的第一方顧客資料確實以要求的格式傳送。基礎Purchase標籤正常執行，並不能證明增強型Conversions運作正常。

跨網域結帳和付款重新導向

有些商店會將訪客從主網域引導至單獨的結帳網域、第三方付款服務供應商、預訂系統、表單服務、子網域或地區站點。跨網域設定錯誤可能導致：

• 一次顧客工作階段被拆分為多個工作階段。
• 原始廣告來源消失。
• 付款服務供應商成為報表中的引薦來源。
• 點選ID在結帳前丟失。
• 店面有事件，但付款成功後沒有事件。

僅在您控制、且可以部署同一個GA4標籤的網域之間使用GA4跨網域評估。對於無法部署該標籤的第三方付款網域，請檢查List unwanted referrals，避免付款服務供應商取代原始來源；這不能替代跨網域評估。請從到達網頁開始測試完整重新導向流程，而不是直接開啟成功頁面。

7. Shopify專用追蹤診斷

Shopify Customer Events像素在沙盒環境中執行。應用程式像素使用嚴格沙盒，自訂像素使用寬鬆沙盒，兩者的功能並不完全相同。兩者都應依賴Shopify Customer Events和Web Pixels API，而不是傳統的DOM抓取。

1. 不要只依賴Google Tag Assistant

Google Tag Assistant與Shopify中的GTM自訂像素不相容。請使用Shopify Pixel Helper確認顧客事件進入沙盒，再驗證由此產生的Network請求，以及目標平台的Test Events或診斷資訊。

Shopify Pixel Helper
-> 自訂像素dataLayer
-> GTM標籤
-> Network請求
-> 廣告平台Test Events

2. 避免在沙盒內抓取DOM

Shopify Web Pixels在沙盒中執行。讀取或修改店面DOM的實作可能失敗或表現不一致。應優先使用Shopify Customer Events和Web Pixels API提供的資料，而不是通過CSS選擇器抓取產品價格、按鈕或訂單詳情。

• 直接監聽主題按鈕的點選觸發條件。
• 抓取頁面所顯示產品價格的DOM元素變數。
• 直接使用document.querySelector。
• 把沙盒URL當作店面URL使用。
• 假設GA4增強型衡量可以自動發現每次沙盒互動。

3. 檢查像素是否正在等待同意

開啟Shopify設定 -> 顧客事件 -> 自訂像素並開始測試。如果Pixel Helper顯示「像素正在等待同意」，請檢查：

• 指派給自訂像素的顧客隱私權限。
• 目前市場所使用的Cookie橫幅設定。
• 訪客是否granted了Analytics或Marketing 同意。
• 同意管理平台是否與Shopify Customer Privacy API整合。

4. 正確使用checkout_completed

Shopify checkout_completed通常在每次結帳時觸發一次，且經常可以在「感謝」頁面觀察到。如果存在購買後加購，它可能會在第一個加購頁面觸發，而不會在「感謝」頁面再次觸發。如果預期頁面未成功載入，它也可能無法觸發。

測試一般卡片結帳、Shop Pay或快速結帳、折扣訂單、免費訂單、購買後加購、多幣別訂單，以及「感謝」頁面未完全載入的情況。

8. 常見WordPress和WooCommerce診斷問題

WordPress最常見的問題並不是無法安裝追蹤，而是在太多位置重複安裝同一套追蹤。請按順序檢查以下位置：

• GTM安裝外掛。
• GA4或廣告轉換外掛。
• 單獨的Meta、TikTok或Microsoft Advertising外掛。
• 主題頁首和頁尾的自訂程式碼區域。
• 頁面建構器的自訂程式碼。
• WooCommerce「感謝」頁面自訂內容。
• CDN、快取、指令碼合並和JavaScript延遲設定。

WooCommerce加入購物車、結帳和付款流程經常被AJAX或第三方外掛修改。不要假設標準按鈕點選規則或預設確認頁面規則仍然有效。應將真實的資料層和訂單完成事件作為事實依據。

效能和快取外掛的額外檢查

• 它們是否延遲GTM或像素載入？
• 合並指令碼是否改變了執行順序？
• 包含訂單資料的訂單確認頁面是否被快取？
• 同意更新是否發生在廣告標籤已執行之後？
• 第三方追蹤請求是否被阻擋或錯誤代理？
• 問題是否只在管理員登出後出現？

9. 故障排查矩陣

10. 可靠實作的驗收標準

一次成功的測試購買應滿足以下所有條件：

• Purchase僅在訂單真正成功後觸發。
• One測試訂單在去重後合併為一次邏輯轉換。
• 訂單ID與電商後台一致。
• 轉換價值符合約定口徑，幣別正確。
• 產品ID、價格和數量準確。
• GTM Preview顯示完整事件和已填充的變數。
• Network中存在對應的請求。
• 目標平台可在其測試工具中識別該事件。
• 瀏覽器端和伺服器端事件已去重。
• 已接受和已拒絕的同意狀態均產生預期行為。
• Google Ads Primary、Secondary和計數設定正確。
• 跨網域結帳保留原始來源。
• 重新整理確認頁面不會建立另一次獨立轉換。

最終驗收標準
One筆真實業務訂單 -> 去重後一次邏輯廣告轉換 -> 訂單ID、價值、幣別和產品資料正確 -> 已在平台驗證 -> 可與電商後台核對。

11. 廣告追蹤診斷報表模板

使用以下結構記錄審核結果。儲存測試路徑、Network承載內容、平台Test Events和後台訂單的截圖，作為證據附件。

1. 網站與環境

2. 追蹤安裝清單

3. 測試訂單

4. 診斷結果

5. 問題與修復

6. 回歸測試

完整證據鏈

業務動作
-> 顧客事件/Data Layer
-> GTM觸發條件
-> 廣告標籤
-> Network請求
-> 平台測試事件
-> 轉換目標
-> 後台核對

只有這條證據鏈的每個層級都正確，轉換資料才應當用於廣告活動評估、ROAS報表和自動出價。