多交易所接入工程清单：Vungle、Pangle与Mintegral

在 App 变现的真实业务场景中，我们几乎不会只对接单一的广告需求方。更为典型的工程架构通常是：采用 TopON（或是 MAX、LevelPlay 等）作为统一的流量聚合层，在其下挂载 Vungle（Liftoff）、Pangle 与 Mintegral 等多家需求源，有时还会进一步叠加 AdMob 或 Unity，最终通过 Mediation 或 In-App Bidding 的方式进行并行询价。对外，各家厂商可能都会声称「我们全面支持 OpenRTB 协议」，但真正在生产环境中决定变现收益能否稳定落袋的，往往是那些隐藏在标准文档之外的工程细节：例如，广告位的三层 ID 应当如何精准映射？各家需求源在扩展字段上的方言差异该如何适配？设备身份在遭遇 ATT 政策限制后产生的标识空洞该怎么填补？端上的超时预算究竟该如何科学切分？实时竞价的金额与瀑布流的历史 eCPM 到底要在哪把尺子下进行混比？此外，还包括激励视频的回调防刷策略，以及 TopON 汇总报表与各家需求源后台之间那几个百分点的账目偏差，到底应当如何归因。

本文将以 Vungle 为主要示例，并对照剖析 Pangle 与 Mintegral 的差异；同时，我们将统一以 TopON 作为聚合层的具名代表。正因如此，本文不会枯燥地复述各家厂商的官方文档，而是严格按照线上生产的真实顺序，将多需求源接入的全流程走透：从角色定位、闭环链路、协议方言，一路打通到超时控制、竞价混比以及最终的财务对账。需要强调的是，即使将需求源替换为 Chartboost 或 Fyber，或者将聚合平台替换为 MAX，同一套底层的工程核对清单依然完全适用。

本文是 卖侧竞价与决策 系列的第 3 篇（多交易所对接）。 全系列 4 篇：

1. Header Bidding：Prebid 客户端与服务端架构解析
2. 媒体 Ad Server 深挖
3. 多交易所接入工程清单
4. SSP Yield 深挖

一句话定位：深度解析多需求源接入的端上工程细节，涵盖三层 ID 映射、协议方言、超时切分、混比逻辑及三角对账等变现核心链路。

范围划界：在本文的语境下，TopON 扮演的是聚合与决策层，而 Vungle 等平台则是纯粹的需求源，请务必避免「大家都是 ADX」的混淆称呼。如果需要了解端上广告的生命周期与瀑布流 / Bidding 机制，请参考 App 广告 SDK；有关收益侧的底价（floor）与分层策略，详见 SSP Yield；关于买方如何进行路径选择，请阅读 SPO；而在 Web 侧与此平行的架构，则是 Prebid 配合 媒体 Ad Server。

TL;DR

• 两层角色拆解：需求源（如 Vungle、Pangle、Mintegral）负责提供真实的出价与最终结算；而 TopON 则承担统一 SDK 接入、按需加载 adapter、执行瀑布流与 Bidding 决策，以及整体广告位运营的职责。
• 三层 ID 精准映射：数据流转必须确保「宿主广告位 → TopON placement → 源侧 App ID 与 Placement」具备可逆的映射关系，并且绝对不能将显示名作为主键。
• OpenRTB 方言隔离：尽管协议底层互通，但 imp.video 的定义、激励扩展、商店 URL、计费宏以及 win notice 在各家均存在方言差异；必须依赖 adapter 进行严格隔离，坚决禁止用一套 JSON 模板打天下。
• 超时预算的科学切分：超时设置是调节收益的旋钮，而非固定常量；端上总耗时预算必须被合理切分为「Bidding 并行窗与渲染余量」，各源的软超时（per-source timeout）应按 p95 响应时间进行分桶，对于响应慢且低价值的源要果断降权或移出热路径。
• 混比尺子的统一：在 In-App Bidding 的实时出价与瀑布流的历史 eCPM 进行混比时，必须统一对齐币种与净/毛价口径；一旦比错尺子，将直接导致系统性的贱卖或空仓。
• 三角对账机制：真实的对账应当是「媒体端日志 ≈ TopON 报表 ≈ 各源后台报表」的三角闭环；只迷信聚合层的汇总数据往往是造成差账的最常见根因。
• 线上验收五件套：真正的成功对接不仅是看「后台显示已连接」，而是必须严密监控 bid rate、win rate、eCPM、timeout 比例以及对账偏差这五大核心业务指标。

Table of contents

1. 角色站位：TopON 聚合层与需求源的职责划界

在深挖技术细节之前，我们首先需要把多方参与者的明确分工梳理清楚。后文所有的工程核对清单，均建立在这张基础的角色职责表之上：

具体到本文的语境中，TopON 在整条链路里主要承担以下四项核心职责：

1. 统一的接入外壳：App 侧主要嵌入 TopON SDK，随后由其按需动态加载各家需求源的 adapter；这种设计能够有效降低多 SDK 直连带来的包体膨胀与暴露的 ANR 风险面。
2. 流量的智能分配器：负责执行瀑布流的串行请求或是 Bidding 的并行询价，并将其与历史 eCPM 进行深度混比，这实际上相当于端上版本的 Ad Server decisioning。
3. 运营策略配置台：诸如广告位管理、流量分组、A/B 测试、底价（floor）设定以及各需求源的开关控制，大多集中在 TopON 进行配置并统一下发。
4. 数据报表中枢（但非唯一真相）：虽然开发者习惯优先查看聚合层的汇总数据，但这只是第一步，后续必须将其与各需求源后台的数据进行严密的交叉对账。

对比之下，挂载在 TopON 底层的三条典型需求源各自具备不同的气质：

如果将视角切换到 Web 端进行对照：TopON 的角色大致等同于 Prebid.js 或是 Prebid Server 加上一部分 Ad Server 的决策能力；而 Vungle 则类似于某一家具体的 Exchange。端上架构的特殊性在于，它将向下游的「扇出请求」与最终的「竞价拍板」高度收敛到了同一个聚合 SDK 内部。

2. 完整闭环实战：以 Vungle 与 TopON 的链路打通为例

下面我们将严格按照生产环境的搭建顺序走一遍闭环。当流量经过 TopON 时，两侧的控制台都必须配置妥当，任何一侧的遗漏都会导致线上的静默无量。

2.1 账号、应用与三层 ID 映射机制

广告流转的底层基础，建立在三层 ID 的精确穿透之上：

宿主广告位（产品定义层面）
    → TopON Placement（聚合广告位）
        → Vungle App ID + Placement ID（源侧真实库存）

• 首先，需要在 Vungle 后台创建对应的 App 与 Placement，并妥善记录下 App ID 以及 Placement reference。
• 随后，在 TopON 的控制台新建广告位，并将上述获取的 ID 准确无误地填入 Vungle 源配置中；此时，研发团队应当在内部自建一份双向映射表，并严格区分正式与测试环境。
• 必须严厉禁止使用显示名称作为主键：控制台中的名称修改并不会同步改变底层的 ID，人工依靠名称抄写极易引发映射串位。
• 此外，在进行改版或是拆分广告位时：旧 Placement 的下线必须遵循「切走流量 → 确认对账清零 → 最后删除」的严谨流程，否则极易导致预算上限（cap）被打穿或是报表数据发生严重串联。

2.2 三条协议路径的选择权衡

针对不同的集成诉求，系统通常提供三条协议路径。它们在理论上可以并存，但工程实现上需要极力避免相互踩踏：

需要特别警惕的是，对于同一家需求源，切勿出现「TopON adapter + 官方 SDK」双端同时开启的严重误操作。这不仅会引发双重初始化与双重计费的灾难，两者还会为了争夺底层的 WebView 资源而导致真实的线上事故。

2.3 身份穿透、ATT 政策与「空 ID 流量」应对策略

在隐私合规日趋严格的当下，设备身份的处理显得尤为关键：

• Android 阵营：主要依赖 device.ifa 或 GAID 进行追踪。对于全 0、全 f 或直接缺失的异常 ID，服务端必须制定明确的兜底策略——究竟是降级参与竞价、直接降权，还是果断丢弃请求。
• iOS 阵营：一旦用户未对 ATT（App Tracking Transparency）授权，系统将无法获取 IDFA。正因如此，这种情况下的 eCPM 出现断崖式下跌是合理的商业预期，绝不是工程对接出现了技术故障。
• 当流量经过 TopON 时：用户的隐私同意状态以及 ATT 的最终结果，必须精准无误地透传到每一个底层源的 adapter 中。如果该状态仅仅停留在聚合层，源侧往往会默认判定为「未获取同意」，从而全员返回 no-bid。在监控看板上，这会诡异地表现为「TopON 层面有海量请求发出，但需求源后台却显示零竞价」。

2.4 创意渲染、激励回调与应用商店合规审查

激励视频向来是移动端变现 eCPM 最高的必争之地，但同时也是技术事故的重灾区：

• 广告位的 Placement 类型必须严格设定为 Rewarded，绝不能随意用 Interstitial（插屏）的模板去生搬硬套。
• 奖励回调防刷机制是重中之重：系统必须始终以需求源或 TopON 提供的 server-side 校验结果及签名回调为唯一准绳，绝不能单纯轻信客户端上报的 onRewarded 事件。
• 涉及到创意的关闭按钮位置、跳过功能的倒计时秒数、结尾卡片（endcard）的交互，乃至跳转应用商店的 Deep Link 链路——任何一项导致拒审的原因，都必须结构化地录入素材工单系统，并最终回流至该需求源的填充率监控看板中。
• 此外，如果竞价成功却因为 HTTPS 限制、WebView 崩溃或视频解码失败导致素材无法最终播放，在技术定性上这属于严重的 fill 事故；但狡猾的是，在报表中它经常会伪装成「有 bid 无 impression」的虚假繁荣。

2.5 计费通知闭环与幂等性设计

• 必须在对接初期就清晰界定该需求源采用的计费通知机制，究竟是基于 nurl、burl、直接嵌在 adm 字段内的宏，还是依赖其原生 SDK 进行事件上报（亦或是上述方式的组合）。
• 计费通知的重试机制必须保证绝对的幂等性：无论网络如何抖动，针对同一个 auction_id 或 bid_id 的重复通知，系统在落库时都不能进行双重计费。
• 关于多方数据的三角对账细节，我们将在第 7 节展开详述。

3. Pangle 与 Mintegral：对照差异与方言隔离

很多开发者会误以为既然大家都支持 OpenRTB 协议，就能用一套通用的模板搞定所有源。但这往往是引发线上灾难的开始。

3.1 应对 Pangle 的特殊要求

基于上述差异，工程上的强烈建议是：在 TopON 的配置中，务必给予 Pangle 独立的软超时（per-source timeout）设定，并为其配置独立的熔断降级阈值；切忌将其与 Vungle 粗暴地共享「默认 800ms」的全局参数。

3.2 应对 Mintegral 的效果导向特性

对比不难发现，这三家需求源真正的公约数仅仅局限于：App/Placement 层级映射、设备身份标识、超时参数与对账主键。除此之外，其余字段几乎全是各成一派的方言。正因如此，TopON 等聚合层存在的最大工程理由，正是将这些混乱的方言死死地关进各自的 adapter 牢笼中，从而保障主干链路的整洁与安全。

4. OpenRTB「通」但「不同」：协议归一化到底该归一什么

OpenRTB 标准所能保证的仅仅是一套基础的数据骨架（例如 app、device、imp、user 与 regs 节点），它却并不能保证以下细节的完全统一：

• 激励视频在底层到底应该使用哪一个特定的扩展字段来准确表达 rewarded 的诉求；
• 商店的 URL 与 Deep Link 究竟应该放置在规范的哪一个层级内；
• 针对视频素材的 minduration、maxduration 乃至 skip 跳过功能的默认行为规范；
• 竞价胜出的通知（win notice）与实际计费宏应当如何安全地组合搭配；
• 以及最为棘手的，当设备缺失 GAID 时，对方究竟是会直接回复 no-bid，还是会选择降级并继续参与竞价。

为了抹平这些天然的鸿沟，TopON（或者自建的聚合引擎）内部必须抽象出一套高度统一的内部竞价模型（InternalBid）。例如：

InternalBid {
  source          // 标识来源：vungle | pangle | mintegral | ...
  price_ecpm      // 已精准换算到统一结算币种、且口径已统一为净价或毛价的最终比价基准
  currency        // 货币单位
  creative_ref    // 可直接用于终端渲染的物料句柄（可能是一段 adm、缓存 id 或是 SDK 专用的 token）
  expires_at      // 报价的有效生命周期
  meta            // 保留源侧原始的 bid id，仅用于后续的精准对账与深层排查
}

在这个模型运转下，Adapter 必须承担起三项核心职责：

1. Outbound（发出）：负责将内部的标准化请求，精准翻译为对应需求源的方言，并按需补齐对方所强制要求的各类扩展字段。
2. Inbound（接收）：负责拦截源方的响应报文，并将其反序列化为 InternalBid 格式，期间必须完成币种的实时汇率换算、净毛价的系数折算以及数据的合法性校验。
3. Failure（降级捕获）：当遭遇网络超时、HTTP 状态码异常、业务层面的 no-bid 或是 JSON 解析失败时，adapter 必须能够产出结构化的原因错误码，以此强力支撑上层的熔断机制与全盘监控看板。

一个设计优良的架构，必须确保某一个 adapter 的意外崩溃或线程死锁，绝对不能拖垮同一次拍卖竞价池里的其他正常源——这与 Prebid Server 的 adapter 隔离机制 所探讨的完全是同一个严峻命题。

5. 并行架构设计与超时控制的数学逻辑

真实的运行链路往往呈现出显著的并发特征：

App 宿主
  └─ TopON（承载统一 SDK 与决策引擎）
        ├─ Vungle adapter   ──┐
        ├─ Pangle adapter   ──┼─→ InternalBid[]（并行收口点）
        └─ Mintegral adapter─┘
              ↓
        核心决策：取出 Bidding 返回的最高实时价
              vs 评估瀑布流层中记录的历史 eCPM（若开启混比策略）
              ↓
        执行渲染 / 触发回调 / 数据上报

5.1 为什么坚决不能将「三家 timeout 简单相加」

对于端上的真实用户而言，他们能感知到的只有整体的绝对等待时长。因此，正确的超时模型应当是一个共享着统一 deadline（截止时间）的扇出（Fan-out）并发结构：

最典型的错误做法是：让 Vungle 等待 1000ms，加上 Pangle 的 1000ms，再叠加 Mintegral 的 1000ms，最终变成长达 3000ms 的串行地狱。这种做法不仅会把核心的热路径彻底拖死，且最终那些慢源依然有可能一个结果都没返回。

5.2 实施按 p95 耗时分桶的调优策略（与 Prebid 同构）

假设我们设定 Bidding 的并行全局等待窗为 1000ms：

针对这种场景，合理的调优顺序应当是：

1. 优先盘点各家需求源的「真实 timeout 率 × 其贡献的 eCPM 均值」；
2. 对于贡献高但响应偏慢的需求源，为其单独适当拉长 soft timeout（前提是依旧 ≤ 并行等待窗），或者将其整体移出核心的高并发热路径；
3. 对于那些「响应又慢、出价又穷」的劣质源，必须果断将其踢出 In-App Bidding 阵列，改置于瀑布流的最末端，甚至直接实施物理关停。

这种关于「全局 timeout 阈值误杀高价值慢速源」的技术叙事，实际上与 Header Bidding 超时调优 探讨的完全是同一道系统工程题的端上翻版。

5.3 警惕 Floor 设置导致的自我压价危机

在多需求源并行竞价时，如果任由每家源各自携带一套互不相通的地底价（floor）体系：

• A 源的地板价设置过高，导致其常年返回 no-bid；
• B 源的地板价设置过低，导致高质量流量被其以极度廉价的代价收割；
• 最终在报表上看起来「填充率极度饱满」，但实际上系统却在进行隐蔽的自我贱卖。

正确的应对做法是：在 TopON 的广告位层级设定全局统一的地板价，再将其按需分发并覆盖至各个源；这一操作必须与 SSP Yield 探讨的分层策略保持绝对对齐。同时需要强调的是，如果某个 Bidding 返回的实时价已经跌破了这层统一的 floor，聚合层应当直接将该出价丢弃，绝不能再将其推入后续的瀑布流混比环节。

6. 竞价与瀑布流混比：对齐同一把衡量尺子

在真实的商业生产环境中，纯粹的 In-App Bidding 或纯粹的传统瀑布流都较为罕见。更为成熟的模式通常是：

1. 开启并发线程，向 Vungle、Pangle 以及 Mintegral 请求获取最真实的实时 bid 报价；
2. 在此期间，系统同步读取瀑布流队列中预设的各分层的历史经验 eCPM 数据；
3. TopON 作为最终裁判，必须使用同一把尺子，在两者之间精确比对出最终的胜利者。

6.1 尺子必须严丝合缝统一的三大要素

一旦这把尺子没有校准，最直接的临床症状就是：在业务报表上，某一需求源仿佛开挂般「永远在赢」，或者另一家源「永远在输」；甚至 eCPM 的表面数据看起来一片大好，但月底对账时总收入却纹丝不动，甚至出现了倒退。

6.2 与 Web 侧统一竞价机制的镜像对应

仔细审视，端上的这种混比机制与 Web 侧的 GAM dynamic allocation / unified auction 高度相似：本质上都是让系统获取的实时价与「预设的经验价格层」同台竞技。然而，端上的独特之处在于，除了比对数字，它还必须死死抠住包体的内存占用、主线程的流畅度，以及素材是否成功命中了预加载缓存——在移动端，即便某个源出价极高，但如果其对应的素材尚未就绪，在良好的产品体验策略下，它依然有可能输给「出价略低、但素材已 fully cached」的备用源（当然，这种业务妥协必须是在后台显式配置下发生的，绝不能任由其作为隐蔽 Bug 默默发生）。

7. 财务对账、防双计灾难与系统的可观测性

7.1 三角对账的闭环体系

可靠的财务数据必须建立在稳固的三角闭环之上：

媒体端的真实发奖日志（曝光 / 点击 / 奖励下发）
        ≈  TopON 聚合层的最终报表
        ≈  Vungle / Pangle / Mintegral 各家需求源的官方报表

线上放量的绝对门禁应该是：在连续 3 日的滑动窗口期内，三方数据的收入偏差必须严格落在业务约定的容差范围内（例如 2%～5%，具体视不同的需求源而定）；一旦发现超差，系统应当立即触发告警，并果断冻结该源的后续放量操作。

7.2 引发双重计费（双计）的典型致命路径

• TopON 的 adapter 与该源的官方直连 SDK 被错误地同时唤醒并重复上报；
• 激励视频在客户端层面触发了发奖回调，而同时服务端的校验逻辑又将其下发了一次；
• 核心的计费重试（如 nurl 机制）在设计时彻底缺失了幂等键的保护。

防范这种灾难的铁律是：确保整个架构中存在单一的上报权威、全面铺设不可被篡改的幂等键（如 auction_id 或 bid_id），并且奖励的最终发放必须毫无条件地以服务端的校验结果为准。

7.3 构建高价值的最小指标集

为了实现真正的可观测性，监控指标必须精细地按照「广告位 × 需求源」的维度进行横向切开：

请记住，如果你在搭建看板时没有做到「按源切开的 timeout 分析」，那么你在后台随手调整的每一个全局数字，本质上都只是极其盲目的拍脑袋决策。

8. 生产级线上验收核对清单（Runbook）

核心配置面

• 确保「宿主广告位 ↔ TopON ↔ 各源 App/Placement」的三层映射表录入完整且双向匹配。
• 严格核对广告形式（激励视频 / 插屏 / Banner）与该源后台的 Placement 类型绝对一致。
• 确认正式与测试 App ID 已实现物理隔离；且测试模式的 flag 绝不能被意外打包进正式生产包中。
• 隐私同意协议 / ATT 弹窗 / 儿童隐私旗标已按各地区的市场合规要求正常调起，并通过抽包抓包确认上述状态已成功透传至各需求源。

真实流量面

• 灰度期间数据表现：确认三家源的 bid rate > 0；且在并行等待窗内的 timeout 比例完全符合业务预期。
• 激励视频验证：确保发奖回调能够在完整播放后被稳定复现，且服务端的防刷机制已被真实激活。
• 创意渲染验证：赢得竞价的创意必须能够被完整、流畅地播放与关闭；确保全链路不存在 Mixed Content 错误，且 WebView 没有引发任何崩溃日志。

财务流转面

• 确保在放量前，连续三日的三角对账数据稳定在安全的容差范围内。
• 监控大盘，确认不存在大面积的「只出竞价却不结账」或是「看似结算了但毫无有效曝光」的异常现象。

故障防御面

• 验证单源熔断机制：当人工模拟 Vungle 接口大面积超时飙升时，确认 TopON 依旧能够稳健地将请求交付给其他备用源。
• 验证监控告警：确认当 bid rate 归零、对账偏差超过阈值、激励回调遭遇持续失败，或是指定版本的 ANR 陡然升高时，系统能够秒级触发告警通知。

在这个错综复杂的系统中，最常导致静默失败的几个经典元凶分别是：在 TopON 后台粗心填错了 Vungle 的 Placement、遗留了未摘除的测试模式代码、将激励视频与插屏广告类型相互挂载错误、用户未对 ATT 授权系统却依旧按照携带 IDFA 的高价值预估收入、对账时只死盯 TopON 而彻底忽略了源后台的数据，以及在 Bidding 与瀑布流混比时净价与毛价的严重错位。

9. 生产事故复盘：三种「看起来接好了」的虚假繁荣

危险假象 A：聚合后台数据全绿，但线上却零竞价。 这种故障的底层根因，通常是 consent 标识或者 ATT 状态未被正确透传至底层，又或者是广告位的 Placement 类型出现了错配。此时，在需求源的后台虽然能看到所谓的「有请求」，但这些请求全部被系统归类到了无效流量的口径下。

危险假象 B：业务报表上的 eCPM 极度好看，但月底总收入却纹丝不动。 出现这种情况，往往是因为混比尺子的失真，把原本具有高变现潜力的优质 Bidding 请求粗暴地过滤掉了，或者是全局统一的 floor 设定过高导致整体的 fill 比例出现了严重坍塌。如果只盯着 eCPM 这一单一指标，极其容易得出「优化大获成功」的荒诞错觉。这部分的深入逻辑，详见 Yield 篇章。

危险假象 C：TopON 与 Vungle 数据相差高达 8%，业务方却表示「先上线跑量，后续再慢慢查」。 请牢记，这种幅度的差账往往预示着底层的三层映射、时区设定，或者是活动维度在系统层面存在根本性的数据错位。如果带着这种病灶强行放量，后果只会演变成越来越大的财务坏账与多方扯皮。因此，对账门禁机制必须像铁墙一般死死挡在全面放量之前。

10. 核心行业误区 ↔ 实战正解指南

排障与调优口诀：三层映射不可逆；方言必须做隔离；总耗时切并行窗；慢源果断移热路；混比统一净毛价；对账必查源后台。

理解了端上的多需求源接入，接下来我们需要深入探讨如何在宏观层面统筹全局流量的变现效率，推荐阅读本系列下一篇：SSP Yield 深挖。

延伸阅读

同系列（卖侧竞价与决策）：

• 本站. Header Bidding：Prebid.js vs Prebid Server：Web 扇出 / 超时分桶——与 TopON Bidding 同构。
• 本站. 媒体 Ad Server 深挖：多路价格如何拍板（Web 对照）。
• 本站. SSP Yield 深挖：floor、分层与「好看的 eCPM」。

跨系列相关：

• 本站. App 广告 SDK 深挖：Mediation / In-App Bidding 与端上生命周期。
• 本站. 广告 SDK 实战：adapter 与厂商接入。
• 本站. 供应链优化 SPO：买方如何收敛多路径。
• 本站. IAB TCF：consent 缺失时的集体 no-bid。
• 本站. 归因 MMP / SKAdNetwork：Mintegral 类效果源联调背景。

资料：

• TopOn. Developer / Help：聚合、Bidding、广告位与源配置。
• Liftoff / Vungle. Publisher / Bidder 文档：App、Placement、Bidding。
• Pangle. Publisher 帮助中心：出海网络与合规对接文档。
• Mintegral. Developer / Help：效果源流量运营与联调。
• IAB Tech Lab. OpenRTB 2.6：骨架字段；扩展仍以各源为准。

附录：术语表

• TopON：移动广告聚合平台；负责统一 SDK、需求源管理与瀑布流及 Bidding 决策，其本身不是交易所。
• Vungle（Liftoff）：以移动视频、全屏及激励场景见长的交易所；本文所选用的需求源主要示例。
• Pangle / Mintegral：字节系出海广告网络，以及偏向效果转化的移动广告网络。
• 三层 ID：核心的数据映射链路，即宿主广告位 → TopON placement → 源侧 App/Placement。
• Adapter：协议方言的翻译与隔离层；通常由 TopON 等聚合 SDK 按需动态加载。
• InternalBid：聚合平台内部统一的竞价对象（涵盖了统一的换算价格、币种、创意渲染句柄与过期时间）。
• In-App Bidding：在端上发起的并行真实询价机制。
• 混比：将 Bidding 获取的实时价与传统瀑布流的历史 eCPM，放置在同一把衡量尺子下进行价值比对。
• 三角对账：通过媒体端日志、聚合层报表与需求源后台报表进行交叉验证，确保财务数据的一致性。
• Per-source timeout：单源软超时限制；该值应当 ≤ 并行等待窗，并严格按真实请求的 p95 响应耗时进行分桶设定。