Appsflyer 实现 后端行为上报行为的思路+坑

正好遇到，解决后做个记录。

对接Appsflyer的时候，如果需要给AF回传后端行为数据，比如：支付完成、订阅续费、客服操作、后台补单等App端没有直接触发，必须通过后端上报的事件，有两个思路来实现事件上报。

A，通过S2S方式直接给AF上报。

按照官方给的标准操作，去security center里面创建S2S token，再按照文档操作回传事件即可。

B，通过客户端SDK上报给AF，但是需要额外处理一些东西。

由于之前接触到的项目，技术都直接通过方法2里面自行处理，没人来要过S2S token，一度让我以为他们用S2S方式回传的时候也用的是APP DEV KEY，然今天发现并非如此，S2S的token和APP DEV KEY并非一个，只是技术因为觉得找我要单独的token麻烦，所以自己用下面的一些方式实现了同样效果：

把服务端数据，先给到客户端再让客户端按照SDK上报方式上传给AF。

这个地方也存在一些差别，比如可以是服务端主动通知客户端APP再去上报，或者服务端把数据先收集，等APP启动的时候或者定期上报，这就有个大坑，如果APP是不活跃，那么数据就不会被及时上报，但是好在比如用户充值这样的行为，本身就是在APP端内实现的，这会APP正活跃没问题，但是如果产品是订阅类的，用户先开启了免费试用3天，等到3天后自动续费成功，这个行为再通过APP客户端去上报就可能存在用户没有及时启动APP，上报延迟，甚至很多用户直接忘记取消续订，APP后续根本没再活跃，这个行为也就不会被上报。所以这种时候，用S2S的方式上报更稳妥一些。

另一种情况，比如本身是多端的产品，安卓，iOS，H5一起，用户可能是从安卓来的，但是iOS或者H5这边实现了后端行为，这个时候应该如何上报这个付费，服务端实际上也是可以决定好通过谁来上报，最后通过把数据给到端这边再等到下一次启动或者定时（APP需要活跃）的时候去上报。

所以从目前的情况看，分产品来考虑自己是否可以用方法B，比如本身业务本身都是在APP端行为完成的，不会存在实时性问题的行为，也可以通过客户端做回传的方式解决，只需要和客户端那边做一下配合，决定到底是实时上报还是定时上报等细节。从官方给的解决方案看，其实他有点鼓励大家走S2S的方式上传，但是S2S开发的方式也有个关键的点：要解决归因标识（appsflyer_id）匹配问题。

以前就有过专门的文章去介绍小贷打点时候用的是用户首次注册的afid还是末次login时候的afid，这个里面逻辑又会涉及到一堆细节导致投放难度发生变化。技术上服务端需要处理用户的uid和afid的映射关系，再根据uid来考虑给afid回传转化事件，如果通过app sdk直接上报的方式，应该是直接用当前设备信息做上报，默认就是末次设备上报，更有利于广告投放一些。

非技术人员对这块的理解，仅供参考，里面不少细节，也许等到大家遇到同类问题在来考虑最优解，平时基本用不到。