正好遇到，解決后做個(gè)記錄。

對(duì)接Appsflyer的時(shí)候，如果需要給AF回傳后端行為數(shù)據(jù)，比如：支付完成、訂閱續(xù)費(fèi)、客服操作、后臺(tái)補(bǔ)單等App端沒有直接觸發(fā)，必須通過后端上報(bào)的事件，有兩個(gè)思路來實(shí)現(xiàn)事件上報(bào)。

A，通過S2S方式直接給AF上報(bào)。

按照官方給的標(biāo)準(zhǔn)操作，去security center里面創(chuàng)建S2S token，再按照文檔操作回傳事件即可。

B，通過客戶端SDK上報(bào)給AF，但是需要額外處理一些東西。

由于之前接觸到的項(xiàng)目，技術(shù)都直接通過方法2里面自行處理，沒人來要過S2S token，一度讓我以為他們用S2S方式回傳的時(shí)候也用的是APP DEV KEY，然今天發(fā)現(xiàn)并非如此，S2S的token和APP DEV KEY并非一個(gè)，只是技術(shù)因?yàn)橛X得找我要單獨(dú)的token麻煩，所以自己用下面的一些方式實(shí)現(xiàn)了同樣效果：

把服務(wù)端數(shù)據(jù)，先給到客戶端再讓客戶端按照SDK上報(bào)方式上傳給AF。

這個(gè)地方也存在一些差別，比如可以是服務(wù)端主動(dòng)通知客戶端APP再去上報(bào)，或者服務(wù)端把數(shù)據(jù)先收集，等APP啟動(dòng)的時(shí)候或者定期上報(bào)，這就有個(gè)大坑，如果APP是不活躍，那么數(shù)據(jù)就不會(huì)被及時(shí)上報(bào)，但是好在比如用戶充值這樣的行為，本身就是在APP端內(nèi)實(shí)現(xiàn)的，這會(huì)APP正活躍沒問題，但是如果產(chǎn)品是訂閱類的，用戶先開啟了免費(fèi)試用3天，等到3天后自動(dòng)續(xù)費(fèi)成功，這個(gè)行為再通過APP客戶端去上報(bào)就可能存在用戶沒有及時(shí)啟動(dòng)APP，上報(bào)延遲，甚至很多用戶直接忘記取消續(xù)訂，APP后續(xù)根本沒再活躍，這個(gè)行為也就不會(huì)被上報(bào)。所以這種時(shí)候，用S2S的方式上報(bào)更穩(wěn)妥一些。

另一種情況，比如本身是多端的產(chǎn)品，安卓，iOS，H5一起，用戶可能是從安卓來的，但是iOS或者H5這邊實(shí)現(xiàn)了后端行為，這個(gè)時(shí)候應(yīng)該如何上報(bào)這個(gè)付費(fèi)，服務(wù)端實(shí)際上也是可以決定好通過誰來上報(bào)，最后通過把數(shù)據(jù)給到端這邊再等到下一次啟動(dòng)或者定時(shí)（APP需要活躍）的時(shí)候去上報(bào)。

所以從目前的情況看，分產(chǎn)品來考慮自己是否可以用方法B，比如本身業(yè)務(wù)本身都是在APP端行為完成的，不會(huì)存在實(shí)時(shí)性問題的行為，也可以通過客戶端做回傳的方式解決，只需要和客戶端那邊做一下配合，決定到底是實(shí)時(shí)上報(bào)還是定時(shí)上報(bào)等細(xì)節(jié)。從官方給的解決方案看，其實(shí)他有點(diǎn)鼓勵(lì)大家走S2S的方式上傳，但是S2S開發(fā)的方式也有個(gè)關(guān)鍵的點(diǎn)：要解決歸因標(biāo)識(shí)（appsflyer_id）匹配問題。

以前就有過專門的文章去介紹小貸打點(diǎn)時(shí)候用的是用戶首次注冊(cè)的afid還是末次login時(shí)候的afid，這個(gè)里面邏輯又會(huì)涉及到一堆細(xì)節(jié)導(dǎo)致投放難度發(fā)生變化。技術(shù)上服務(wù)端需要處理用戶的uid和afid的映射關(guān)系，再根據(jù)uid來考慮給afid回傳轉(zhuǎn)化事件，如果通過app sdk直接上報(bào)的方式，應(yīng)該是直接用當(dāng)前設(shè)備信息做上報(bào)，默認(rèn)就是末次設(shè)備上報(bào)，更有利于廣告投放一些。

非技術(shù)人員對(duì)這塊的理解，僅供參考，里面不少細(xì)節(jié)，也許等到大家遇到同類問題在來考慮最優(yōu)解，平時(shí)基本用不到。