广告业务系统 之 业务串联 —— “ PDB - 广告投放【保量保价】”

PDB - 广告投放[保量保价]

常规的 ADX 系统，会支持 PD、PDB、RTB…等多种广告售卖模式。 针对不同的售卖模式，系统之间各服务之间的逻辑及交互方式是不同的，下面将以 PDB 模式讲解详细数据流。

前面几章都是以模块粒度去描绘 ADX 系统链路，这次以 业务角度 去串联 ，希望大家有所获益。

PDB 浅述

PDB ，这种广告无需参与竞价，以 合同方式 进行约定 流量及展现规模 并 结算。其中交易流量完全由 广告主决定，且投放优先级在 全部广告模式中 最高。【详细含义可见后续文章】

由于 PDB 售卖模式的特殊性，在 ADX 系统中有独特的设计。在下面的阐述中，将会全面概述数据、逻辑链路部分。

PDB 数据流图

PDB 数据流的源头来自 BP 平台，流入 ADX 系统，最终将由 投放引擎 消耗掉。

注：全链路流程图可参看 暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”

• BP 平台将 CRM 合同数据的 PDB 计划，下发给 消息中心；消息中心将对数据进行筛选，并落地至 Redis；投放引擎在进行广告投放时，会优先去 Redis 中判定是否存在 PDB 计划；

• BP 平台将 CRM 合同数据的 流量圈定部分，也就是规则【广告面向群里划分：男/女，北京市/天津市/，汽车类…】，下发给 索引服务；索引服务将对具体规则建立对应的索引；投放引擎 将当前流量特征下发给索引服务，并进行匹配，筛选出符合的规则，并于获取的 PDB 计划进行映射，获取到最终需要进行投放到 PDB 计划。

• 投放引擎 获取到 当前流量投放到 PDB 计划之后，将去 离线脚本 拉取对应的实时数据【主要为订单曝光数据】，进行流量保量及平滑的控制。

• 离线脚本的数据源为 日志中心的数据实时监控采集。

上述数据流涉及到了ADX 系统中 六个模块，数据链路比较长，且各个模块之间数据存在相互作用，缺一不可。

保量逻辑设计

在 PDB 介绍中聊到，我们需要对 PDB 订单进行保量。如果最终没有完成预定曝光量，需要对广告主进行赔付。

投放引擎进行投放时，将以 “当天剩余曝光量” 为核心判定指标。

• 当核心指标存在余量，则下方流量至 DSP 侧 进行广告候选的投放；当无余量时，将触发 “当天计划曝光已完成” 的消息，并知会给消息中心进行天维度的计划下线。
• 若无此核心指标，投放引擎将不再进行流量下发，终止 PDB 流程，将流量下发给 其他模式的 DSP。

我们将如何动态地设置核心指标，当天剩余曝光量呢？

订单曝光拆分

如上图示，在创建 PDB 计划时，将会拆分成天粒度的存储数据。为了更细粒度、更平滑的控制流量规模，我们将指标细分为，计划曝光、计划之前曝光、实际之前曝光、实际需曝光、剩余曝光..等等多个指标。

指标统计规则如图所示，这里不再赘述，细节问题可留言。

通过每天定量的流量下发，可确保流量不会超量。但当投放计划最后一天时，无法达到预期规模时，就需要对 PDB 计划进行补量。

凌晨停量

由于 PDB 订单采用真实曝光结算，真实曝光结算数据在全链路中会有延迟，因此在 22:00-22:30 期间会暂停投放；如果曝光量还未完成当天的曝光量，则会在 22:30-24:00 之间继续补量。

注：具体时段，视具体场景而定

补量

补量的逻辑，其实有很多做法，最常见的方式就是 运营/产品在内部系统中再补一单。

独特的产品模式，造就了特异的功能逻辑。通过架构、组件之间的灵活交互、数据流转 完成产品价值的交付，这也是作为研发人员毕生的宿命。

通过 PDB 模式的讲解，将业务模式与技术架构做贴合，更深层次的、提升对 广告业务/ ADX 系统 的了解、学习。

---

见后续文章！

推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”
广告业务系统 之 框架沉淀 —— “数据消费型服务框架”
广告业务系统 之 智能保险丝 —— “智能流控”
广告业务系统 之 敏捷交付 —— “基于 Docker 容器同机部署”

---

三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…