Outbrain S2S 追蹤：Postback 設定步驟詳解

Outbrain 伺服器對伺服器 (S2S) 追蹤運作分為三個步驟：您在到達頁透過在追蹤網址附加 {{ob_click_id}} 巨集來擷取 Outbrain 的唯一點擊識別碼，將該 ID 儲存在訪客的 session 中，當轉換發生時，您的伺服器會發送一個 HTTP 請求——即 postback——到 Outbrain 的追蹤端點，攜帶儲存的 ID 和轉換事件名稱。Outbrain 將 ID 與原始點擊進行匹配，並將轉換功勞歸於確切的廣告活動、廣告素材及發布商版位。無需瀏覽器像素，這意味著不會因廣告攔截器或 Safari 的 Cookie 限制而損失數據，即使轉換在數天後於客服中心或 CRM 中發生，也能獲得準確的歸因。

為何在原生流量上 S2S 優於僅使用像素追蹤#

原生流量是客戶端追蹤最惡劣的環境。您的廣告在內容網站上投放，這些網站廣告攔截器使用率高，很大一部分點擊來自具有嚴格追蹤防護的 Safari 行動瀏覽器，而且——如果您投放名單開發或貨到付款 (COD) 的廣告——轉換通常根本不會在瀏覽器中發生。Postback 是伺服器對伺服器的 HTTP 呼叫，因此上述問題皆不適用：只要您的伺服器知道轉換發生，Outbrain 就能得知。

實際的利害關係在於優化，而不僅僅是報表。Outbrain 的競價及您自身的版位決策，其品質僅取決於餵入的轉換數據；像素默默地遺失一部分轉換，會讓盈利的發布商版位看起來不盈利，導致您砍掉贏家。嚴謹買家的標準設定是將 S2S 作為單一真實來源，並搭配頁面像素作為備援檢查——所有主要的廣告追蹤工具都預設支援 Outbrain 範本。（在逐步教學前先說明一個命名注意事項：Outbrain 的廣告主平台稱為 Amplify，且 Outbrain 本身已與 Teads 合併——本文描述的追蹤架構屬於 Amplify 端，且在合併後保持不變。）

步驟 1：將點擊 ID 傳入您的銷售漏斗#

Outbrain 提供動態巨集，這些巨集會在點擊時被替換為實際值。在您的廣告追蹤網址中，附加點擊識別碼——同時，也附加您後續優化時會需要的版位元數據：

https://your-lander.com/offer
  ?ob_click_id={{ob_click_id}}
  &publisher={{publisher_name}}
  &section={{section_id}}
  &campaign={{campaign_id}}

媒體買家常使用的主要巨集：

巨集的可用性會演變，因此在最終確定範本前，請至 Outbrain 廣告主文件 確認當前清單。您這邊的參數名稱（ob_click_id=、publisher=）可自行選擇——只有 {{…}} 標記是 Outbrain 的。

接著確保 ID 能在銷售漏斗中存活。如果您使用追蹤工具，其點擊網址會自動擷取所有內容。如果您使用第一方追蹤，請在到達頁將點擊 ID 儲存在 Cookie 或 session 記錄中——並稽核廣告與到達頁之間的任何重定向，因為剝離查詢字串的重定向是 Outbrain S2S「無法運作」最常見的單一原因。我們的重定向鏈詞彙條目說明了如何追蹤重定向鏈。

步驟 2：發送 postback#

當轉換事件發生時——銷售、名單、合格通話——您的伺服器呼叫 Outbrain 的追蹤端點，並攜帶儲存的點擊 ID 和事件名稱：

https://tr.outbrain.com/pixel?ob_click_id=STORED_CLICK_ID&name=purchase

有兩件事必須對齊。首先，name 值必須與您在 Amplify 轉換設定中建立的伺服器對伺服器轉換事件名稱完全相符——事件名稱不匹配會無聲地失敗，這是第二常見的設定失敗原因。其次，點擊 ID 必須是 Outbrain 提供給您的原始值，未經修改或截斷。該端點也接受訂單價值和貨幣的參數，以便營收數據流入 Amplify 的 ROAS 欄位；請查閱當前的轉換文件以獲取確切的參數名稱，而非猜測。

先在 Amplify 中設定事件（轉換區塊 → 新增轉換 → 伺服器對伺服器類型），然後手動發送測試：點擊您自己的真實廣告、擷取 ID、使用 curl 發送 postback，並確認轉換已註冊。儀表板上的歸因可能需要一段時間才會顯示，因此在斷定失敗前請給予時間。

步驟 3：驗證與品質保證整個追蹤鏈#

在信任數據前，執行此檢查清單：

• 端到端測試轉換應來自真實裝置上的真實廣告點擊，而非模擬網址——模擬的 ID 無法與 Outbrain 端的點擊匹配。
• 檢查點擊 ID 是否成功送達您的追蹤工具或資料庫，包含所有到達頁變體，行動版亦同。
• 檢查銷售漏斗的重定向——每個跳轉都必須轉發查詢參數。
• 確認 postback 中的事件名稱與 Amplify 轉換設定中的名稱字元完全相符。
• postback 呼叫使用 HTTPS，且來自您的生產伺服器，而非會將測試事件發送到即時統計數據的測試環境。
• 若同時使用像素與 postback，請進行去重複——決定每種事件類型的標準來源，否則您的 CPA 看起來會比實際情況好。

完成以上步驟後數據仍有問題？請比較時間窗口：您的追蹤工具根據點擊時間歸因，Amplify 則在其轉換窗口內歸因——跨月的轉換會落入不同的時間區段，這將折磨負責對帳的人員。這一切的整體架構在我們的轉換追蹤入門指南中有涵蓋。

使用 Amplify API 自動化流程#

Postback 完成了數據迴圈；Amplify API 則讓您能根據數據以程式化方式採取行動。Outbrain 為廣告主提供 REST API（使用您的 Amplify 憑證進行身份驗證以取得 token，然後在後續呼叫中將其作為標頭發送——開發者文件涵蓋了當前的流程），其端點可用於廣告活動管理、預算設定，以及按發布商和版位細分的成效報表。

對於已部署 S2S 的帳戶，核心的自動化工作是：將您的 postback 轉換數據與來自報表 API 的版位層級花費進行關聯，然後將封鎖決策推送回去——任何花費超過目標 CPA 倍數且零轉換的版位，將按排程被加入廣告活動的封鎖清單。這與Outbrain 購買手動操作時要求的「砍掉輸家」原則相同，只是現在每小時自動執行，不帶情緒。大量廣告素材上傳以及每日花費同步至資料倉儲，是另外兩個值得投入整合工作的任務。

每個原生廣告網路上的相同模式#

一旦 Outbrain 整合成功，您就建立了一個範本，而非一次性方案。Taboola、MGID、Revcontent 及其他網路都採用完全相同的架構，只是詞彙不同：追蹤網址中的點擊 ID 巨集、儲存的識別碼，以及一個接受該 ID 加上事件名稱的網路 postback 端點。可以直接轉移的部分是您銷售漏斗的參數衛生（保留查詢字串的重定向）、您的伺服器端轉換擷取邏輯，以及您的去重複邏輯；每個網路不同的部分則是巨集語法、端點網址，以及在各個控制台設定事件的位置。跨網路投放的買家通常會在第一天就將所有數據標準化到其追蹤工具的 sub-ID 架構中——相同的欄位總是承載版位資訊，相同的欄位總是承載廣告素材資訊——這樣跨網路報表就能無需轉譯地對齊。趁您只有一個網路時就設定好這個慣例，那麼第二個和第三個整合就會變成只需一個下午的工作。

閱讀追蹤鏈的另一端#

以上所有內容都是針對您自己的銷售漏斗進行部署——但同樣的機制也可以從外部觀察到其他人的漏斗。網路上每個 Outbrain 廣告都公開攜帶著其追蹤堆疊：重定向鏈、追蹤工具網域、傳遞給到達頁的參數。OpenAdLibrary 大規模擷取這些資訊——索引包含超過 108,000 個即時的 Outbrain 廣告素材（2026 年 7 月），並追蹤了跨網路的超過 130 萬次到達頁擷取——因此您可以查看競爭對手透過哪些追蹤工具和預先到達頁來路由哪些廣告，以及每個銷售漏斗的存活時間。存活時間是關鍵指標：一個持續投放數週的銷售漏斗，其追蹤數據顯示它是盈利的。Outbrain 廣告間諜指南涵蓋了研究流程，而 Outbrain 間諜工具 則是執行研究的地方。

S2S 追蹤只需一個下午即可設定完成，它是 Outbrain 帳戶中槓桿效益最高的基礎建設：下游的每個優化決策——廣告素材剔除、版位封鎖、出價調整、擴量決策——其準確性都繼承自這一個整合。確保點擊 ID 完整通過銷售漏斗，確保事件名稱匹配，使用真實的測試轉換進行驗證，然後才開始信任這些數據，並據此進行自動化。