應(yīng)用統(tǒng)計(jì)分析是App里很重要的一部分。我廠以前用的友盟邀层，最近又集成了Talkingdata返敬，來彌補(bǔ)友盟的一些不足，順便比較下這2個(gè)應(yīng)用統(tǒng)計(jì)分析平臺(tái)寥院，以便后面選擇最終使用哪個(gè)劲赠。
先吐槽下友盟吧：友盟在我們的使用過程中，發(fā)現(xiàn)安裝量秸谢，用戶活躍度這些基礎(chǔ)統(tǒng)計(jì)不準(zhǔn)確凛澎，我們只是拿友盟的數(shù)據(jù)和Apple官網(wǎng)統(tǒng)計(jì)數(shù)據(jù)、我廠后臺(tái)數(shù)據(jù)簡單對比就得出了這個(gè)結(jié)論钮追。另外预厌，友盟必須把代碼里的事件id輸入到友盟后臺(tái)才能生效阿迈，而且漏斗事件的修改功能根本就沒有用元媚，不能動(dòng)態(tài)調(diào)整順序，除非你新建一個(gè)苗沧。
漏斗事件是App應(yīng)用分析里面特別重要的一個(gè)功能刊棕，但我們發(fā)現(xiàn)Talkingdata在漏斗事件的統(tǒng)計(jì)里面數(shù)據(jù)完全不準(zhǔn)確。舉例說明：
頁面跳轉(zhuǎn)路線1 A->B->C待逞，線路2 D->E->C甥角。2條跳轉(zhuǎn)線路的最終頁面都是C，漏斗事件的作用在于你可以定義2個(gè)漏斗事件來對比分析2條線路的用戶留存识樱。但是｀臀蕖！怜庸！当犯，Talkingdata的統(tǒng)計(jì)策略是，只要C有事件割疾，就統(tǒng)計(jì)到里面嚎卫，那么這2條線路的數(shù)據(jù)看起來特別的別扭，特別的奇怪宏榕！因?yàn)榫€路2到達(dá)C的事件會(huì)被統(tǒng)計(jì)到線路1里面去拓诸。要想得到2條線路分別的正確的漏斗事件數(shù)據(jù)侵佃，你需要分別定義事件id，A1->B1->C1, D1->E1->C2奠支，也就是說你的最終頁C有多少條線路可以到達(dá)馋辈，那么你就必須定義多少個(gè)不同的Cx事件來區(qū)分不同的線路，不然結(jié)果就是不準(zhǔn)確的倍谜。（我們電話了Talkingdata的人首有，他們確認(rèn)了這個(gè)！）枢劝。友盟的漏斗事件相對靠譜點(diǎn)
我的天井联，Talkingdata這種統(tǒng)計(jì)法明顯是要搞死使用他們平臺(tái)的人啊您旁！我不知道以前有沒有人向Talkingdata反應(yīng)過這個(gè)情況烙常，據(jù)Talkingdata的人說，他們后臺(tái)對漏斗事件的算法就是這樣實(shí)現(xiàn)的鹤盒，難道你們都不去研究下競爭對手的嗎蚕脏？（友盟<-->Talkingdata）
Talkingdata比較好的地方是，代碼里面定義的事件會(huì)自動(dòng)上傳到后臺(tái)侦锯，這樣就可以直接在后臺(tái)使用了驼鞭，不像友盟還需要后臺(tái)輸入一次。Talkingdata的漏斗定義后可以靈活調(diào)整尺碰。這是比較方便的地方挣棕。
總結(jié)：友盟和Talkingdata都存在統(tǒng)計(jì)不準(zhǔn)的情況，建議有需求的同學(xué)靈活考慮同時(shí)集成亲桥，在不同的平臺(tái)看不同的數(shù)據(jù)洛心。可惜國內(nèi)的App不好用Google的數(shù)據(jù)統(tǒng)計(jì)工具题篷，唉词身！
