廣告後台沒轉換、訂單後台卻明明有單，多半不是廣告沒效，而是「購買這件事沒被記下來」。月報交出去之前，主管要先分清楚：是追蹤斷了、換站後沒搬、來源在結帳時遺失，還是那張單根本不是從官網下的。以下 5 個檢查點，可以直接交代團隊去查。
廣告後台沒轉換，是「記不到」還是「記錯了」？
先分類再動手。「記不到」是訂單真的發生了，廣告後台卻完全沒收到；「記錯了」是兩邊都有數字，但算法不同、對不起來。兩種的處理方式完全不同，混在一起查，團隊會白忙一場。
| 你看到的症狀 | 比較像哪一種 | 先看哪裡 |
|---|---|---|
| 廣告後台的購買數長期是零，或明顯少於訂單後台 | 記不到 | 本篇 5 個檢查點 |
| 兩邊都有數字，但廣告後台比帳本好看 | 記錯了（各平台各自認功） | 站上〈廣告後台都說賺，帳本卻兜不起來？〉 |
| 購買有記到，想知道客人卡在漏斗哪一步 | 要細看漏斗 | 站上〈GA4 別只看 purchase〉 |
本篇只處理第一列：購買沒被記到。保健品牌通路多，只要結帳、會員或網站任何一個環節換手，追蹤就可能默默斷掉，而且不會跳出任何錯誤訊息。
檢查點 1：購買事件有沒有真的送出去？
先確認「客人下單的那一刻，後台有沒有收到購買事件」。這是所有檢查的起點，其他四個都是在解釋它為什麼沒送出或送到一半。請團隊用測試的方式親眼看一次，不要只看報表有沒有數字。
GA4 這一側，官方的做法是用 DebugView。依 Google 的〈在 DebugView 中監控事件〉說明：
- DebugView 會即時顯示 Analytics 收集到的事件，用來排解問題，使用前要先啟用偵錯模式。
- 個人裝置可以透過 Google Tag Assistant 開啟偵錯模式。
- 開啟後，到「管理」→「資料顯示」下方的「DebugView」查看。
同一頁也提醒：如果網站已導入隱私權控制項，或已導入同意聲明模式但使用者尚未授予 Analytics Cookie 同意聲明，偵錯模式就不會顯示任何事件。所以團隊測試時要先在自己的裝置上同意 Cookie，否則 DebugView 一片空白，會被誤以為是追蹤壞了。
測試時看三件事：
1. 下單完成後，有沒有出現購買事件（purchase）。
2. 事件裡有沒有交易編號。Google 的〈Measure ecommerce〉退款範例的註解寫明，交易編號在購買與退款都需要提供。
3. 這個交易編號，對不對得上訂單後台那一筆的訂單編號。
第 3 點是對帳的關鍵：兩邊編號對得上，才有資格談後面的數字。
檢查點 2：換站、改版、換結帳系統之後，追蹤碼還在嗎？
追蹤碼最常在換手的那一天掉。網站換平台、改版、換購物車或換金流頁，新頁面如果沒有把原本的追蹤碼帶過去，購買事件就會從那天起停止，但舊報表看起來只是「最近怎麼都沒轉換」。
給團隊的查法，是把「事件開始變少的那一天」對照「網站最後一次改動的日期」：
- 網站、結帳頁、感謝頁，有沒有任何一次改版或換系統？
- 改版後，誰負責把追蹤碼搬過去？有沒有人驗收？
- 改版後，每個頁面是否還是用同一個資料串流的代碼？（跨網域設定的前提見檢查點 3。）
主管最該補的是流程：任何改版驗收單，都要多一欄「購買事件測試通過」。 沒有這一欄，下次換站還是會再斷一次。
檢查點 3：結帳在另一個網域時，來源有沒有斷掉？
如果客人在官網逛完、跳到另一個網域結帳，來源就可能在中途遺失。Google 的〈設定跨網域評估〉說明：沒設定時，使用者在不同網域之間移動，每個網域都會建立新的 Cookie 與 ID，同一個人會被視為兩位使用者、兩個工作階段。
白話說：購買被記到了，但記在「另一個人」身上，廣告帶來的那一段就接不起來。購物車、金流頁或會員系統若掛在另一個網域，就會碰到這個情況。
請團隊對照 Google 說明頁的設定與驗證：
- 設定跨網域評估的前提：依說明頁，每個網頁的代碼都必須使用同一個網站資料串流的相同「G-」ID。
- 在「管理」→「資料收集和修改」下的「資料串流」→「網頁」→ 網站資料串流 →「進行代碼設定」→「設定網域」，確認結帳網域有被列進去。
- 從官網點到結帳頁，看網址上有沒有出現
_gl參數。 - 若沒有，頁面列出的常見原因包括：網址重新導向時
_gl被移除，以及與其他指令碼衝突。
這個檢查點如果沒做，月報上的來源也可能跟著亂掉。站上另有一篇專門講 direct 流量：〈GA4 流量來源全是 direct？6 個原因與解法〉。
檢查點 4：廣告平台那一側，有沒有真的收到購買？
GA4 記到，不代表 Meta 也記到。廣告平台自己有一套事件收集，要分開驗。
請團隊到 Meta 的事件管理工具（Events Manager）確認，依 Meta 開發者文件〈Using the API〉：
- 位置是 Events Manager > Data Sources > 你的 Pixel > Test Events。
- 用伺服器端送事件時，要帶測試代碼（test_event_code）才會出現在測試視窗，正式上線的內容必須移除這個欄位。
- 事件送出後，頁面說明約 20 分鐘內可以在 Overview 驗證收到多少事件，以及是透過哪個管道送進來的。
（以上為英文官方頁面的名稱，介面中文字樣可能不同，請以實際畫面為準。）
另一個常被忽略的是「重複」。如果網站同時用瀏覽器端 Pixel 與伺服器端 Conversions API 送同一個購買，Meta 的〈Handling Duplicate Pixel and Conversions API Events〉說明必須設定去重。其中一種做法的重點是：
- Pixel 的 eventID 要和伺服器端的 event_id 相符。
- 事件名稱也要相符。
- 同一個 Pixel 下，相同組合在 48 小時內，後到的事件會被丟棄。
這一點雖然偏技術，但主管只要問團隊一句就夠：「我們的購買，是只從一條路送，還是兩條路都送？有沒有設去重？」答不出來，就先別簽月報。
檢查點 5：這張單，根本不是從官網下的？
常被誤會成「追蹤壞掉」的，其實是訂單本來就不在官網。保健品牌通路多：自家官網、電商平台、團購、實體通路、企業福委。廣告後台記到的，是有回傳購買事件的那幾條路，通常就是裝了追蹤碼的自家官網；其他通路的訂單，除非另外設定回傳，否則就算廣告確實帶來了人，也不會出現在廣告後台。
所以月報前要先做一件事：把訂單後台的單，按通路拆開。 拆完才能回答「廣告後台沒轉換」是不是正常：
- 官網的單，廣告後台應該要對得上，對不上就回頭查檢查點 1 到 4。
- 其他通路的單，若沒有另外設定回傳就記不到，要另外列出，不能和官網混在同一個分母。
- 要不要為某個通路另外設追蹤（例如專屬連結、專屬優惠碼），是主管的決定，先看這個通路的訂單量值不值得。
這裡的原則是：記不到的，月報就老實寫「無法追蹤」，不要用推估補進廣告成效。
補進去的數字，下一季就會被老闆或財務問倒。月報怎麼把通路貢獻寫到站得住腳，可以看〈行銷月報的通路貢獻怎麼寫才站得住腳？〉。
主管可以直接拿去用的「月報前 5 點檢查表」
下表只有欄位，沒有預設結果。請團隊每個月填一次，主管看「結果」那一欄就夠了。
| 檢查點 | 負責人 | 怎麼查（一句話） | 結果 | 查完日期 | 證據 |
|---|---|---|---|---|---|
| 1 購買事件有送出 | 做一筆測試訂單，在 DebugView 與 Test Events 看事件、對訂單編號 | 通過／未通過／無法確認 | 截圖 | ||
| 2 改版後追蹤碼還在 | 對照上次改版日與事件開始變少的日期 | 通過／未通過／無法確認 | 改版驗收單 | ||
| 3 跨網域來源沒斷 | 結帳頁網址有沒有 _gl、結帳網域有沒有列入設定 | 通過／未通過／無法確認 | 截圖 | ||
| 4 廣告平台有收到、沒重複 | Events Manager 看事件與管道，確認去重設定 | 通過／未通過／無法確認 | 截圖 | ||
| 5 通路已拆開 | 訂單後台按通路拆開，標出哪些沒有設定回傳 | 通過／未通過／無法確認 | 通路對照表 |
兩個使用原則：
- 「無法確認」是合法的答案，但不能留白，要寫是誰、卡在哪裡。
- 做測試訂單前，請先和財務確認這筆單怎麼處理，避免月底對帳時多出一筆說不清楚的單。
查完之後，下一步誰來接？
檢查表填完，大致會落在兩種結果。第一種是團隊自己能修，例如補上追蹤碼、設定網域；第二種是卡在法務、通路或系統商，團隊拿不到權限，也沒有人敢拍板。
第二種最耗時間，常見的卡點是：
- 追蹤碼要改的是系統商管的頁面，沒有人催。
- 同意聲明牽涉法務審核，改一次要排很久。
- 不同人各自管 GA4、Meta、網站，沒有人能一次看完整條線。
這時候，主管要的不是再多一份教學，而是有人把這 5 個點一次走完，並且在下一次改版時一起驗收。最省時間的做法，是先請一個外部的人把整條線盤一遍：哪裡斷、卡在誰、誰來修，列成一張修復清單，團隊照著補。
