競價延遲

拍賣延遲是指從發布商的廣告伺服器發送出價請求到收到最終決定（勝出出價、廣告素材網址或回傳）之間的實際時間。這是一個平台層級的指標，因為拍賣基礎設施——廣告交易平台、SSP、標頭競價包裝器——控制了大部分時間。

延遲並非單一數字，而是一條鏈：

• 網路往返——請求到達出價方並返回回應。
• 出價方處理——出價方評估用戶、應用底價及執行內部拍賣的速度。
• 包裝器瀑布流——在標頭競價中，每個適配器會等待其超時後才執行下一個。
• 廣告伺服器決策——最終的伺服器端呼叫，選出勝出者。

用戶可見的成本

每增加 100 毫秒的延遲，就會降低頁面瀏覽完成率。在行動裝置上，由於網路條件較差且用戶耐心不足，這種影響會更加嚴重。只優化填充率或勝出率而不監控延遲的平台，通常會降低可視度，並諷刺地導致有效千次曝光成本下降，因為較少的曝光能完整呈現。

拍賣延遲 = 收到決策時間 − 發出出價請求時間

所有時間皆在平台端（SSP、廣告交易平台或標頭競價包裝器）測量。單位為毫秒。

重要注意事項

• 起始點不同。 部分平台從廣告請求離開瀏覽器時開始計算；其他則從進入競價引擎時開始。請務必查閱供應商的定義。
• 超時 ≠ 延遲。 500 毫秒的超時設定並不代表每次競價都耗時 500 毫秒。延遲是實際時間，應遠低於超時設定。
• 彙總數據會隱藏極端值。 平均延遲可能看起來正常，但第 95 百分位數卻可能造成實際用戶體驗問題。請分別監控 p50、p95 和 p99。
• 不包含素材下載時間。 延遲計算在收到決策時結束，而非廣告渲染完成時。渲染時間是另一個指標（通常稱為「素材載入時間」）。

單一的延遲數字幾乎毫無用處。請從分佈角度解讀：

• p50（中位數） — 典型使用者體驗。伺服端競價應低於 200 毫秒，用戶端標頭競價應低於 400 毫秒。
• p95 — 最慢的 5% 競價。若此值超過逾時時間，表示您因逾時而失去競價。
• p99 — 極端異常值。通常由單一慢速競價者或網路短暫異常造成。

搭配指標

• 競價請求 量 — 若延遲突然飆升且競價請求量下降，表示競價可能在請求完成前就已逾時。
• 填充率 — 若延遲高且填充率也高，可能是競價層級過深，為了邊際收益而損害使用者體驗。
• 勝率 — 勝率低且延遲高，通常表示逾時時間過短，競爭性競價者來不及回應。

常見錯誤

常見的 Slack 訊息：「延遲平均 180 毫秒，看起來沒問題，所以我們可以再加兩個競價者。」請先檢查 p95。若 p95 為 900 毫秒，新增的競價者將使延遲超過逾時，您將看不到任何增量收益，同時每個頁面都會變慢。

降低延遲的槓桿

• 縮短超時時間。 Prebid 和大多數 SSP 允許您為每個適配器設定超時時間。將超時時間從 1000 毫秒縮短至 500 毫秒可直接降低 p95 延遲，但可能會遺漏一些回應較慢的出價方。
• 轉向伺服器端拍賣。 伺服器端標頭競價（例如 Prebid Server、Amazon TAM）消除了客戶端瀑布流延遲。代價是對出價方連接的控制較少。
• 減少出價方數量。 每個額外的出價方都會增加網路和處理時間。請測試邊際出價方是否真的能贏得足夠多的次數，以證明其帶來的延遲成本是合理的。
• 優化出價方選擇。 根據使用者區段的歷史勝率使用出價方「簡短清單」。不要呼叫從未在此庫存上獲勝的出價方。
• 使用並行出價。 同時呼叫所有出價方的客戶端包裝器（而非順序呼叫）可將瀑布流壓縮為一次往返。

增加延遲的槓桿（請謹慎使用）

• 增加底價或複雜的交易邏輯。 出價方必須評估的每一條額外規則都會增加處理時間。
• 豐富的使用者訊號。 傳遞完整的使用者 ID、裝置圖譜或自訂區段會增加請求負載大小和解析時間。
• 多格式拍賣。 在同一呼叫中請求影片、展示廣告和原生廣告可能會減慢出價方決策引擎的速度。

權衡取捨

超時時間 vs. 需求深度 是經典的平台權衡。200 毫秒的超時時間可提供出色的使用者體驗，但可能會排除需要 300 毫秒才能回應的出價方。1000 毫秒的超時時間可捕捉更多出價，但會損害可見度和頁面載入速度。

何時不應追求此指標： 如果您的填充率已超過 95% 且可見度良好，則進一步優化延遲可能會因切斷有價值的出價方而減少收入。延遲是一個限制條件，而非目標。在使用者體驗可接受之前進行優化，然後停止。

競價延遲是決定需求深度與用戶體驗之間取捨的時鐘。平台的每個決策——超時長度、出價方數量、伺服器端與客戶端——都會影響這個數字。

• 關注尾部，而非平均值。 p95 和 p99 才能反映真實情況。
• 將延遲與填充率和勝率結合起來看。 一個低延遲但無法贏得任何出價的競價是沒有用的。
• 當用戶體驗可接受時停止優化。 超過這個點，你就是在用收入換取用戶注意不到的毫秒數。