fbclid 有帶進來，Meta 卻對不上——問題出在你什麼時候記下它

太長不看版： fbc 這個欄位是四段組出來的，其中一段是時間戳，而它必須是你第一次看到那個 fbclid 的時間。很多實作在送事件的當下才現組，時間戳就變成了轉換發生的時間，跟 Meta 手上的點擊時間差了幾分鐘到幾天。參數本身沒掉，比對卻會爛掉。

fbc 長什麼樣

從廣告點進來的網址會帶一個 ?fbclid=IwAR...。瀏覽器端的像素會拿它組成一個叫 _fbc 的 cookie，格式是四段用點連起來：

fb.1.1723694400000.IwAR2xxxxxxx

第一段固定 fb，第二段是子網域層級，第三段是毫秒時間戳，第四段是原始的 fbclid。伺服器端送 CAPI↗ 的時候，user_data.fbc 要放的就是這一整串。

關鍵在第三段。它代表的是這個點擊發生的時間，不是這個事件發生的時間。

為什麼容易寫錯

寫成錯的版本非常自然。你的後端在收到轉換的那一刻，手上有 fbclid（從表單或 session 帶過來的），於是就地組一個：

// 這是錯的
const fbc = `fb.1.${Date.now()}.${fbclid}`;

程式不會報錯，Meta 也不會退件，events_received 照樣回 1。表面上一切正常。

但如果使用者是昨天點的廣告、今天才回來填表，這個時間戳就差了一天。Meta 拿它去對自己的點擊紀錄，對不到那一筆。你會看到事件量正常、比對率偏低，然後開始懷疑是不是雜湊做錯了。

正確的做法

第一次看到 fbclid 的時候就把時間鎖住，之後只讀不重算。

// 落地頁第一次載入，網址有 fbclid 時
if (fbclid && !getCookie('_fbc')) {
  setCookie('_fbc', `fb.1.${Date.now()}.${fbclid}`, { days: 90 });
}
// 之後所有事件都直接讀這個 cookie 的完整字串，不要重組

實務上如果你的頁面本來就有裝 Meta 像素↗，_fbc 這個 cookie 它會自己寫。這種情況你要做的只有一件事：把 cookie 原樣讀出來送去 CAPI，不要自己拼。會出事的通常是沒有像素、或者像素在 GTM↗ 裡因為同意設定沒有載入的頁面。

跨頁跟跨網域的部分

麻煩的是使用者很少在同一個頁面完成轉換。

同網域跳轉沒問題，cookie 跟著走。但只要換了網域（落地頁在 A 站、註冊在 B 站），cookie 就過不去，得靠網址參數把值帶過去，落地頁那端再重新寫入 cookie。這時候要傳的是已經組好的完整 fbc 字串，不是原始的 fbclid，否則第二站又會用自己的當下時間去組，前面鎖時間戳的工就白做了。

導去外部通訊軟體的情況更麻煩。網址參數在跳轉的過程中常常被吃掉，這條斷點我們單獨寫過一篇：LINE 加好友廣告的歸因為什麼會斷。

怎麼確認自己做對了

三個檢查，都不需要等數據跑出來：

打開落地頁（網址後面自己加一個假的 ?fbclid=test123），在瀏覽器主控台輸入 document.cookie，看有沒有 _fbc，第三段是不是現在的時間。然後隔幾分鐘重新整理一次，第三段不應該改變——會變就表示你每次載入都在重寫。

最後看你實際送出的 CAPI payload，fbc 欄位要跟 cookie 裡的字串一字不差。

一個常被忽略的順序問題

如果你的落地頁是先跳轉再落地（例如中間有一層分流或短網址），fbclid 要在第一跳就抓下來。等到最後一站才抓，前面每一跳都有機會把參數掉掉，而你會以為使用者是自然流量。

自然流量的比例莫名其妙地高，通常就是這個原因，不是真的有人在搜尋你。

歸因的完整鏈路（從落地頁抓參數、跨站接力、到伺服器端補送）寫在 iGaming 買量實戰課的第 5、6 章，含可以直接用的接收端程式碼。事件送不出去的那一類問題，另外看轉換 API 測試事件面板空白的五個排查點。參數都對了但三個後台的數字還是對不齊，看Meta 說 50 筆、GA4 說 32 筆、業主後台說 21 筆。

了解我們的廣告代投服務 →

fbclid 有帶進來，Meta 卻對不上——問題出在你什麼時候記下它