cover_image

海外流量平台搭建实践

陈振伟 映客技术
2023年11月24日 07:10

背景

目前公司大力发展海外项目,海外产品越来越多,流量投放和数据看板的需求也越来越强烈,流量平台需要快速搭建起海外环境。

虽然可以复用国内的部分功能,但海外业务和国内业务存在区别,仍需要一定的扩展开发。

  • 国内用户角色控制粒度不够细致,不能区分产品线,希望在本次的搭建过程中进行优化。

  • 海外的数据看板和国内不一样,不能直接复用。

  • 产品接入流程和国内不一样,也需要重新梳理自动化接入流程。

  • 海外归因回传逻辑和国内不一样,需要重新搭建归因服务。

针对以上区别,我们将从系统的整体框架、用户权限控制模块、产品自动化接入模块、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等媒体也将逐步接入。

  • 自动化投放探索,目前我们通过总结一些业务方投放的经验,来制定出相应的自动化策略,比如成本过高可以自动减预算、成本低自动增加预算等。后面将尝试对整个广告的生命周期进行管理。


    继续滑动看下一个
    映客技术
    向上滑动看下一个