海外流量平台搭建实践
背景
目前公司大力发展海外项目，海外产品越来越多，流量投放和数据看板的需求也越来越强烈，流量平台需要快速搭建起海外环境。
虽然可以复用国内的部分功能，但海外业务和国内业务存在区别，仍需要一定的扩展开发。
国内用户角色控制粒度不够细致，不能区分产品线，希望在本次的搭建过程中进行优化。
海外的数据看板和国内不一样，不能直接复用。
产品接入流程和国内不一样，也需要重新梳理自动化接入流程。
海外归因回传逻辑和国内不一样，需要重新搭建归因服务。
针对以上区别，我们将从系统的整体框架、用户权限控制模块、产品自动化接入模块、appsflyer归因回传模块等方面介绍本次平台搭建工作。
1、系统整体框架
搭建海外平台所需的核心服务包括：管理平台服务、数据接入服务、新增设备服务、归因回传服务、离线任务服务等
服务之间关系如下图所示：
管理平台服务：管理平台的前端和后端服务，用于业务产品的接入配置，数据报表展示，广告账号管理，广告批量搭建等功能。
数据接入服务：各个业务线的产品通过kafka上报激活、登录、支付等端内行为，数据接入服务通过配置的kafka信息消费数据，并判断是否新增设备，然后将数据通过kafka统一上报给归因回传服务。
新增设备服务：该服务通过设备标识来判断是否是新增设备，主要通过维护redis中的激活池来实现。
归因回传服务：将归因数据回传给appsflyer，另外还有facebook、tiktok等媒体的pixel数据回传。
离线任务服务：通过对接各媒体的marketing api，从媒体拉取账户的广告数据，用于数据报表展示使用。
2、用户权限控制
对于用户权限控制模块，最主要的核心需求有两个：
支持角色的细粒度划分，用户对不同的产品可以有不同的角色。
支持自动新增权限，有些用户有整个项目组的权限，当该项目组新增产品时，自动赋予这些用户新增产品的权限。
为了实现上述功能，我们引入了团队、项目组概念，一个团队下有多个项目组，一个项目组又包含多个产品，如下图所示。
产品组织结构图：
权限信息通过项目组成员权限表来关联，一个用户可以有多个项目组的多个角色权限，并且用户可以用于该项目组下所有产品的权限，或者部分产品的权限，通过has_all_app字段来标识用户是否拥有项目组的所有产品权限。如果是全部产品权限，那么后续如果有新的产品接入，用户可以自动获得权限。
在查询用户拥有的产品信息时，有一个需要权衡的点：
读扩散，如是全部产品权限，需要再次查询该项目组拥有的所有产品。新产品写入时权限表做处理。
写扩散，在新增产品时，更新用户的app_id_list字段，读取时只需要查项目组成员权限表，不再查询该项目组拥有的所有产品。
我们采用的是第二种方式，因为产品新增的频率较低，并且更新时可以通过'has_all_app='全部'批量更新，处理起来也很容易。
3、产品自动化接入
产品自动化接入，要求在有新产品接入时，能够更加的流程化和自动化，主要功能包括：
产品元数据接入，国内chl平台是由映客云自动同步的所有产品信息，海外波塞冬平台会定期从chl平台将海外产品的信息拉取过来。
数据源接入，如appsflyer sdk数据源的kafka自动配置，用户中台和金融中台的实时kafka任务调起等。
数据看板相关依赖调起，包括基础ck表自动创建任务调起、数据集创建任务调起、数据看板相关任务调起等
产品接入流程图：
业务方能够在波塞冬管理后台方便的查看当前产品的接入情况，接入状态如下图所示：
接入状态展示图：
具体接入流程如下：
1、用户将sdk接入状态修改为已接入后， 配置kafka到appsfyler_kafka_config表，并且调起激活池状态服务。
2、查询中台接入状态，如果是已接入状态，调起用户中台数据任务， 调起金融中台数据任务。
3、流量离线任务调起。
4、生成基础ck表任务调起。
5、生成数据集任务任务调起，包括实时和离线数据。
6、数据看板异步任务调起，轮询看板任务状态至已完成，保存生成的报表id。
执行流程图如下：
4、广告批量搭建功能
为了更高效地支持业务方创建广告，流量平台通过对接媒体的marketing api，提供了批量搭建广告的功能。如下图所示:
1、业务方选择需要创建的广告的应用。
2、选择创建广告的账户，这里可选择多个账户，同时向多个账户中创建广告。
3、选择广告的基建模板，也就是媒体要求的一些广告设置，如广告类型、系列目标、优化目标等。
4、选择广告受众，确定广告投放的目标人群。
5、选择文案，因为需要一次搭建多个广告，可以选择多个。
6、选择素材，从素材库选择所需的视频素材，广告创意是由文案和素材组成。我们会把文案和素材排列组合，构建出多个广告创意。
最后点击发布即可提交创建任务，后台任务会调用媒体接口创建广告。在推广任务管理页面可以查看创建结果。
5、归因数据回传
海外的归因处理和国内存在很大的不同，国内的归因服务是流量平台直接对接各家媒体，接收媒体上报的点击数据，然后消费客户端上报的心跳、登录、支付等数据，和点击进行匹配归因，归因成功后再回传给相应的媒体。海外我们没办法直接对接媒体，而是通过appsflyer第三方来对接的。所以只需要将数据回传给appsflyer即可，逻辑其实更简单了。
前期是客户端sdk直接在端上将数据回传给了appsflyer，而没有通过流量平台回传。但是考虑到后续的扩展性和灵活性，还是决定修改为流量平台服务端回传的方式。流程如下:
1、在app启动时af sdk 自动将激活上报给埋点服务，埋点服务将数据推送到kafka中。
2、如果app对接了用户中台sdk和金融中台sdk会将登录、支付事件上报给中台服务，不再通过埋点服务上报。数据格式采用日志埋点格式。
3、中台服务通过日志收集方式，将登录、支付事件收集到大数据kafka中，需要携带appsflyer_id。
4、大数据测消费kafka激活数据，将新增数据推送到redis激活池
5、数仓消费kafka数据，用于生产激活、登录、支付报表。
6、流量服务消费kafka数据，解析refer数据，获取广告信息，保存到数据库中，同步给数仓统计使用。同时将数据通过kafka推送给流量归因服务。
7、流量归因服务，判断是否需要回传，如果回传，则将事件回传给appsflyer。
系统交互如下：
对比客户端回传方案，当前方案有以下优势：
客户端：
简化了客户端sdk的复杂度，只需要上报事件埋点即可，不再需要和服务端进行复杂的交互和判断回传逻辑。
接入更加灵活，业务方选择sdk自动上报，或者自行封装协议上报。
服务端
回传更加可控，通过监控告警，提升回传的健壮性。通过失败回溯方式，提供更好的容错性。
并且使回传口径保持一致，口径调整更方便，不用依赖客户端发版。
流量服务不需要在所有海外集群部署，仅部署tx-sg集群，其他集群通过专线消费kafka即可，降低使用aws集群的费用。
能够针对特定的场景进行优化，比如appsflyer 10s的多次事件会排重，服务端可以通过延迟队列等方式进行优化。
数据端
口径统一，回传事件由流量平台统一处理，保证了回传口径和事件名称的一致性。避免不同产品对相同事件回传不同名称，带来的统计不一致的问题。
未来规划
支持更多媒体的广告批量搭建，目前仅上线了facebook的批量搭建功能，tiktok也在接入中，google、kwai等媒体也将逐步接入。
自动化投放探索，目前我们通过总结一些业务方投放的经验，来制定出相应的自动化策略，比如成本过高可以自动减预算、成本低自动增加预算等。后面将尝试对整个广告的生命周期进行管理。