SSP平台功能解析

ssp运行流程

1.媒体接入
- 确定接入应用及广告位详细信息
- 确定媒体接入需求, 如广告过滤条件, 拒绝某类或某些域名广告接入
2.运营配置
- 上传媒体应用/广告位信息到ssp平台
- 审核上传数据内容
- 第三方(adx/dsp)备案媒体广告位信息并同步结果到ssp平台
- 绑定上游广告需求到代码位, 分配流量及权重
3.程序化逻辑
- 媒体用户流量到达, 媒体携带广告位标识、当前用户参数及上下文信息请求广告物料
- ssp平台优先检查是否当前曝光广告位是否存在程序化直接购买计划(PDB)
	- 存在, 携带参数请求对应DSP获取广告物料
	- 不存在, 进入交易市场, 携带参数请求ADX发起RTB竞价, 获取竞价胜利平台的广告物料
- 完成广告下发, 并收集记录本次流量处理结果, 供统计报表使用.

补充修改:

- ssp平台不参与竞价, 仅负责服务于媒体,链接需求方,报备媒体广告位并转发请求下发物料
- 大媒体一般不接ssp平台, 他们有自己的平台和规范, 接也是大媒体引入站外流量(采买我们的流量当上游,而不是出售流量当下游)
- 确定技术参数如广告位标识,当前用户,上下文等, 需要按照技术文档下发媒体
- 广告主通过PDB方式投放广告, 一般不会直接对接媒体(太多).
- 物料审核一般由广告平台去做, 大媒体也会做, 包括素材/资质/行业等, 广告主/代理将广告物料上传平台, 平台通过DSP/ADX/SSP进行审核, 确保媒体/平台的利益不受损伤

下一步应该基于当前了解的业务流程, 基于当前已有后台, 设计其他缺失模块, 完整系统架构.

(但还不到具体设计表/sql的阶段.)

平台模块预测

流量请求处理

系统模块设计

运营/媒体端

媒体接入相关:

提供平台SDK/API及相关文档, 方便媒体快速接入ssp平台, 包含以下功能:
- 流量上报, 广告获取接口, 提供当前流量所属用户信息/请求广告位ID/上下文信息
- 事件触发, 流量效果(曝光/点击)上报接口

媒体管理系统:

# 数据包: 
data = [ "媒体" => [ "应用" => [ "广告位" => [] ] ] ]

主要用于运营人员/媒体方填写媒体基础信息, 如媒体,应用,广告位报备等, 应包含以下功能模块:

媒体账号创建:
 - 用于运营人员/媒体填写[媒体账号]基础信息,如账号,密码, 审核状态等, 生成媒体ID及媒体标识码, 用于后续创建应用/广告位及请求ssp接口. 数据存入运营/媒体端数据库
 
媒体应用/广告位管理:
 - 基于媒体ID, 生成填写[媒体应用]数据, 用于区分 应用所属行业、操作系统及包名.数据存入运营/媒体端数据库
 - 基于媒体ID和应用ID, 生成填写[媒体广告位]数据,用于区分该广告位的位置,支持广告类型及尺寸, 附带开关功能.数据存入运营/媒体端数据库, 审核通过后通过同步脚本同步至缓存中,等待引擎取用
 
权限系统/登录系统(非必须):
 - 媒体用户登录,可以新增/编辑/删除/开关应用和广告位, 查看本媒体对应报表数据(也可由运营代操作/导出数据)
 
报表查看系统:
 - 主要用于运营/媒体方查看广告分发结果, 应该包含以下功能:
 - 查看各媒体应用下代码位请求/下发/曝光/点击的统计数量, 及各个参数所占比例. 数据从统计脚本导出结果集中获取

上游报备系统:

主要用于运营人员将媒体广告位报备至第三方平台,并录入报备信息到本ssp平台, 应包含如下功能模块:

上游平台管理:
 - 需要报备的平台清单, 用于关联 报备第三方应用/代码位信息. 数据存入运营/媒体端数据库
 
上游平台代码位报备:
 - 基于第三方平台ID, 向上游平台上传报备媒体广告位信息, 获取第三方应用ID/代码位ID并录入报备基础信息
 - 向ADX报备媒体广告位信息, 获取平台代码位ID/应用ID, 并录入/导入ADX报备信息到本ssp平台
 - 以上数据存入运营/媒体端数据库, 录入后通过缓存同步脚本同步至缓存中,等待引擎取用

流量分配策略制定:

主要用于运营人员根据 现有媒体下游广告位, 当前流量 及 需求方需求, 绑定上下游, 配置流量分配策略

广告位上下游绑定:
 - 依据当前需求为广告位绑定上游需求方, 关联媒体广告位与需求方. 数据存入运营/媒体端数据库, 录入后通过缓存同步脚本同步至缓存中,等待引擎在流量分配时取用
 
(绑定逻辑: 存在绑定关系的,当流量进入时, 直接请求获取对应已绑定【第三方代码位】需求方物料. 未绑定的,依据【ADX广告位信息】进行RTB竞价) 

同步脚本

依据引擎需要数据 以及 运营/媒体端的配置数据, 同步基础信息及配置信息到缓存系统中, 
方便引擎在分发流量时取用, 以提高引擎运行效率及响应速度
应包含以下同步脚本:

- 广告位基础信息同步脚本. 用于流量请求时广告位的信息获取及尺寸的确定
- 第三方报备信息同步脚本. 用于采购/竞价时请求第三方接口时携带参数
- 上下游绑定信息同步脚本. 用于引擎流量确定本次流量的分发方案

方案:
 独立脚本调度路由, 对外提供API/内部调用队列消费者, 通过请求参数执行对应脚本/ 读取队列数据消费处理. 与运营端共享数据库, 读取配置数据, 链接缓存系统, 将数据存入缓存. 
 触发式脚本还是定时脚本

引擎

引擎, 不服务于媒体/运营/需求方, 而是做程序化对接, 需要提供足够快的响应速度,且需要支持大流量并发, 所以需要用到的数据最好从缓存系统中获取,

流量分发:

依据运营端配置, 将媒体流量按照配置信息进行分发, 进行PDB采购执行/RTB竞价, 获取广告物料. 需要具备以下功能:

1.媒体流量请求接收接口. 当媒体携带用户参数发起物料请求时,需要:
 - 请求参数校验, 参数格式是否符合接口规定格式, 必填/格式/参数范围 等
 - 查询缓存系统, 依据请求中携带的媒体代码位ID获取该代码位基础信息. 从而判断请求流量是否属于本ssp平台已备案广告位(媒体鉴权/广告位存在鉴定)
 
2.依据携带广告位ID, 查询缓存中的流量分配策略, 当前广告位是否绑定[第三方代码位]
 - 存在绑定上游, 按配置权重转发当前流量到需求方(解析流量参数,转化为需求方参数)
 - 不存在绑定关系, 获取当前广告位在ADX中的备案信息, 转发给ADX参与RTB竞价
 - 转发请求时需要做接口超时控制. 
 
3.生成本次请求分发结果,记录日志
 - 日志记录可以通过推送到队列的方式写入数据库

广告物料下发

- 从接口返回获取流量分发结果, 解析内容, 匹配当前广告位配置信息(物料种类/物料尺寸),下发物料到该广告位
- 记录物料下发结果到日志中

流量日志记录接口

同流量分发系统类似, 该接口虽然不关注响应时间, 但需要考虑大流量并发请求, 不推荐直接链接到mysql中写入数据.

- 提供给媒体, 由SDK/API发起, 推送广告展现/点击动作记录. 依据流量ID关联到日志中
- 提供给需求方, 需求方回传转化数据, 推送用户落地页操作记录.  依据流量ID关联到日志中 

统计脚本

引擎日志记录日志(流量请求广告物料及结果)后, 通过统计脚本获取统计结果, 以广告位(媒体端/上游)为颗粒度, 生成记录, 推送到运营/媒体端数据库, 供报表系统使用

- 统计参数包括请求量, 展现量, 点击量, 下发量及相应比例等数据
- 筛选条件包括媒体, 广告位, 操作系统类型, 地域, 时间等

- 日志信息存储在文件日志系统中后, 定时脚本按照时间分段获取请求量/展现量/下发数/点击数等数据
- 若存在大量请求, 可以在接收时将日志信息推入队列, 多消费者分时段处理, 提供报表系统需要的基础信息

修改逻辑

- 比起基础的技术实现细节, 应该多关注功能层面的数据流动方向, 及对应的数据逻辑闭环. 
- 需要考虑到运营数据与引擎数据不同库, 配置 相关数据同步到缓存 的脚本
- 报表需要支持哪些功能, 数据从哪里获取, 如何存储, 如何展现, 如何统计

二次修改逻辑

- 系统总架构包括 运营端/引擎/同步脚本/统计脚本(报表/反作弊)
- 一方面需要将整体数据流向画出来, 另一方面要将一次流量处理的逻辑整理清楚
- 讲解ssp平台时, 首先需要介绍整体包含的模块, 模块功能, 在数据处理过程中扮演的角色. 然后再介绍每个模块的具体功能,数据操作流程, 数据获取方式, 数据去向等内容

- 理清各项功能需要操作哪些数据, 如此操作的原因, 以及操作过程中需要注意的事项,边界. 如性能,效率,限制条件等

- 理清系统架构逻辑, 可以帮助更好的理解需求, 判断需求, 选择最优实现方式. 以及从性价比方面过滤非必要需求
- 理清系统架构, 可以帮助处理需求时, 知道需要同步变动的功能/代码, 以及改动带来的系统变化影响
- 不能仅关注功能是否完成, 而不考虑可用性和使用性能

- 后续实际需求关注于后台模块中的数据变动

示例需求:
 - 统计各广告位一定时段内的UV数据
 实现过程中若5min统计一次, 合并所有该时段数据, 那么就会存在一个用户多次点击的重复数据出现,不符合要求
 [
   按广告位ID, 每天创建一个hyperloglog, 即 pfadd [ad_index_date] user1
   每次访问均添加到该数据中 pfadd [ad_index_date] userx.
   获取访问UV结果, 可以通过 pfcount [ad_index_date]
 ]
 
- 需求方如何了解广告的 分发次数/展现次数/点击率 数据呢?
直接对接? 需求方不直接和下游媒体对接的
ssp出报表? 需求方表示怀疑ssp报表的真实性
那就是第三方监测机构(adv)/上游自己做监测:
 - 第三方监测机构/上游需求方 针对当前物料生成监测代码(曝光/点击)
 - 需求方下发物料时, 包含上述生成的监测代码, 与物料同时部署在媒体上
 - 监测代码判断触发曝光/点击时, 发送请求推送事件给第三方监测机构/需求方
 - 第三方监测机构定时出具报告/需求方自己生成广告效果及报表数据

参考资料

虚假流量越多, 导致实际转化成本越高, 广告结算费用越低, 收益下降, 正常ssp平台失去竞争力, 行业越发混乱, 广告主投放意愿降低. 
品牌广告主意愿为加强品牌知名度/凝聚力, 虚假广告影响度延后