分析了下三方和Firebase的安装数据差异原因：
这一点主要是埋点的时候，逻辑不同造成的差异。比如说对安装的定义，商店是点击了商店的下载按钮就算安装，Appsflyer作为三方是用户下载以后首次打开app算安装，还有的是用户激活之后算安装，所以对同一个点的不同定义导致计数存在差异。不过我们同时接了Appsflyer和Firebase的SDK，然后双平台的打点逻辑完全一致的情况下，数据仍然存在差异，那么大概率就要考虑其他原因了。
这里要分两部分：
一个是平台处理数据的时间差异，因为有些平台的数据处理并不是实时的，可能是分阶段处理的，且不同平台归因到的具体时间点也不会完全一样，有的根据点击时间归因有的根据激活时间归因；另外一个是本身平台的时区设置，也就是时差问题，A平台是国内UTC+8时间，B平台是UTC+0时区这种情况。如果说是时间差异原因的话，可以查看一下分时段的数据，或者一般把对比周期拉长会发现差异是降低甚至逐步减少的，不过对于新产品数据增长较快的情况下，最好是等到平稳期再评估一下时间导致的影响大小。
不同平台的归因窗口设置周期和用户多次卸载重装也会导致数据差异。比如我们Appsfyer老用户归因窗口期手动设置是180天，如果该用户在180天前激活且注册过游戏，Appsfyer归为用户的后续活跃行为，不计算该用户为一个新用户，而Firebase会计算为一个新用户，这也会导致数据的差异。
这个是谷歌搜索到的一个关于Firebase数据偏多的原因：当现有用户迁移到包含Firebase的新版应用程序时，即使不是新用户，Firebase也会记录first_open。 也就是说，如果发版的时候用户不断迁移或者经过版本更新，那Firebase的first_open将会不断重新记录。谷歌官方也有表示过会优化这个情况，目前为止还是会有这个情况。
还有一个是数据对接的方式和端口区别，如果用的是服务器的数据和客户端的数据前后也会有差别，这部分涉及到具体的代码调用和技术细节了，需要跟技术部门确认好相关的使用区别。另外一方面就是SDK的版本更新等导致的数据回传异常等问题的可能性也需要考虑在内，这一点可以直接跟三方沟通差异进行确认。
观察数据之间差异也可以帮助我们更深刻的了解用户行为。当然还可能有别的未知原因未被发现，如果有其他可能原因也欢迎告知。
下拉推荐菜单可查看更多精彩内容↓
发表评论 取消回复