轉換 API 設好了，測試事件面板卻是空的—

轉換 API 設好了，測試事件面板卻是空的——五個地方依序查

太長不看版： 測試事件面板空白，代表事件沒進到 Meta，或進去了但沒帶測試碼。這兩件事的查法完全不同。先看你的伺服器端有沒有真的收到請求、Meta 的回應寫了什麼，再回頭懷疑前端。多數人反過來做，先改前端程式碼，於是在錯的那一層繞了一整天。

CAPI↗ 最麻煩的地方是它每一層都可以安靜地失敗。前端 fetch().catch(() => {}) 吞掉錯誤，中間層回 200 但其實什麼也沒送，Meta 收到了卻因為時間戳過期不計入。整條鏈上沒有任何一段會主動告訴你出事了。

所以查的順序要從後往前：先確定 Meta 有沒有收到，再往回找是誰沒送出去。

一、先確認你打的是哪個像素

聽起來蠢，但這是最常見的一種。開發環境跟正式環境用不同像素、換帳號後程式裡的 ID 沒改、或者同一個品牌有兩個像素而你在 A 的面板看 B 的事件。

確認方式不是看程式碼，是看你實際送出去的 payload。把送出的 pixel ID 印出來，跟事件管理工具網址列上的那串數字比對。這兩個數字對不起來的話，後面四步都不用查了。

順帶一提，如果你最近換過廣告帳號，像素的使用權限跟像素本身是兩回事。權限沒分享過去，API 會回一個講權限的錯誤，而不是說「查無此像素」。

二、看你的伺服器端拿到了什麼回應

Meta 的 /events 端點回的東西資訊量很大，但前提是你有把它記下來。

正常成功的回應長這樣：

{ "events_received": 1, "messages": [], "fbtrace_id": "..." }

events_received 是 0 或者根本沒有這個欄位，就代表沒收。這時候 messages 陣列裡通常會寫原因。

實務上這一步最常卡在「你根本沒存這個回應」。很多人的 CAPI 程式是送出去就不管了，出事的時候沒有任何紀錄可以回頭看。這件事的成本在換像素的時候會具體浮現：想把過去的事件重送一次，才發現當初只記了一行 console log，完整的 payload 沒存過，重播不了。

固定把整包送出去的內容跟 Meta 的回應寫進資料庫，不是為了漂亮，是為了有一天你需要它。

三、事件時間戳

event_time 是 Unix 秒，不是毫秒。乘錯一千倍會變成幾萬年後的時間，Meta 直接拒收。

另一個是過期。Meta 只收七天內的事件，補送歷史資料的時候這個限制會咬人——送出去也不會報錯，就是不會計入歸因。所以要重播舊事件的話，先算一下那批資料的日期，超過七天的部分做了也是白做。

四、測試碼有沒有跟著這一次的請求

這一步是「事件有進去，但測試事件面板看不到」的真正原因。

測試事件面板只顯示帶了 test_event_code 的請求。你在面板上拿到的那組碼（TEST12345 那種）必須跟在這一次 API 呼叫裡，而且是每一次都要帶。常見的錯是：碼寫在設定檔裡但實際組 payload 時漏了、或者碼過期了（換頁面會重新產一組）、或者你在正式環境測而正式環境的程式碼特意把測試碼拿掉了。

分辨方法很直接：如果事件管理工具的「總覽」有數字在跳、但「測試事件」是空的，那事件其實有進去，只是沒帶碼。這種情況你的 CAPI 是好的。

五、最後才回頭看前端有沒有觸發

順序放最後是有原因的。前端是最容易改也最容易改壞的一層，先動它等於在還沒定位問題前就製造新的變數。

真的要查的話，不要用「我點了按鈕應該有送吧」來判斷。打開瀏覽器的網路面板，篩掉其他請求只看送到你自己端點的那幾筆，看它有沒有出現、狀態碼是什麼、送了什麼內容進去。

用 navigator.sendBeacon 送的請求特別要注意，它設計上就是不回傳結果的，失敗跟成功在前端看起來一模一樣。同理，fetch(...).catch(() => {}) 這種寫法會把所有錯誤吃掉。這兩個模式在導頁前送事件的場景很常用，也因此掩蓋了大量的失敗。

那個順序為什麼重要

我看過的案例裡，至少一半的時間花在改前端，而問題出在第一步或第四步。改前端沒有錯，只是在還不知道事件到底有沒有進去的時候改，你不會知道自己的改動有沒有效果——面板一樣是空的，於是繼續改，越改越亂。

先確定終點收到了什麼，再往回追。這個順序適用於任何一條有中繼站的資料鏈，不只是 CAPI。

轉換 API 設好了，測試事件面板卻是空的——五個地方依序查