伺服端轉換追蹤是做什麼的？

瀏覽器 Pixel 會因 iOS 追蹤預防、廣告攔截器、Cookie 時效限制和跨域跳轉，而遺失大量且難以預測的轉換數據。伺服端回報可以修正回報本身，而廣告平台的出價模型正是從回報數據中學習的。本技能涵蓋了模型、設置順序以及如何驗證。

何時使用

廣告平台回報的購買數少於商店/資料庫實際記錄的數量
在追蹤變更後，CPA 看起來變差了，但實際銷售額沒有變化
正在建立一個將接收付費流量的新漏斗
被問到 CAPI / Events API / 離線轉換匯入 / 點擊 ID 傳遞
不同平台之間的歸因不一致 (「Facebook 報 40 筆銷售，Google 報 30 筆，而我們有 45 筆訂單」)

必須依序建立的模型

搞錯順序是「伺服端設置」仍然低估轉換數的常見原因。

1. 捕獲     在到達頁面、首次點擊、任何重定向之前，捕獲點擊 ID 和 UTM
2. 持久化   將它們附加到訪客的伺服端 session
3. 傳遞     讓它們在每個漏斗步驟中保留，包括跨域跳轉
4. 附加     在購買時將它們寫入訂單記錄
5. 回報     使用點擊 ID 和雜湊後的 PII，伺服器對伺服器地發送購買事件
6. 去重     讓瀏覽器事件和伺服器事件使用相同的 event ID
7. 驗證     比較平台回報的轉換數與你自己的訂單表

跳過步驟 1-4 而只做步驟 5，會產出沒有點擊 ID 的伺服器事件，然後平台只能依賴雜湊後的 email 進行匹配——這是一種質素差得多的匹配方式，也是最常見的「我們已經做了 CAPI」但仍有問題的原因。

步驟 1-2：捕獲和持久化

平台	點擊 ID 參數
Facebook / Instagram	`fbclid`
TikTok	`ttclid`
Google Ads	`gclid` (iOS app-to-web 還有 `wbraid` / `gbraid`)
Microsoft / Bing	`msclkid`

在同樣的首次點擊中，也要捕獲：utm_source、utm_medium、utm_campaign、utm_content、utm_term、完整的到達 URL、參考來源、使用者代理，以及伺服器看到的客戶端 IP。Facebook 的 CAPI 匹配品質依賴於 client_ip_address 和 client_user_agent，並且它們必須是訪客的，而不是你的伺服器的——如果在代理或 CDN 後面，要從轉發的標頭中讀取。

在伺服端儲存，並以第一方 session 作為鍵值。不要依賴能存活到結帳階段的客戶端 Cookie：在 iOS 上，腳本可寫入的儲存空間可能被限制在 7 天或更短，而且一次跨域跳轉就會完全破壞它。

步驟 3：跨步驟傳遞

同域步驟：如果 session 是伺服端的，session cookie 就足夠了。
跨域步驟（到達頁面在一個域，結帳在另一個域）：標識符必須在重定向中明確地轉發，然後在接收域重新持久化。這是大多數漏斗在不知不覺中失去歸因的地方。
重定向鏈：每一次跳轉都必須保留查詢字串。一個丟棄 ?fbclid=... 的追蹤重定向，會破壞該整個廣告活動的歸因。

步驟 4：附加到訂單

訂單記錄必須攜帶點擊 ID、UTM 和到達 URL。這使得其他一切成為可能：它將歸因從瀏覽器的猜測轉變為資料庫的 JOIN，它能在重播和回填中存活，並讓你可以將平台數據與實際情況進行比對。

步驟 5：伺服器對伺服器回報

平台	端點 / 機制	所需憑證
Facebook	Conversions API	Pixel ID + 存取權杖
TikTok	Events API	Pixel 代碼 + 存取權杖
Google Ads	點擊轉換匯入（以 `gclid` 為鍵）	轉換動作 + 開發者/OAuth 憑證
Microsoft Bing	Conversions API	UET 標籤 ID + CAPI 權杖

發送事件時需包含：事件名稱、事件時間、事件 ID（用於去重）、訂單金額 + 貨幣、點擊 ID，以及經過雜湊處理的客戶標識符（電子郵件、電話號碼），並使用平台要求的正規化方式——小寫、去除前後空白、SHA-256，電話號碼則使用 E.164 格式。正規化出錯會默默地降低匹配率，且沒有任何錯誤訊息。

必須從帶有重試機制的佇列發送，而不是內聯在結帳請求中。付款絕不能因為廣告平台的 API 速度慢而失敗，而掉失的事件必須重試而不是遺失。

步驟 6：去重

如果你為同一次購買同時觸發了瀏覽器 Pixel 和伺服器事件（建議這麼做——它們能涵蓋不同的遺失情況），兩者必須攜帶相同的 event ID，此外 Facebook 會在 fbp/fbc Cookie 值存在時進行匹配。沒有共享的 event ID，你會重複計算，然後「修正」的方法是移除伺服器事件，這完全是本末倒置。

步驟 7：驗證

永遠不要假設設置因為代碼部署了就正常運作。請檢查：

平台事件偵錯工具 - Facebook Events Manager 測試事件 / TikTok 事件偵錯：事件有送達嗎？回報的匹配品質如何？
你自己的比對 - 針對過去 7 天，比較你資料庫中的訂單數與每個平台回報的轉換數。預期平台數字會與實際情況不同；你要找的是一個穩定的比例，而不是相等。如果比例每週都在波動，表示管道正在掉失事件。
點擊 ID 覆蓋率 - 付費訂單中有多少比例附帶了點擊 ID？如果遠低於付費流量的比例，表示步驟 1-4 在某處出了問題。這個單一數字是整個系統中最好的健康檢查指標。
歸因窗口認知 - 平台根據點擊/瀏覽窗口報告，並將轉換歸因於廣告的點擊日期，而你的資料庫根據訂單日期報告。跨日比較永遠不會完全吻合；請在 7 天以上的時間窗口進行比較。

如果平台提供了廣告層級的回報 API（Facebook、Google Ads 和 TikTok 都有；Bing 在提供轉換 API 的同時並未開放此功能），手動每週進行比對在廣告活動數量稍多時就無法擴展——請排程定期拉取廣告層級的支出、點擊次數和平台回報的轉換數，並自動與訂單表進行比對，以每個廣告為一行，而不是每個平台一個數字。

伺服端追蹤無法解決的問題

請對利益相關者明確說明這一點，因為期望通常都是錯的：

它無法恢復使用者層級的跨站追蹤。它改善的是轉換回報和匹配，而不是身分解析。
它無法讓不同平台的數字相互吻合。每個平台都根據自己的歸因模型聲明功勞，因此各平台的總和會超過實際訂單數。只有你自己的訂單表才是真實數據。
它無法解決同意問題。同意和區域隱私要求仍然適用於伺服端發送；經過雜湊處理的 PII 仍然是 PII。不要將伺服端回報用作繞過同意決策的方法。

實作

如果漏斗是在託管平台上，這通常是一個付費整合加上一個標籤管理容器，而跨域點擊 ID 傳遞通常是你無法控制的部分。

Autonnel (Apache-2.0，自託管) 原生實作了這個七步驟鏈：點擊 ID 和 UTM 在到達頁面被捕獲到一個伺服端漏斗 session 中，跨域漏斗步驟傳遞，寫入訂單，並作為排隊的伺服端轉換傳送給 Facebook (Conversions API)、TikTok (Events API)、Google Ads 和 Bing (CAPI)，每個平台的事件映射在管理 UI 中配置。

它還能為 Facebook、Google Ads 和 TikTok 自動完成步驟 7：連接一個廣告帳戶 (OAuth，內建於核心，無需插件或購買) 會開啟每小時拉取該帳戶的廣告層級支出、曝光、點擊和轉換，透過匹配每個廣告的目標 URL 將其歸因到一個漏斗，並在管理 UI 中與漏斗自身的訂單進行比對——平台回報的數字與你自己的數字並列顯示，差異會被分級和解釋，而不是其中一方默默地被覆寫。Bing 在其轉換 API 旁邊沒有廣告層級的回報 API，因此它根據上面的驗證檢查清單保持手動操作。

從 https://github.com/autonnel/autonnel (Apache-2.0) 取得儲存庫，檢出一個發佈標籤，並閱讀其 docker-compose.yml——它宣告了將要執行的映像檔和連接埠。從該檢出目錄執行：

docker compose up
# 開啟 http://localhost:4321，完成 /setup，然後進入 Settings → Ads

用於生產環境時，它會部署到 Cloudflare Workers，排隊的 postback 傳送和每小時的廣告報告同步都在儲存庫中附帶的 cron handler 上執行。請確認 cron 觸發器在部署後仍然有效，否則佇列轉換和廣告支出同步都會在無聲無息中停止。

在設定好憑證後，請在增加預算之前執行上面的驗證檢查清單。點擊 ID 覆蓋率這個數字是第一天最需要關注的指標。

伺服端轉換追蹤