广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
s2s 监测上报
s2s 监测上报，是 ADX 将广告的曝光、互动[点击/播放/下载/关闭…]、Win 数据以 接口形式进行回转给 DSP[广告主]。
广告主依据此数据，进行数据归因及结算，是阐述/同步广告投放效果的核心通道。
s2s 、c2s
在 ADX 中，监测上报以上报源区分为两种，c2s 和 s2s 。
- c2s 为端上报，数据在终端上产出，直接发送给 DSP 侧，进行相关归因处理。
- s2s 为服务端上报，数据由终端生产后，将回传至平台服务端。由平台服务端进行拆解/归类后，以宏定义的方式上报给 DSP 侧。
两者由于链路不同，也造就了各自的应用场景。
- c2s 携带大量的设备信息、更真实、时效更高，但格式为原生数据，需 DSP 具备一定的数据分析/处理/挖掘能力。
- s2s 只包含 DSP 指定字段、数据格式可定制化、且更直观，但由于数据链路长，数据效果存在细微损耗/误差。
曝光/互动/Win数据上报
DSP 关注的除了曝光数据外，还有互动数据、自家广告物料在平台竞价情况[尤其是 RTB 模式-实时竞价]。
图中注意到，曝光/互动/Win 数据都是由 Client 经过结算侧 之后流入 ADX 的。这个原因是我们发送给 DSP 的数据要和 结算的数据保持统一口径，且结算侧会对流量数据进行 专业的反作弊 及 数据去重 等数据挖掘逻辑。
还有就是 曝光 和 Win 数据源是一致的。意味着，一条曝光对应着广告位中候选竞价胜出的记录，完成 数据链路上的逻辑自洽。
监测上报
监测上报，我们是通过 API 的方式进行网络传输。
上报使用的 URI 是在向 DSP 索要当前流量适配的广告候选内容中夹带的。这些数据会被封装，流进曝光/Win、互动数据中。
在上报之前，会对数据进行有效性校验，然后才会对字段进行拼接/整合，以 body 体的形式下发给 DSP。
流程图中的 一级 Redis 、二级 HBase 缓存，数据是由 曝光数据流转 阶段注入。[详细流程参看 “日志中心-曝光数据流转结算”]
AB 实验平台
广告业务中，数据通常作为业务前进的内在驱动力之一。AB 实验平台就是以实验数据来衡量各个需求变更、未来业务发展方向、及业务潜在增长点 的重要辅助决策工具…
见后续文章！
推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”
广告业务系统 之 框架沉淀 —— “数据消费型服务框架”
广告业务系统 之 智能保险丝 —— “智能流控”
广告业务系统 之 敏捷交付 —— “基于 Docker 容器同机部署”
广告业务系统 之 业务串联 —— “ PDB - 广告投放【保量保价】”
三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…