预警！英国第二大港口的码头工人接下来可能会因为工资纠纷而举行罢工...
这几天遇到一个产品在Appsflyer上的数据表现非常奇怪，广告渠道过去的用户在靠后的event上完成率极低，但是在自然量上却异常多出来大量转化数，而且明显events count 和unique user的比重也比较奇怪，最高时候达到了10：1的比例，自然量里面甚至会出现某个event的unique user为0，但是event count超多的现象。
经过一系列的排查后发现：
1，靠后的event 都是走的服务端在s2s回传。
2，服务端回传时候使用的afid是按照最新更新的afid来，并非按照用户安装+用户注册时候记录的afid进行回传。
3，确认了一个逻辑，如果用户在安装app后有卸载再次安装的行为，afid会重置一次。
按照上述的逻辑，如果服务端每次按照最新的afid来做event回传，再加上产品可能出现一些问题，或者在某些落后地区用户有习惯性重装APP的时候，就会出现上述现象。如果产品重装的现象不明显，一般不容易被发现，顶多会觉得买量效果差了点，自然量数据还不错。
具体解决思路也比较简单：
1，用户注册时候直接把用户的afid和注册信息绑定，后续该用户完成后续行为的时候，直接按照注册时的afid（这个afid会对应来源的渠道）回传，能保证尽可能的把后续event算到买量的渠道来源去。
2，用gaid来和afid做个关联，再关联到注册信息，按照最早gaid和注册信息再加adif绑定一起，如果后续用户有重装，并且还重置过手机，就干脆溯源到最早的gaid+afid回传event。确保所有event都能回传到了最初用户安装时候来源的渠道上。
不过这个处理方式也可能会存在一些小问题，比如用户reinstall的问题，按照af的再归因逻辑默认90天之后重装的用户算个新用户，但是我们自己如果写死了每次给首次注册afid回传也会导致我们未来再看数据的时候，这些再归因进来的用户后续转化不理想。时间长了，可能还会造成三方数据和广告平台之间数据差异（广告平台不一定认afid，估计还是gaid，所以可能广告平台上会有转化，但是AF reinstall的没有后续转化数据）。
所以大家在处理服务端回传时候是否遇到了这个问题？如果有这个问题，大家的处理逻辑是什么呢或者说我应该去解决为何用户会重复安装
我们建了一个亚马逊卖家交流群，里面不乏很多大卖家。
现在扫码回复“ 加群 ”，拉你进群。
热门文章
*30分钟更新一次
