出價要求與最佳操作實例
出價整合要求
為了執行正確且最理想的整合程序，所有內部整合皆必須符合以下條件。
- 為全部可得標的廣告展示次數（例如非直接銷售廣告）傳送要求。
- 僅為每次展示機會傳送 1 個要求。
- 請勿就同一個廣告單位合併出價和標準（又稱為標籤）要求。
- 請勿就同一展示機會同時傳送瀑布流式策略和出價要求。
- 使用相應的失標代碼傳送得標、失標和逾時通知。
- 使用 Audience Network SDK 從用戶端獲取
buyeruid。buyeruid是使用 Audience Network SDK 中的getBidderToken方式在用戶端產生的用戶出價者憑證。 - 使用 Audience Network SDK 檢索和呈現廣告。
- 僅在出價贏得競投後才要求刊登廣告。
- 使用驗證憑證（應用程式密鑰和要求編號）傳送出價要求。
- 在每個要求中加入 HTTP 標頭，並呼叫
x-fb-pool-routing-token，當中包含出價者憑證作為其值。 - 在同時使用傳統瀑布流式策略與出價機制時，就前者的其他需求來源設定多個底價限。一般而言，我們建議開始時先設定兩個底價。如此一來，您便可以更精細地控制競投與瀑布流式策略競爭的方式，從而提高整體收益。
如要進一步了解如何同時使用出價與現有瀑布流式策略，請參閱整合出價式競投與現有瀑布流式策略
出價最佳操作實例
除了滿足最佳整合條件之外，我們亦建議遵照以下最佳操作實例操作。
- 將出價要求的逾時值最少設定為 1 秒。
- 在伺服器中為每一個出價要求擷取 BidderToken。
- 為每個要求傳送不重複的編號。
- 找出狀態代碼為 200 以外的出價回應，讀取並記錄當中的
x-fb-an-errorsHTTP 標頭，以用於解決疑難。 - 讀取並記錄所有出價回應的
x-fb-an-request-idHTTP 標頭，以用於解決疑難。 - 出價時使用現有的版位編號，而非建立新廣告版位，除非您正在進行 A／B 測試，或您使用的合作夥伴平台要求建立新廣告版位。
- 儘可能採用伺服器至伺服器整合，從而將處理程序和網絡使用從用戶的裝置和網絡轉移至發佈者的伺服器和網絡，並允許在不更改應用程式的情況下修改出價和競投。
- 在要求中加上
Content-Encoding:gzip標頭，便可以傳送 gzip 壓縮檔格式的要求正文。 - 請勿在出價時使用底價，否則會被略過。