正好遇到，解決后做個記錄。

對接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直接上報的方式，應該是直接用當前設備信息做上報，默認就是末次設備上報，更有利于廣告投放一些。

非技術人員對這塊的理解，僅供參考，里面不少細節，也許等到大家遇到同類問題在來考慮最優解，平時基本用不到。