ADX平台功能解析

ADX平台功能解析

新增下游对接

涉及模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
1.下游管理->下游列表 新增该下游媒体		[t_downstream]
为了录入下游基础信息, 关联上游订单/流量目标, 需要我们为可提供的广告位创建所属目标. 即下游渠道
录入信息:
必填: 下游名称, 下游类型(adx/ssp), 是否需要审核广告主/创意等, 自动生成秘钥/校验码
非必填: 媒体邮箱
> adx/ssp类型有什么区别? 无用
> 下游秘钥/校验码是否是用于加密下游价格? 下游加密, 触发监控链接, 我们解密


2.媒体管理->应用列表 创建该下游下属应用 [t_app]
指定该应用支持的广告位交互类型和操作系统类型
录入信息:
必填: 应用名称,所属媒体,应用分类/二级分类,指定该应用类型(PC/Android/IOS), 交互类型(链接/下载/跳转)
非必填: 应用包名
> 媒体分类用途?


3.媒体管理->广告位列表 创建广告位 [t_ad_position]
指定该平台各个广告位支持的操作系统类型及下游请求过来的流量识别ID
- 前提1: 在下游广告形式模块中, 查询是否存在该广告位形式(banner/开屏/贴片), 不存在先创建 [t_adx_adtype]
> 上述有误. 广告位信息中的广告位形式与下游广告位形式不匹配, 后台代码中是以配置方式存在的.
- 前提2: 在模板列表模块中, 创建该广告位支持的广告模板, 填写广告位形式/投放类型/素材宽高等信息 [t_ad_template]
录入信息: 该广告位名称, 所属应用, 所属媒体, 广告位类型(前提1), 广告位模板(前提2), 投放平台/系统/类型, 广告位底价/建议价, 下游请求广告位ID/标识, 绑定系统广告位ID
> 投放类型字段有何用处? 可以用于筛选匹配模板(并不是)
> 广告位和模板都有投放类型字段记录, 是否存在广告位投放类型与广告模板投放类型不一致的情况, 如何处理


- 广告位模板介绍
下游模板仅在媒体管理中存在, 包含信息有名称, 广告位形式(banner/信息流), 投放类型(RTB/PD), 创意尺寸/字数要求等
广告位模板可以用于绑定媒体广告位, 也可以绑定系统广告位. 同时使用同一个模板是双方建立关联关系的前提
为了在下游流量请求过来时, 判断广告位的各种尺寸/创意要求, 要么下游请求中包含模板ID, 要么需要某种方式匹配到该模板(如广告位ID+尺寸). 后一种方法可以使用[映射下游模板ID]功能达成.


4.系统媒体管理->应用列表 创建系统应用(对上游) [t_system_app]
将下游各应用的广告位来源汇总, 成为对上游来说一致的流量来源应用. 如本系统中存在多个下游, 他们各自都代理爱奇艺的一部分广告位, 交集差集都不为空, 此时, 这些广告位对上游来说, 应该属于统一的应用-爱奇艺
查询是否存在该应用, 不存在, 对照媒体应用录入系统应用数据以创建
录入信息:(除没有所属渠道外,和媒体应用基本相同)
交互类型/系统类型/媒体分类/是否自定义应用信息/应用信息(自定义APP名称/包名)
> 同样包含媒体分类
> 是否存在下面的情况: 系统媒体应用支持多种交互类型, 其中某个媒体应用仅支持一种交互类型


5.系统媒体管理->广告位列表 创建系统广告位(对上游) [t_system_adslot]
用于向上游发送竞价请求时, 统一下游广告位流量形式.
录入信息: 广告位名称, 所属系统应用, 广告位形式, 广告位模板, 投放平台/系统/类型, 上游底价
绑定关系: 一对多, 系统广告位可包含多个媒体广告位, 并在媒体广告位对应字段记录所属系统广告位对应关系 [f_sys_adslot_id]
设置价格: 该广告位媒体底价和上游底价
设置上游底价, 每关联一个新的媒体广告位, 将在价格表(t_ad_price/t_adslot_price)中修改价格并记录
> ? 列表页中的DSP底价和编辑上游价格中的价格什么关系
> ! DSP底价和上游价格都是在请求上游时使用的底价. 但DSP底价关联系统广告位, 属于基础默认价格, 关联媒体广告位时会自动生成该价格的上游价格. 上游价格关联系统+媒体广告位的关联关系, 属于该媒体广告位自定义的底价, 可以低于DSP底价, 但不能低于该媒体广告位底价

6.绑定媒体广告位到对应的系统广告位上
支持在系统广告位中绑定媒体广告位(一对多), 也支持在媒体广告位上绑定系统广告位(一对一)
该绑定关系在后台无法取消, 据说是为了避免误操作,导致使用的关联关系失效

新增上游对接

涉及模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1. 上游平台管理->基本信息  新增上游信息		[t_dsp_members]
该模块主要用于存储上游平台信息, 用于在流量请求过来时, 指定需要分发竞价请求的目标本体.包括用于展示的信息 和引擎需要的配置参数(isdsp-上游类型 / is_ext-是否执行扩展程序代码)
录入信息:
展示信息:上游名称, 账户/密码, 公司信息, 对接人, 邮箱配置等
引擎配置: 平台类型, 是否使用扩展代码
> 是否为DSP平台有什么用?
一般DSP平台是由上游对接我们, 我们提供竞价请求/响应接口格式, 他们做适配开发.
而非DSP平台一般是我们对接他们, 需提供个性化接口处理请求响应数据格式(引擎dsp文件夹内容), 有些还需要在预算平台注册资源
> 扩展代码的作用是什么? 主要用于为某些上游提供定向流量功能, 参考SPLITFlow + 引擎common/config中的逻辑


2. 上游平台管理->配置信息 配置上游DSP对接信息 [t_dsp_config]
上游平台用于流量分发时的引擎配置信息, 一般直接存储在广告位对应的缓存中
录入信息: 竞价URL, QPS, 是否需要审批创意, 接口配置(方式/超时/IP白名单/加密秘钥)
> ? 为何不将上游信息单独存储, 而是放在下游平台:下游广告位ID的dspIds中?耗费内存不说, 若上游平台有修改,所有相关广告位缓存信息都需要更新
> ! 可能是以空间换时间,优先保证请求时间. 有时间可以测试下两种方式的耗时区别

3. 广告主管理 新建广告主 [t_advertisers]
主要用于审核上游广告创意所属广告主资质信息, 同时也支持向下游传递该广告主信息, 供下游审核
录入信息: 所属上游平台ID, 广告主信息(名称/营业执照/资质/行业信息)
广告主开通: 传递给下游审核, 通过接口/运营手动传输给下游, 审核该广告主资质/行业信息 [t_advertisers_audit]
> 广告主创建来源? 接口创建? 谁触发,谁填写(本平台运营/上游平台)
> 为何会有上游广告主ID? 从哪儿获得, 有什么用

4. 创意管理 同步DSP创意到ADX [t_creatives]
用于审核上游创意素材信息, 同时支持向下游传递创意信息, 供下游审核
录入信息:
关联关系: 该创意所属上游, 上游创意ID, 所属广告主, 广告主所属行业, 订单ID
素材属性: 投放时段, 创意交互类型(落地页/下载/跳转), 广告形式, 广告模板
素材内容: 创意素材信息, 落地页, 监测链接(点击/曝光), 竞价成功通知链接等
> 录入创意是否是用于先审后投, 竞价成功所用创意优先用哪个, 如何保证竞价成功响应素材和审核素材一致
(拉取上游素材到本地, 投放时可以使用本地素材, 以避免上游链接所在素材被替换)

创意开通: 传递给下游审核, 通过接口/运营传输给下游, 下游审核该创意是否合规 [t_creative_audit]
创意操作日志: 记录创意操作的数据变动 [t_creatives_handle_log]

1
2
3
4
5
6
7
8
上下游管理中
下游对外使用媒体管理, 配置内容主要是下游媒体需要填写的内容.
对内使用系统媒体管理, 将下游媒体广告位整合成为本系统的广告位

上游对外需要在其他平台注册我们自己的广告位
对内需要整合其他上游, 做好区分, 整理为自己的预算集合

那是否可以开放对下游媒体的操作, 由下游自己创建应用/广告位, 通过接口/脚本在媒体广告位进行增删改时, 同步信息到系统广告位清单, 在此过程中, 可以做广告位合并, 清退, 去重等操作

预算平台资源管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
某些业务流程中, 本ADX平台对于上游平台来说, 是类似于ssp下游平台的存在.

1.预算平台应用 [t_third_app]
从后台看, 预算平台应用创建需要将【上游平台管理】中的上游ID 与【系统媒体管理】中的下游应用ID 关联, 生成应用记录
应该是我们作为ssp, 需要在上游adx(上游ID)中创建应用(下游应用ID), 返回adx应用ID
> ? 应用ID存哪儿了 预算平台管理->配置信息 t_dsp_config->f_media_id
> ? 为什么不在预算平台资源管理中记录应用ID
> ! 对上游来说我们是一个整体, 上游不关心这个流量来自哪个下游, 也就不用每个下游在上游资源管理中新建一个应用, 并区分请求来源

2. 预算平台模板 [t_third_template]
从后台看, 预算平台模板创建是将【上游平台管理】中的上游应用ID 与【媒体管理】中的模板ID 关联,加上注册在上游平台返回的模板ID/名称,生成模板记录
- 我们作为ssp需要创建广告位, 先得创建模板, 记录广告位投放类型, 素材宽高等信息
我们需要在上游预算平台(上游ID)创建模板(下游模板ID). 登记我们【媒体管理】中的对应模板数据, 获取上游返回的模板ID/名称
> 为何会有广告位形式? 也是在绑定广告位时做筛选的么? 实验后发现没有筛选关系

3. 预算平台广告位 [t_third_adslot]
从后台看, 预算平台广告位创建是将【上游平台管理】中的上游ID, 第一步创建的应用, 第二步创建的模板,【系统媒体管理】中的广告位ID 关联起来, 生成广告位记录
- ssp创建广告位, 需要提供所属应用/模板ID
我们需要在上游预算平台创建广告位,登记我们【系统媒体管理】中的对应广告位数据, 使用的应用/模板信息等, 返回广告位ID/名称
在本系统中记录该广告位的预算平台信息, 所属应用/模板,登记广告位ID/名称

这也是为何【上游平台管理】列表数据中, 存在字段 是否为DSP平台 的原因

流量管理

1
2
3
4
5
6
7
8
9
10
分为两种方式: 模板维度/广告位维度
- 模板维度 [t_flow_new / t_flow_adslot_relation]
列表显示所有媒体广告位模板, 依照媒体/应用/广告形式/模板ID 逐层筛选流量
点击分配后显示可用上游平台, 确认关联关系分配流量
- 广告位维度 [t_flow_adslot_dsp_relation]
列表显示所有媒体广告位, 依照媒体/应用/广告形式/广告位ID 逐层筛选流量
点击分配后显示可用上游平台, 确认关联关系分配流量

> 该关联关系用于下游流量进来后, 获取分发竞价请求目标 ? RTB/ PD PDB
模板和广告位是一对多的关系

订单管理

? 是否仅服务于PD/PDB形式的流量交易

1
2
3
4
5
6
7
8
9
下游订单管理 - 下游录入各种基础信息后, 流量送达的合同记录		[t_adx_order]

录入信息: 时间区段, 订单名称, 订单价格(单价?总价?), 下游交易ID,
下游平台(下游管理列表中的媒体ID), 应用(?媒体管理应用列表中的应用ID), 广告位(?媒体管理广告位列表中的广告位ID),
?预算平台(上游平台管理中的平台ID), ?广告主(广告主管理中的广告主ID), 上游订单(非必填), 订单价格(下游设定底价?),
绑定关系:关联上游订单信息? [t_dsp_adx_order_relation]

> 下游订单应该是adx/ssp之间的合同, 为何会有上游平台字段+广告主, 还是必填
下游订单创建时需要明确该下游平台流量需要分配给哪些上游预算平台,投放哪个广告主的素材
1
2
3
4
5
6
上游订单管理 - 上游对于某个广告位的合同记录			[t_dsp_order]

录入信息: 时间区段, 订单名称, 订单价格(单价?总价?),
预算平台(上游管理列表中的平台ID), 活动(上游活动ID,内含投放量级,频控等数据),广告主(广告主管理中的广告主ID),
应用(系统媒体管理应用列表中的应用ID),广告位(系统媒体管理广告位列表中的广告位ID)
绑定关系:关联下游订单信息 [t_dsporder_adslot_relation]
1
合约广告不仅是adx和上游签订订单, 还会涉及到下游, 下游发送流量时会标识该流量的
1
2
3
4
5

该模块从创建优先级别来说, 应该是先创建上游活动, 在创建上游订单, 最后创建下游订单
因为创建下游订单数据时, 需要绑定上游订单, 而创建上游订单时, 需要选择上游活动

当上游平台类型为DSP平台时, 不需要在预算平台资源管理中注册应用/广告位. 如果是SSP平台, 则需要注册,并在上游订单中绑定上游广告位信息

流量处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
媒体发起流量请求, 请求需携带ADX中已注册的广告位下游ID		t_flow_adslot_dsp_relation

ADX系统通过广告位ID定位【媒体管理->广告位列表】数据, 从而获取到该请求所属媒体/应用/模板/投放类型等数据
先处理PD/PDB
- 通过订单获取上游订单
查询【订单管理->下游订单】数据, 是否存在包含该广告位的下游订单
若存在该下游订单, 查询是否存在上游订单关联关系, 进而获取【订单管理->上游订单】中的上游订单数据
通过上游订单获取到需要该广告位的上游平台及其应用/广告主/系统代码位/价格
- 通过广告位获取上游订单
查询【系统媒体管理->广告位列表】数据, 获取该媒体广告位对应的系统广告位
若存在该系统广告位, 再从【订单管理->上游订单】中获取该系统广告位是否存在上游订单数据
若存在该上游订单, 通过上游订单获取到需要该广告位的上游平台及其应用/广告主/系统代码位/价格
再处理RTB
- 获取上游
- 通过模板获取分配上游
查询【流量管理->流量分配】数据, 获取该媒体广告位对应的模板的分配上游DSP平台
- 通过广告位获取分配上游
查询【流量管理->流量分配(广告位维度)】数据, 获取该媒体广告位对应的模板的分配上游DSP平台
- 获取上游配置
查询【上游平台管理->配置信息】数据, 获取上一步获取到的上游对应配置信息
- 竞价
验证token/IP白名单/超时时间
依据每个上游不同的流量接收地址, 发起竞价请求, 取胜者, 通知上游竞价成功

PD/PDB/RTB请求可以同步发出, 依照优先级由低到高处理响应, 返回媒体最终展示的创意结果
PD/PDB若返回创意,则舍弃RTB胜者广告素材, 若PD/PDB没有返回创意, 使用RTB胜者素材

> 流量分配完成后在流量分配缓存标识表(t_flow_new)中设置缓存标识

数据报表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
上游数据报表
单日数据(小时): t_dsp_chain_statistics_202304
非单日数据: t_dsp_chain_statistics_day

下游数据报表
单日数据(小时): t_adx_chain_statistics_202206
非单日数据: t_adx_chain_statistics_day

上游订单数据报表:
单日数据(小时): t_dsp_chain_statistics_pd_202206
非单日数据: t_dsp_chain_statistics_pd_day

下游订单数据报表:
单日数据(小时): t_adx_chain_statistics_pd_202206
非单日数据: t_adx_chain_statistics_pd_day

上游活动报表:
dsp_chain_statistics_pd_day

监测链接处理方式

1
2
3
包括曝光/点击/竞胜等
上游提供给我们的监测链接, 需要我们提供价格加密替换(使用上游秘钥), 再直接请求(仅竞胜)或传递给下游, 由下游触发
我们自己的监测链接, 需要下游提供价格加密替换(使用下游秘钥), 再由下游触发

其他问题:

1
2
- 下游平台可能设置某些行业黑名单, 没发现有地方配置
提前商务沟通避免投这些行业, 且下游也会自己审核创意

深入方向

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
如何从0搭建一套ADX系统
(核心功能为流量转发, 需要处理上下游大量请求, 所以在搭建之初需要考虑负载均衡及缓存配置)
1. 需要商务对接下游, 获取流量. 进而通过提供广告位清单的形式在adx中注册
- 需要下游提供投放黑白名单, 广告位清单(含类型/支持素材格式/宽高等信息), 底价等

2.获取到流量后, 需要商务获取预算方, 支持合约和竞价两种交易形式.
- 合约形式, 需要指定上游想要投放的下游广告位, PDB(保价保量)/PD(报价不保量)
- 竞价形式, 需要为其分配支持其投放类型的下游订单/广告位/模板, 并按照需要开通下游
为上游预算方做进一步支持, 如上传审核上游广告主, 开通下游广告主, 审核素材, 开通下游素材, 设定请求参数配置(URL/QPS)等
(审核广告主一方面是为符合广告法要求, 避免虚假宣传, 一方面是筛选黑五类广告, 避免影响下游平台)
(考虑大量广告素材数据的存储)

3.有了上下游配置后, 就需要考虑下游流量请求ADX后, 如何分发的问题
首先需要将广告预算分发至各匹配计价模式的下游广告位上.用于下游请求流量到来时做分发
其次对合约形式广告流量, 需要在系统中生成订单数据, 记录订单ID, 投放时段, 下游目标, 投放价格等数据
> 上下游订单生成的先后问题
(为避免转发请求中包含过多判断逻辑, 可以通过后台在缓存中维护分配目标集合, 不涉及数据库查询及交并计算)
(一般要将adx响应时间尽量压缩, 分发流量后的响应也需要配置响应时间, 超时响应主动丢弃) 100-150ms

ADX获取到下游流量请求后, 需要通过适配器, 依据来源将其转化为标准格式, 依据流量类型(合约/竞价), 转发至上游并记录请求日志
- 合约. 获取合约上游配置,与其他关联上游一起, 发起竞价请求. 若合约目标返回填充, 使用填充内容响应下游;若合约目标响应无填充, 使用其他上游竞价优胜者填充响应下游
- 竞价. 获取绑定上游配置, 发起竞价请求. 获取竞价优胜者填充, 响应下游
(为加快响应时间, 上下游绑定关系及上下游信息应该记录在缓存中. 有数据变动时, 先更新数据库, 再更新缓存)

4.向优胜者发送竞胜通知并记录日志

5.分发完成后, 需要考虑报表统计计算问题, 为上游生成多种维度的报表数据

6. 计费平台/充值管理的实时扣费问题
(CPT/CPM多种结算方式, 反作弊, 余额撞线, 扣费摊销/对账)

其他问题:
流量均衡 - 如何保持流量请求按照设定QPS, 分发给上游平台
资金策略 - 如何合理使用资金
预警

1
2
3
4
5
6
7
8
9
10
11
12
13
ADX报表关注指标
针对DSP平台而言,主要关心的是广告效果指标,例如竞赢率、点击率、点击成本、激活成本等。

竞赢率 = 竞赢量/竞价量
点击率 = 点击数/曝光数
点击成本 = 广告消耗(花费)/点击数
激活成本 = 广告消耗(花费)/激活数

针对SSP平台而言,主要关心广告的价值eCPM、广告填充率、广告点击率等。

eCPM:广告千次展示收入(预估值)
广告填充率 = 广告返回量/广告请求量
广告点击率 = 广告点击数/广告曝光数
1
2
3
4
5
ADX基础功能:
- 转发流量的功能
- 报表API和数据分析可视化报表后台
- 按照基础维度筛选流量(buyer和seller的黑白名单,广告形式和广告尺寸,国家和地区,网络环境和OS);
- 高级优化设置,比如TMAX和底价范围值请求的屏蔽(即不转发某个条件或维度的请求);http和https(secure的屏蔽),porn content的屏蔽,IP和bundle mismatch的屏蔽。
1
2
ADX理解:
中立的竞价平台 -> 分发处理(管理/变现)流量(自有流量/外购流量)的平台
1
2
3
4
5
6
7
广告投放合同约定内容:
发布概况: 内容, 形式, 素材, 发布地址/位置, 媒体规格, 数量
款项/支付方式: 合统款项, 支付日期, 支付批次, 支付方式
双方权利/义务:
广告主: 营业资质证明, 广告商品质量证明, 广告真实性证明, 代理委托证明, 广告素材
媒体: 广告发布资格证明, 维护发布设施正常运行, 提供发布数据
违约责任:

ADX逻辑架构图

1684918647375

1
2
3
4
5
答疑:
流量分配和订单管理之间的关系是什么, 是现有订单才去配置流量分发逻辑/还是先配置流量再有订单拆分添加流量分发
没有关系, 流量分配只是关联了上游和下游之间的流量分发逻辑. 但还需要通过订单去判断该次流量分发是通过什么交易方式结算的.
- 若下游流量请求包含dealId, 且该合约ID存在于订单系统中, 证明该次请求是使用PD/PDB模式的合约请求
- 若下游流量dealId不存在, 则使用RTB方式竞价分发