应用统计分析是App里很重要的一部分。我厂以前用的友盟，最近又集成了Talkingdata，来弥补友盟的一些不足，顺便比较下这2个应用统计分析平台，以便后面选择最终使用哪个。
先吐槽下友盟吧：友盟在我们的使用过程中，发现安装量，用户活跃度这些基础统计不准确，我们只是拿友盟的数据和Apple官网统计数据、我厂后台数据简单对比就得出了这个结论。另外，友盟必须把代码里的事件id输入到友盟后台才能生效，而且漏斗事件的修改功能根本就没有用，不能动态调整顺序，除非你新建一个。
漏斗事件是App应用分析里面特别重要的一个功能，但我们发现Talkingdata在漏斗事件的统计里面数据完全不准确。举例说明：
页面跳转路线1 A->B->C，线路2 D->E->C。2条跳转线路的最终页面都是C，漏斗事件的作用在于你可以定义2个漏斗事件来对比分析2条线路的用户留存。但是！！！，Talkingdata的统计策略是，只要C有事件，就统计到里面，那么这2条线路的数据看起来特别的别扭，特别的奇怪！因为线路2到达C的事件会被统计到线路1里面去。要想得到2条线路分别的正确的漏斗事件数据，你需要分别定义事件id，A1->B1->C1, D1->E1->C2，也就是说你的最终页C有多少条线路可以到达，那么你就必须定义多少个不同的Cx事件来区分不同的线路，不然结果就是不准确的。（我们电话了Talkingdata的人，他们确认了这个！）。友盟的漏斗事件相对靠谱点
我的天，Talkingdata这种统计法明显是要搞死使用他们平台的人啊！我不知道以前有没有人向Talkingdata反应过这个情况，据Talkingdata的人说，他们后台对漏斗事件的算法就是这样实现的，难道你们都不去研究下竞争对手的吗？（友盟<-->Talkingdata）
Talkingdata比较好的地方是，代码里面定义的事件会自动上传到后台，这样就可以直接在后台使用了，不像友盟还需要后台输入一次。Talkingdata的漏斗定义后可以灵活调整。这是比较方便的地方。
总结：友盟和Talkingdata都存在统计不准的情况，建议有需求的同学灵活考虑同时集成，在不同的平台看不同的数据。可惜国内的App不好用Google的数据统计工具，唉！
