Meta 廣告有點擊卻沒訂單，
先查追蹤還是商品頁？

報表上的零，說的是哪一種成果？

打開廣告管理員，把正在看的欄位名稱抄下來。是網站購買、潛在顧客，還是某一個自訂轉換？接著記下廣告帳號、行銷活動、廣告組合、廣告，以及報表起迄日、時區、查詢時間與篩選條件。廣告組合選用的成效目標、資料集和事件，也放在同一份紀錄

這篇以網站購買為例。若一則廣告的網站購買是零，往上查看所屬廣告組合與行銷活動，再到商店後台核對同期間的訂單狀態。這樣才能分清楚：目前是這一則沒有廣告購買紀錄，還是商店也沒有已付款訂單

商店的待付款、已付款、取消與退款分開列，測試單另外標記。欄位還沒載入、權限錯誤或尚未取得資料時，先記待查；等到實際讀到 0，才把它放進後面的判斷

事件名稱的依據：Meta：標準事件的詳細說明；平台事件與廣告認列的範圍見下方對照

點擊很多，有多少次真的載入商品頁？

先看你用的是哪一種點擊欄位，再把同一則廣告、相同期間的「連結點擊次數」和「網站連結頁面瀏覽次數」並排。Meta 的連結點擊可導向 Meta 內部或外部的目的地，所以還要核對這則廣告實際開啟的網址

連結頁面瀏覽說的是點擊後網頁載入的紀錄。Meta 說明，這項衡量可透過應用程式內瀏覽器或網站像素追蹤；資料不完整時，部分事件可能由模型估計。因此，兩欄可以幫你找出下一個查核位置，卻不適合直接當成逐人配對的流失名單

如果兩欄出現落差，先用手機從廣告預覽開啟目的頁，記下最後網址、商品與規格是否正確、頁面能否操作，以及錯誤或重新導向發生在哪一步。再核對頁面事件是否收到，才能區分實際載入問題與量測問題

欄位依據：Meta：連結點擊次數、Meta：網站連結頁面瀏覽次數

事件有購買，廣告報表為什麼還是零？

到了這一步，先把三份資料分開看。事件管理工具顯示收到的事件，廣告管理員顯示廣告認列的成果，商店後台則提供訂單與付款狀態。Meta 的官方說明指出，事件管理工具收到的大部分事件，和廣告報表中的歸因事件，本來就有不同的範圍

廣告組合使用哪一種歸因模式、認列哪一段點閱或瀏覽期間，都要以目前設定為準。核對時保留原設定和報表，先弄清楚差異來自哪裡，再討論是否需要調整，別為了讓兩邊數字一樣就先改歸因

例如事件有 6 次、商店有 4 筆已付款訂單，只能先記數量相差 2。要找出是否重複、漏送或付款狀態不同，還需要可對照的時間與識別資料；只有彙總時，還不知道是哪幾筆，也不能把商店全站訂單直接算到這則廣告

範圍與歸因依據：Meta：廣告報表與事件管理工具中的事件數差異、Meta：歸因模式和歸因設定

要確認事件有沒有送到，該怎麼測？

對完報表後，若還不知道網站操作有沒有送出對應事件，就把這件事獨立查清楚。先確認負責人能操作正確的資料來源，再依 Meta 的瀏覽器事件測試流程進行

1. 在事件管理工具的資料來源中，選取本次網站使用的名稱與編號，進入「測試事件」
2. 在瀏覽器或網站事件區輸入目的頁網址，透過開啟網站功能進入，並保持測試事件頁籤開啟
3. 依序操作商品瀏覽、加購與開始結帳，將每次動作和收到的事件名稱、時間、網址及參數一起記下來
4. 購買測試由負責人先安排可識別的測試方式與付款處理，再檢查完成購買時的事件與訂單狀態；測試資料另做標記
5. 把沒收到、收到不同事件，以及畫面上的錯誤分開保存，交給負責網站或追蹤的人重現與修正，修正後再用同一條操作路徑回查

若網站也透過轉換 API 傳送資料，瀏覽器這邊測完，還要由整合負責人依伺服器事件的流程檢查。兩種來源的結果分開留下來，才能知道這次驗證到哪裡

Meta 也說明，清除測試事件頁籤的動態，不會把測試活動從事件管理工具、廣告報表與受眾建立的結果中移除。整理正式成果時，保留測試的時間與標記，別把它混成顧客購買

測試流程依據：Meta：驗證應用程式和網頁瀏覽器事件、Meta：測試伺服器事件

確認有到站卻沒成交，接著看哪個頁面？

事件和訂單範圍清楚後，再沿著實際購買流程找阻礙。Meta 的 ViewContent、AddToCart、InitiateCheckout、Purchase，分別對應內容瀏覽、加購、開始結帳與完成購買；你的網站實際在哪個動作觸發，仍要對回前一節的測試紀錄

把同來源、同期間、同商品的事件列出來，先看哪個階段值得補證據。事件次數還不是同一批人的完整路徑，若要算逐步流失，還要確認追蹤單位與能否配對。不要把不同報表抓來的總數拼成一條看似精確的漏斗

需要看頁面時，可以先做這三項查核，把看到的結果記下來：

• 廣告到商品頁：廣告承諾的商品、優惠與可選規格，進入頁面後是否找得到；點擊後是否到了預期的版本與網址
• 商品頁到購物車：手機上能否選規格、確認庫存、看清價格並加購，按鈕或提示有沒有擋住操作
• 購物車到付款：配送地區、運費、總額和付款方式在哪一步出現，哪個具體動作會報錯，能否用相同條件重現

如果重現了錯誤，就先處理那一個步驟，再回到相同條件確認。若流程能走通，卻還不知道顧客為什麼離開，就把價格、訊息與購買疑慮列為待驗證問題，接著補頁面觀察或顧客回饋，別一次把價格、受眾和素材全換掉

事件定義依據：Meta：標準事件的詳細說明；三項頁面查核是本文整理的操作方法

同樣是零訂單，三組資料要怎麼接著查？

以下資料專為教學設計，示範如何把報表、事件與下一步接在一起。範例中的零都指欄位已讀到 0；你尚未取得的欄位，仍應保留待查

要請同事協助，怎麼寫才接得下去？

把下面六欄複製到工作文件，每次只接著補一筆能區分原因的資料。內部保留必要的識別資料，對外請人協助時先移除顧客姓名、電話與完整地址

工作對象

廣告帳號、行銷活動／廣告組合／廣告 ID、商店、資料集、商品與目的頁

查詢範圍

查詢時間、報表起迄日、時區、篩選、幣別、歸因模式與設定

廣告與到站

成效目標、事件名稱、曝光、連結點擊、頁面瀏覽與該層級購買；缺欄位記待查

事件與訂單

事件來源與時間、收到的事件、付款／待付／取消／退款／測試狀態、可用共同 ID

操作證據

裝置、廣告預覽與最後網址、做到哪一步、可重現的錯誤、事件測試時間與結果

判讀與接續

已確認什麼、原因候選、還缺哪一筆證據、由誰查、修正後用什麼條件回看

例如範例三可以交接成：商品 C，手機加購後在配送步驟出現指定地區無法配送；已保存規格、地區、時間與錯誤畫面，請網站負責人核對配送規則，修正後按同一路徑重測。這份紀錄就能把眼前的問題交到對的人手上

資料查清楚之後，這一輪要改哪一件事？

若問題停在網址或結帳錯誤，先修那個可重現的步驟；若購買事件與付款資料對不上，先把對照補完；若資料與流程能核對，才針對訊息或素材提出一個比較問題，保留其他條件，記下這次改動與回看方式

要開始比較文案，可以接著用三組標題與固定條件的素材測試教學。若廣告其實還沒有曝光或花費，則先回到零曝光、零花費排查，把投遞條件查清楚