广告数据生产流转链路

send事件
- 千川(oCPM)广告是按send事件计费的。

客户端事件
- 客户端主要是指我们公司所有的app（抖音、头条、火山等）、以及穿山甲接入的各类媒体侧等，主要功能是展示广告和内容，并对事件（广告和非广告事件）进行上报。例如展示、播放视频、点击、下单等事件。

ACK事件
- 在发送send事件前，会先调用engine的ack接口，我称之为ACK事件。
- Send事件是服务端能感知到的最及时的事件，其他事件都是客户端触发。

AdLog
adlog是一个承上启下的商业化数据处理节点，主要提供统一的数据抽取、回填、拼接等基础功能，并且收敛了的统计、计费、转化等业务的口径。

“承上”的意思是，adlog接受了所有的广告客户端埋点事件，以及服务端事件。“启下”意思是将处理好的数据，分发给下游多个核心业务方，如广告各端模型，统计，计费，AB实验等。

包括三部分，union_dispatch，AdLog，分流服务。
1 union_dispatch
初步处理数据。例如将原始的客户端事件，进行一定的抽取，转换，打平成后续的业务处理所需要的事件格式。
2 AdLog
- 数据库数据回填：数据库数据回填主要是针对客户端上报的value(即creative_id)，请求nebula接口和db，关联到其他维度的信息。例如adid、advid等。
- send拼接：客户端每一次广告请求，都会对应一次服务端send，send会以事件的形式下发到下游数据流，而拼接的目的就是将服务端send事件中的很多字段拼接到客户端对应这一次send回流的客户端事件上，主要包括show，click，convert事件等。对于convert事件，有额外的需求拼接到对应的click事件。拼接到字段主要用于下游模型，统计、分析等；
- 统计口径：收敛统计相关基础指标的口径；
  - send：这个指标一致性比较高，基本不需要特殊处理
  - 展示：将某些特殊事件映射成展示指标，例如开屏的play转show，
  - 点击：将某些特殊事件映射成点击指标
  - 转化：有效转化，不匹配作弊
  - 播放相关：有效播放
- 计费口径：应该对哪些事件计费&对这个事件计费多少钱；
- 数据分发：在之前下游依赖方多的时候，adlog写出了多个流供下游使用，该功能逐渐收敛到分流服务。
3 分流服务
  通过细化topic粒度，使业务方只消费必要的数据来缓解kafka出口带宽过高的情况。

转化归因
1 归因是什么
狭义上：广告信息拼接，转化事件拼接到广告信息(req_id、cid、rit)。
广义上：客户价值分配，在众多用户的触点(包含广告和自然)中，判定转化事件是由哪一次/多次触点带来，度量每一次触点的真实增效价值，量化不同媒体/来源对转化的影响程度，指导合理的媒体预算分配。

技术上是触点数据和转化行为数据的拼接。

- 直接归因：广告归因窗口期(30min)内，带来的直接转化。
- 间接归因：3/7/15/30天内，带来的转化。


"Last Click Attribution" 是一种短期归因模型，而不是长效归因模型。它将转化事件的全部归因权重归给用户最后一次点击或与广告交互的触点，忽略了其他触点的贡献。

长效归因（Long-term Attribution）旨在考虑较长时间范围内广告触点对转化的综合影响。它需要评估广告触点在转化路径中的各个阶段的贡献，而不仅仅是最后一次点击。

在长效归因中，通常会使用多种模型和方法来量化各个广告触点的贡献。


实时计费系统架构
1 流控应扣聚合模块
消费原始计费事件，聚合应消耗数据到Redis提供给流控服务，主要有未扣费数据。

2 消耗聚合服务
对原始的计费事件进行聚合，产出广告计划维度粒度的应消耗数据。

3.实时扣费服务
实时获取MySQL新增未扣费数据，进行实时扣费，产出消耗数据。

4.消耗拆分服务：
实时获取MySQL新增已扣费数据，拆分出广告位的实际消耗数据，用于统计数据产出。

统计数据产出
将事件进行聚合处理，以准确、及时地披露给广告主，便于广告主根据统计数据及时进行投放策略优化。