竞价要求和最佳实践
竞价集成要求
为实现正确和最佳的集成，所有内部集成都必须遵循以下条件。
- 为全部可得标的广告展示（例如，非直接销售）发送请求。
- 只为每个展示机会发送 1 次请求。
- 不合并同一广告单元的竞价请求和标准请求（又称为“标签请求”）。
- 不为同一展示机会同时发送与瀑布策略和竞价相关的请求。
- 使用相应失标代码发送得标、失标和超时通知。
- 使用 Audience Network SDK 从客户处获取
buyeruid。buyeruid是由客户端使用 Audience Network SDK 中的getBidderToken方法生成的用户竞价方口令。 - 使用 Audience Network SDK 检索和呈现广告。
- 只在竞价赢得竞拍时发送广告请求。
- 使用身份验证口令（应用密钥和请求编号）发送竞价请求。
- 为每个请求添加
x-fb-pool-routing-tokenHTTP 标头，其值为竞价方口令。 - 若将传统瀑布策略与竞价结合使用，请为其中的其他需求来源设置多个底价。一般而言，开始时先设置两个底价是不错的选择。如此一来，便能更精细地控制竞拍与瀑布策略之间的竞争方式，从而提高整体收益。
如要详细了解如何将竞价与现有瀑布策略结合使用，请参阅将基于竞价的竞拍与现有瀑布策略集成
竞价最佳实践
除了上述最佳集成条件外，我们还推荐您采用以下最佳实践。
- 将竞价请求的超时值至少设置为 1 秒。
- 在服务器上为每个竞价请求获取竞价方口令。
- 为每个请求发送唯一的编号。
- 读取并记录竞价响应（状态代码并非 200）中的
x-fb-an-errorsHTTP 标头，以用于解决问题。 - 读取并记录全部竞价响应中的
x-fb-an-request-idHTTP 标头，以用于解决问题。 - 竞价时使用现有的版位编号，而非创建新编号，除非正在进行 A/B 测试，或正在使用需要创建新版位的合作伙伴平台。
- 尽量使用服务器到服务器集成，以便将处理流程和网络使用量从用户的设备和网络转移至发行商的服务器和网络，并实现在不更改应用的情况下修改竞价和竞拍。
- 如果您在请求中提供
Content-Encoding:gzip标头，则可以传递 gzip 压缩形式的请求正文。 - 竞价时请勿使用底价，因为系统会忽略底价。