2 min read
Day 0 and Day 3 cohort metrics
AppsFlyer 如何防止“应用商店劫持”影响归因？
相比海外Google Play的一统天下，国内的安卓市场显得非常碎片化。不同的应用商店各霸一方，都希望能够提高自己的下载量，导致“劫持”的情况非常流行。那么，应用商店“劫持”会对广告投放与归因造成什么影响呢？要回答这个问题，我们需要一些背景知识铺垫。
首先，我们需要理解广告主会进行“分包”。通常来讲，广告主如果在应用市场A，应用市场B同时上架自己的App，就会打成两个渠道（应用商店）包：APK-A与APK-B，这样可以追踪不同渠道的下载量。另外可能的原因则是应用市场A与B都拥有自己的效果类广告平台，在这些广告平台进行投放时，下载必须指向对应的自有商店。
其次，我们来简要地回顾一下归因逻辑。以AppsFlyer为例，归因的起点是用户激活了嵌有AppsFlyer SDK的App。此时SDK将向服务器发送一条请求，询问有没有见过对应App，对应设备的广告点击数据。另外一方面，AppsFlyer之前已经接收到广告渠道回传的点击数据，从而可以完成归因动作（将激活归因给某个点击）。
现在回到文章开始的问题，应用商店劫持是如何影响归因的呢？有了对“分包”和归因逻辑的理解，我们就可以从整个流程中发现问题了：
- 用户点击广告，目标效果是下载APK-A（点击链接中包含APK-A的包名信息）。
- 用户准备下载时，本地应用商店发生“劫持”，用户其实下载了APK-B。
- 用户激活App，AppsFlyer SDK询问服务器：有见过包名是APK-B的，在这个用户设备上发生的点击吗？
- 服务器回答没有（因为点击信息是指向包名APK-A的）。
- 这个下载激活被归因成自然量（没有广告互动），广告平台错误地被认为没有任何贡献。
细心的读者可能已经发现问题的关键了：有没有办法使APK-A和APK-B的包名一致？这样App激活和点击就可以打通了。但是，APK-A和APK-B的下载量还能同时区分出来吗？
AppsFlyer给出的答案是有办法，能区分！我们提供独特的字段“AF_STORE”可以保证不同渠道包APK-A与APK-B的包名一致，但是同时可以区分他们的下载。
具体的实现方法可以分为两种，选择一种操作即可：
- 技术人员在Manifest里面写入不同的“AF_STORE”值：
APK-A：<meta-data android:name=”AF_STORE” android:value=”A” />；
APK-B：<meta-data android:name=”AF_STORE” android:value=”B” />；
- 技术人员在代码层级利用API写入“AF_STORE”值：
APK-A：AppsFlyerLib.getInstance().setOutOfStore(“A”);
APK-B：AppsFlyerLib.getInstance().setOutOfStore(“B”);
现在我们带着解决方案再回顾一下整个流程：
- 首先，APK-A与B包名一致，但是AF_STORE的值分别是A和B。
- 用户点击广告，目标是下载APK-A（点击链接中包含APK-A的包名信息）。
- 用户准备下载时，本地应用商店发生劫持，用户其实下载了APK-B。
- 用户激活App，AppsFlyer SDK询问服务器：有见过包名是APK-B的，在这个用户设备上发生的点击吗？
- 服务器回答有（点击信息是指向包名APK-A的，但此时APK-A=APK-B）。
- 这个下载激活被归因成非自然量，广告平台被正确归因。同时，AF_STORE=B。目前，这个字段会展示在原始数据报告里。
流程中“劫持”的展现（用户本来是要在应用商店A下载，却被劫持到B）可以参考点击链接信息与广告平台的设置：用户下载的应用商店是B，但是在广告平台上广告主设置的却是A。
通过AppsFlyer提供的“防劫持”方案，广告主可以准确地了解用户获取的真实渠道，同时广告平台的价值也能被正确地体现。
由于篇幅所限，文章没有办法展现所有细节。如果大家还有兴趣进行更加深入的讨论，尽请联系AppsFlyer，我们专业的销售与技术团队会为您服务，助您成功！
