摘要： 在广告商业化变现中，靠关键事件买量越来越是新的趋势，几乎国内的广告买量都趋于关键事件买量，什么是关键事件，就是你希望用户在你产品产生关键行为的事件，你需要买的用户你都期望发生这个事件，比如我们的订阅游戏，关键事件可以设置为通过防成迷的用户，且点击了订阅面，且完成了订阅的用户，这种行为我们称为关键事件行为。
关键事件数据量： 当我们的日志平台收集到这些关键行为，需要有个配置页面，这个页面配置好关键事件的规则，那么定时的去扫描日志数据，发现有满足的用户，把这个用户信息通过接口API的方式调用归因平台。因为在各个投放渠道，当用户点击下载APP的时候，投放渠道会把信息通过归因链接回传给归因平台，那么归因平台有投放渠道的用户和设备信息，当关键行为通过Api传回给归因平台，会带上用户和设备信息，归因平台会通过匹配知道这个用户是哪个渠道来的，把信息再通过callback链接传回给对应的投放渠道，投放渠道收到关键行为信息后，会通过自己平台的用户画像信息去查询和这个关键事件相似的用户，把这种用户推给APP内，那么我在投放渠道买的用户就是满足我关键行为的用户。
举例：：比如触发了广告事件（task_ad_content__imuserdata）次数大于1次，且ecpm大于等于20，且广告类型为（reward）激励类型。触发了这些条件的用户就是我要买的关键事件用户，是我最想要的用户。我就买这种关键事件。配置如下：
需求背景情况： 此前关键事件是业务线自己在App内部配置，配置完了去买量，如果发现跑的不理想，就需要修改关键事件，重新发版本，且每次都是凭经验试关键事件的配置。如果有某个广告商的回传策略变更了，需要开发人员改动代码来实现，人力成本会更高，而且不够灵活，从需求提出到上线可能需要几周的时间。
-
希望中台利用sdk报上来的数据做预测，以及灵活配置关键事件，把满足关键事件的用户回传给（归因平台热云），归因平台再整合激活信息传给投放平台，告诉投放平台要按照的关键行为购买用户。
-
预测需要哪些指标做预测
| 新用户 | 按渠道分，触发了install事件的用户 |
|---|---|
| 关键事件触发用户数 | 按渠道分，触发了install事件的用户，且在触发install事件后6小时，触发了关键事件。 |
| 关键事件渗透率 | 2/1就是关键事件渗透率 |
| 人均关键事件转换时长 | 关键事件触发用户数用户所用的时长总和（分钟）/关键事件触发用户数 |
| 次日留存 | 关键事件触发用户在第2天登录的用户数/关键事件触发用户数 |
| 第3日留存 | 关键事件触发用户在第3天登录的用户数/关键事件触发用户数 |
| LTV0 | 关键事件触发用户+ 该用户当天task_ad_content__imuserdata里ecpm加总 除以1000 再除以关键事件触发用户数 |
| LTV1 | 关键事件触发用户+ 该用户当天 和次日task_ad_content__imuserdata里ecpm加总 除以1000 再除以关键事件触发用户数 |
| LTV2 | 关键事件触发用户+ 该用户当天 和次日 和第三日task_ad_content__imuserdata里ecpm加总 除以1000 再除以关键事件触发用户数 |
| 人均停留时长 | （关键事件触发用户在产品内的停留时长总和/触发关键事件的新用户 ）单位分钟 |
需求实现： 能计算出预测值。把整个链路打通，业务线可以配置关键事件，然后回传给热云，热云再把信息回传给投放渠道（抖音，快手，百度等）完成关键事件买量。
-
方案选择：
- 上述所有的预测计算查询的数据是我们自建的日志数据平台，都是历史表存的数据，就是某一个产品从产品上架产生的的数据都在这个表，我们固定查询七日数据做预测，每天的数据都取的是触发了install事件的用户，且在触发install事件后24小时，触发了关键事件的用户。
- 数据是否从历史日志表取，业务需要实时数据允许延迟十分钟，意思是每十分钟都需要扫秒表去查询满足关键事件的用户，且如果一旦满足关键事件的用户，不能再重新上报到热云。
- 如果在历史日志表去查询，且还需给用于打上报过关键事件的标签，且这张表业务会用来查询各种分析模型。每十分钟查一次历史表，且需要加状态字段，且去修改上报标签的字段，会拖慢业务查询，影响业务对日志平台使用，且历史日志表数据量大，查询会很慢。
- 最终方案：关键事件建一张新表，里面就存配置的关键事件的事件和属性，哪个产品哪个包配置哪些关键事件，把这个产品和包信息存下来，当配置完成接下来有日志消费的时候，判断满足此产品和此包以及此事件的且事件打的install_time和当前时间比较是24小时之内的数据存到新的关键事件的新表中。且这张事件表的日志生命周期最多保存24小时，那么整个查询数据量会很少，不会有查询效率的问题，也不会影响业务线对日志平台的使用。
- 上报归因平台热云的数据每隔十分钟扫秒的数据去新表查询。意思是配置完关键事件之后的时间sdk打上来的新用户满足关键事件的才能上报。且每次上报完更新标签。
-
上报热云必须要哪些属性
- 关键行为：可选为event_1到event_12任意一个
- appid：热云的唯一id，这个id会在归因平台建应用的时候生产。
- ryId：热云id，sdk日志上报
- os: sdk 日志上报 操作系统
- idfa:sdk日志上报 IDFA--ios
- model:sdk日志上报 model
- ip:sdk日志上报
-
用户标签
- 业务希望我们除过支持现有埋点的事件下的私参，公参，以及用户的属性，需再支持两个虚拟属性用来计算
- LTV0：LTV0很好理解，每个人触发了task_ad_content__imuserdata里ecpm加总 除以1000 的值来判断是否满足。
- LTV0等级：中台数仓算出当天24小时之内的新用户满足task_ad_content__imuserdata里ecpm加总再除以1000的值排名，然后把值按从大到小排序，分成是10等份，给出每一等份对应的值，比如10%对应的值0.1，那么选择0%-10%就是选择ltv0为前百分之10的值，就是查询ltv0大于0.1的值，同理20%代表0.03。那么查询10%-20%就是查询ltv0大于等于0.03小于等于0.1的值。
结论： ：至此一个能灵活查询预测数据，和能实时配置和修改商业化广告买量的关键事件买量模块就完成了，根据关键事件买量比根据激活买的数量质量更高，会给企业广告主带来更大的收益，也是国内广告买量跑法的主要买法。
