Jul 17, 2026·6 分鐘閱讀
出價請求 (OpenRTB)
出價請求是廣告交易平台發送給競價者（DSP）以描述可用庫存的訊息。根據 IAB OpenRTB 規範定義，它包含頁面 URL、裝置資訊、使用者 ID，以及一個或多個
Imp（曝光）物件——每個物件代表一個特定的廣告版位。交易平台期望在嚴格的逾時時間內（通常為數十到數百毫秒）收到出價回應。逾時的回應將被丟棄，使得出價請求處理成為核心的延遲挑戰。
什麼是出價請求
出價請求是程序化廣告中供應的基本單位。當用戶載入頁面或應用程式時，發布商的廣告伺服器會呼叫廣告交易平台，後者將 OpenRTB BidRequest 物件廣播給所有連接的 DSP。
出價請求中的關鍵元件
- Imp 物件 — 每個描述一個廣告版位：尺寸、底價、允許的創意類型，以及可選的
Banner、Video或Native子物件。 - Site/App 物件 — 發布商網域、內容類別和庫存類型。
- Device 物件 — 作業系統、瀏覽器、IP、設備型號和地理位置。
- User 物件 — 匿名 ID（Cookie、設備 ID 或 PPID）和可選的區段。
- Regs 物件 — 法規標誌，如 COPPA、GDPR 或 CCPA。
單個請求可以捆綁多個 Imp 物件（例如，一個 300×250 橫幅加上一個 728×90 排行榜）。DSP 必須決定對哪些（如果有的話）進行出價，並根據 Imp.id 返回回應。
所以呢： 出價請求是每次拍賣的原始材料。其豐富程度決定了 DSP 對曝光價值的評估能力。稀疏或不準確的請求會導致糟糕的出價決策。
計算方式
Bid Request 並非「計算」而得，而是由交易所根據發布商供應訊號建構而成。Bid Request 的數量即為交易所在特定期間內發送給競價者的 BidRequest 訊息總數。
Bid Requests = 發送的 BidRequest 訊息數量
重要注意事項
- 多重廣告版位請求 — 一個包含 3 個 Imp 物件的單一 BidRequest 仍算 1 次 Bid Request，而非 3 次。若需廣告版位層級的數量，請改計算
Imp物件。 - 重複請求 — 部分交易所會將同一曝光機會發送給多個競價者（多重傳送）。每次傳送皆視為獨立的 Bid Request，這會使請求數量高於實際廣告呼叫數。
- 過濾請求 — 驗證失敗（例如缺少必要欄位）的請求通常會被記錄為錯誤，而非 Bid Request。請確認您交易所的定義。
- 逾時捨棄 — 逾時未收到回應的 Bid Request 仍計為一次請求，被捨棄的是 DSP 的回應。
所以呢： 比較 Bid Request 數量與 Bid Response 數量，可了解 DSP 實際評估了多少機會。兩者差距過大通常表示存在逾時或流量限制問題。
如何在儀表板中解讀
出價請求量是一個漏斗頂端的指標。數值高表示DSP看到許多機會；數值低可能表示連線問題、流量低或節流。
搭配什麼一起看
- 出價回應率 — 出價回應 / 出價請求。比率低表示DSP跳過許多請求（節流、資料品質差或處理緩慢）。
- 贏得率 — 贏得的曝光 / 出價回應。如果請求量高但贏得率低，表示出價策略或價格有問題。
- 平均延遲 — 從收到請求到發送回覆的時間。如果延遲接近超時，回覆會被丟棄，降低有效回應率。
常見的儀表板誤讀
出價請求突然飆升常被解讀為「更多供應」。但如果飆升來自低品質庫存（例如MFA網站、無效流量），DSP會浪費運算資源卻無法贏得有價值的曝光。務必按庫存層級進行區分。
所以呢： 將出價請求量視為健康訊號，而非成功指標。真正的問題是：這些請求中有多少能帶來有利可圖的贏得？
通常影響此指標的因素
出價請求量主要由交易平台連接和流量品質篩選器控制。DSP 無法增加發布商供應量，但可以影響其接收和處理的請求數量。
增加出價請求量的槓桿
- 連接更多交易平台 — 每個新的交易平台整合都會增加請求串流。
- 啟用更多供應類型 — 公開交易平台、PMP 交易和直接庫存都會產生不同的請求流程。
- 減少限流 — 如果 DSP 設定了每秒查詢數 (QPS) 上限，提高上限可讓更多請求進入。
- 擴大定向範圍 — 移除地理位置、裝置或類別限制，可讓更多請求通過預先出價篩選器。
減少出價請求量的槓桿
- 流量品質篩選器 — 封鎖 MFA、專為廣告製作或低可見度的網域，可減少請求數量但提升平均品質。
- 供應路徑優化 (SPO) — 偏好直接 SSP 連線而非轉經銷商，可減少重複請求。
- 使用者同意限制 — GDPR/CCPA 的選擇退出會減少可定址的請求池。
取捨
- 更多請求 ≠ 更多收入。 用低品質庫存淹沒出價系統會增加運算成本，並可能降低模型準確度。
- 積極限流可保護基礎設施，但可能錯過有價值的曝光。需在 QPS 限制與預期勝出價值之間取得平衡。
- 過早篩選（在出價模型執行前）可能會封鎖那些表面上看起來廉價但價值高的曝光。應使用分層篩選：先進行低成本預先出價檢查，再進行高成本模型評估。
結論： 優化目標應為有價值的請求量，而非原始數量。一個能處理 50 萬個高品質請求的 DSP，其表現通常優於被 500 萬個低品質請求淹沒的 DSP。
公式
多個 Imp 的請求計為 1 個出價請求。請查閱您的交易平台對過濾或錯誤請求的定義。
適用場景
超時陷阱
某DSP發現競價請求量穩定在每日200萬次，但競價回應率從85%降至60%。
發生了什麼： 交易平台將超時時間從150毫秒縮短至80毫秒。該DSP的模型因速度太慢而無法及時回應。
解決方法： 分析模型推論延遲。將繁重處理（如用戶分群、廣告素材選擇）移至預先計算層。在競價器中加入超時防護機制，跳過無法及時處理的請求。
重點： 回應率下降通常指向延遲問題，而非供應量減少。
重複請求洪水
某DSP整合新的SSP後，競價請求量一夜暴增40%。勝率持平，但運算成本飆升。
發生了什麼： 新的SSP將同一曝光發送給多個競價者（多路複用）。該DSP看到的請求量是實際供應量的1.4倍。
解決方法： 使用交易平台的
request_id或imp.id加seat組合進行請求去重。或採用SPO規則優先選擇直接連接。重點： 並非所有請求增長都代表真實供應增長。擴展基礎設施前務必先去除重複。
品質過濾矯枉過正
某家居服務廣告主的DSP封鎖了所有可視率低於50%的網域請求。競價請求量驟降70%，但勝率幾乎未提升。
發生了什麼： 可視率門檻對該廣告主的利基市場過於嚴格。許多合法的本地新聞網站未達標準，導致廣告活動供應枯竭。
解決方法： 使用較寬鬆的過濾方式（例如降低權重而非直接封鎖），或僅在競價模型對曝光評分後才套用過濾。以保留組進行測試。
重點： 過度過濾供應可能扼殺廣告活動的投放量。務必根據實際勝率數據驗證品質門檻。
常見誤區
將出價請求量視為成功指標
更多出價請求並不代表更多收益。一個吹噓「每秒處理1000萬次請求」的DSP可能是在浪費運算資源處理無效廣告庫存。
替代做法： 同時追蹤出價回應率和勝率以及請求量。按廣告庫存層級（優質、標準、長尾）分類請求，以了解價值來源。
忽略多重曝光乘數效應
一個包含5個曝光物件的單一出價請求仍算1次請求。若用請求數估算廣告版位量，會低估5倍。
替代做法： 計算
Imp物件進行版位層級分析。僅將出價請求數用於基礎設施擴展和超時監控。假設所有廣告交易平台計算請求方式相同
部分交易平台將過濾請求（如無效使用者代理）計入出價請求，其他則不計入。部分計算重試次數，其他則不計算。
替代做法： 閱讀各交易平台的文件。跨平台比較時，使用一致定義進行標準化（例如僅計算到達出價器模型的請求）。
總結
出價請求是驅動每次程式化拍賣的原始訊號。其數量很重要，但只有與回應率、勝出率和品質分層搭配時才有意義。
- 計算請求，但重視曝光。 高數量但低品質只是雜訊。
- 注意延遲。 一個快速但錯過逾時的模型是無用的。
- 按來源分層。 並非所有交易平台或庫存類型都相同——應分別衡量。
快速檢查
確認您已理解本文內容。
single
一個出價請求包含 3 個曝光物件。這代表幾個出價請求？
請選擇答案
參考來源
- IAB Tech Lab OpenRTB 規格 — 概念參考 (https://iabtechlab.com/standards/openrtb/)
- OpenRTB 2.6 PDF — 出價請求與曝光物件定義 — 概念參考
- Google Ad Manager 說明 — 出價請求概覽 — 概念參考
僅供學習，不構成投放建議。