在对接 Appsflyer（AF） 的过程中，如果需要向 AF 回传一些后端行为事件，比如「支付完成」「订阅续费」「客服操作」「后台补单」等，这类事件通常并不是由 App 端直接触发的，因此必须通过后端进行上报。
针对这种情况，一般有两种实现思路👇：
A. 通过 S2S（Server to Server）方式直接上报
这是官方推荐的标准方式。
你需要在 Appsflyer Security Center 中创建一个 S2S Token，然后按照官方文档说明，通过该 Token 将事件回传给 AF 即可。
这种方式由后端直接与 AF 通信，可靠性高、实时性强，适合服务端产生或延迟触发的行为。
B. 通过客户端 SDK 进行上报
另一种思路是，让客户端 SDK 来完成上报，但由于事件源头在后端，因此需要做一些额外处理。
我之前接触的一些项目中，技术团队大多采用这种方式——即使事件来自后端，也通过客户端 SDK 上报。那时没人找我要过 S2S Token，一度让我以为他们回传事件时使用的就是 App Dev Key。
结果今天才发现，S2S Token 和 App Dev Key 并不是同一个东西。
之所以他们没要 Token，是因为觉得申请太麻烦，于是采用了一个“曲线救国”的办法：
👉 把服务端产生的数据先发给客户端，再由客户端通过 SDK 上报给 AF。
两种方式的差异与潜在问题
这种“服务端转客户端上报”的方式本身可行，但存在一些细节差异，比如：
- 服务端可以主动通知 App 去上报；
- 或者先将数据存储，等 App 启动时或定期再进行上报。
不过，这里就容易踩坑。
如果 App 长期不活跃，那这些事件就无法及时上报。
举个例子：
- 对于充值类行为，用户是在 App 内完成支付的，此时 App 是活跃的，上报没有问题；
- 但对于订阅类产品，比如用户开启了 3 天免费试用，3 天后自动续费成功，这种情况下如果用户没有重新打开 App，客户端就无法触发上报。
于是，数据会延迟，甚至完全丢失。
因此，在涉及延迟触发或非前台行为时，采用 S2S 方式上报会更稳妥。
多端产品的特殊场景
如果你的产品是多端协同的，比如同时有 Android、iOS、H5，那就更容易遇到跨端触发的问题。
比如：用户最初来自 Android，但后续行为（如支付）发生在 iOS 或 H5 端。
这种情况下，就要由服务端统一判断并决定由哪个端进行上报：
- 可以由后端将数据再发给对应端，等下一次启动或定期上报；
- 但同样存在 App 需活跃 的前提条件。
因此，是否采用方式 B（客户端上报），要根据产品特性来判断。
如果核心业务都在 App 内完成、实时性要求不高，那么通过客户端配合回传是可行的。
只需与客户端开发沟通好——是实时上报还是定期上报即可。
官方建议与关键技术点
从官方的设计角度来看，Appsflyer 更倾向于开发者使用 S2S 上报，因为它更加安全、可控。
但要注意，S2S 开发方式中有一个关键问题需要解决：
👉 归因标识（appsflyer_id）的匹配。
在以往项目中，也有文章专门讨论过：
比如在小贷类业务里，应该用“用户首次注册时的 afid”还是“最后一次登录时的 afid”？
不同逻辑会影响投放数据的精度和后续归因匹配。
服务端在实现时，需要建立 用户 uid 与 afid 的映射关系，再根据 uid 向对应的 afid 回传转化事件。
而如果是通过 App SDK 直接上报，那么上报的就是当前设备信息，也就是“末次设备”的 afid——这通常对广告投放更友好。
总结
以上内容主要从非技术视角，对 Appsflyer 后端事件上报的两种方式进行了梳理。
具体实现过程中还有不少细节，实际方案要结合产品类型、上报场景、用户活跃特征等因素综合考虑。
当真正遇到类似问题时，再深入研究最优解即可——毕竟在多数日常项目中，只有特定业务场景才会用到这些细节。
问题找早鸟出海，早鸟出海（NBOVERSEA）深耕出海近十年。专业提供谷歌、苹果APP代上架服务，支持PWA/W2A/H5/APP广告代投，提供Google/Facebook/Tiktok广告账户，谷歌/苹果开发者账户，一站式解决您的后顾之忧。如有任何疑问，请点击服务流程或咨询飞机：@nboversea