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

最新推荐文章于 2024-07-20 16:19:07 发布

魏小言

最新推荐文章于 2024-07-20 16:19:07 发布

阅读量2.7k

点赞数 1

分类专栏：广告业务/系统详细架构设计文章标签：计算广告 PDB 架构 ADX 微服务

本文链接：https://blog.csdn.net/qq_34417408/article/details/128706538

版权

17 篇文章 4 订阅

订阅专栏

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

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

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

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

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

BP 平台将 CRM 合同数据的 PDB 计划，下发给 消息中心；消息中心将对数据进行筛选，并落地至 Redis；投放引擎在进行广告投放时，会优先去 Redis 中判定是否存在 PDB 计划；
BP 平台将 CRM 合同数据的流量圈定部分，也就是规则【广告面向群里划分：男/女，北京市/天津市/，汽车类…】，下发给 索引服务；索引服务将对具体规则建立对应的索引；投放引擎 将当前流量特征下发给索引服务，并进行匹配，筛选出符合的规则，并于获取的 PDB 计划进行映射，获取到最终需要进行投放到 PDB 计划。
投放引擎 获取到当前流量投放到 PDB 计划之后，将去 离线脚本 拉取对应的实时数据【主要为订单曝光数据】，进行流量保量及平滑的控制。
离线脚本的数据源为日志中心的数据实时监控采集。

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

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

在这里插入图片描述
投放引擎进行投放时，将以 “当天剩余曝光量” 为核心判定指标。

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

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

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

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

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

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

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

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

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

见后续文章！

关注