写点什么

移动统计分析—— 那些年一起踩过的坑

2015 年 7 月 28 日

出门在外,被问得最多的问题就是“应用开发者为啥要用 TalkingData 的统计分析,自己做不行吗,看起来很简单啊”。每当这时,我就觉得万般辛酸,内牛满面,在做统计分析平台的过程中遇到的无数坑,骑着羊驼在脑海呼啸而过。

TalkingData 这 4 年来在移动统计分析上投入巨大,就是为了去填平诸多的坑。但是很多人是不到黄河心不死,所以我鼓励大家都来做做统计分析平台,一起来踩坑,“望山跑死马”,只有跑断几条腿,大家才会有感觉。

为了避免大家吃亏以后怪我言之不预,所以今天重点聊聊移动统计分析的坑。

第一个大坑:设备唯一性识别

智能设备的唯一性识别是所有移动统计分析的基础,唯一性识别不准,就谈不上数据分析。客户在接入 TalkingData 的时候一般会先对数据,由于设备唯一性识别不准确,有时候数据差异能达到 20% 以上。

在 PC 时代,PC 的唯一性可以通过一些硬件 id(比如硬盘、CPU、网卡 Mac 等)来标识,技术相对成熟,识别也比较稳定。但是在智能手机上,情况就很不一样了:

一是对用户隐私和数据安全有更多管控,有些数据无法获取。尤其是苹果系统,对此更加严格,其识别方法就经历过 UUID、UDID、WIFI MAC、Open UDID、IDFA、IDFV 等不同阶段的安全策略调整,不同机型不同系统版本需要使用不同的方法,ID 持久化的手段也不同。

二是国内安卓手机生态系统非常碎片化,超过 2 万款的不同安卓系统,在底层接口上或多或少具有一定的差异性,从来没有一个统一规范或绝对保险的信息获取手段,都需要有针对性的进行适配。也许你不知道,记录一个原生 ID 需要综合使用至少 4 种方式,持久化一个 Html5 的 ID 更需要超过 6 种方式。这里需要的不仅是经验的积累,还需要耐心。

TalkingData 经过和 2 万多款系统的艰苦斗争,逐步建立起相对完善的智能设备 TDID(TalkingData Device ID)识别体系,在设备识别准确率上有极为优异的表现。当然,随着智能设备的品类和款型不断丰富,这个斗争还会一直持续下去,我们也会坚持投入资源,以维持高质量的设备识别。

第二个大坑:数据标准化

数据标准化解决的是数据质量的问题,数据标准化程度越高,数据分析结果就越准确,客户对于数据的理解也就越深入。但是在中国,数据标准化是一个比较高的门槛,需要投入大量资源做很多辛苦的“接地气”的工作,并非所有公司(包括 BAT)都有能力和意愿持续投入资源在这样苦逼的事情上。

比如手机机型是数据分析的一个比较重要的维度,机型数据能够反映用户的一些属性特征,比如年龄、性别、消费能力等等。但是对于智能手机(尤其是安卓手机)来说,识别机型绝不是一件容易的事情,即使是有一些巨头,机型数据分析里面最大比例的也是“其他设备”。先不说刷机的存在让手机经常面目全非,即使是同一款手机不同出厂批次,也会出现较大的系统差异。仅仅从系统配置属性里面拿到制造商和机型两个字段远远不够,再加上更多的附加系统配置属性也稍稍不足,有的系统要根据手机内存的大小来进一步辅助机型判断,有的系统还需要一定的技术手段获取核心芯片类型。TalkingData 目前有一个团队专门在做机型的识别,已经建立了一个很大的机型匹配模型和数据库,在机型识别准确度上名列前茅。

再比如大家以为很简单的“运营商信息”,大部分公司可能直接截取系统配置信息里面的运营商字段即可,好像也没啥要做的。但是我们收集的信息表明,即使是“中国移动”这家运营商,就有超过 200 条的字符串对应,包括“中国移动”、“中国移动 Mobile”、“China Mobile”、“中国移动”、“China-Mobile”、“中国移动很 **”等等,千奇百怪,令人叹为观止。TalkingData 为了数据的准确,针对类似的数据指标建立起了一套半自动化的处理流程,采用流式处理技术,在海量数据流转过程中,发现新的词条,就会提示相关的数据标准化人员。因此可以相对实时、准确的完成数据清洗工作。

还有,关于归属区域的数据,常规手段是通过 IP 地址来识别,于是大家都有了自己的 IP 地址和区域的映射表。但是中国的情况大家都知道,网络环境是非常复杂的,各省运营商从成本考虑,经常修改路由策略,导致 IP 地址非常混乱,基于归属区域的数据分析结果漏洞百出,经不起推敲。比如你以为你的用户大部分在上海,但是归属地一查,居然甘肃占大头!

为了解决这个问题,TalkingData 和多家数据服务商合作,建立了一套基于 IP 地址、位置、WIFI 背景和用户行为分析的归属地分析系统,大大提升了归属地判断的准确度。伙伴们再也不用担心找不准自己的用户了。

数据取不到是一方面,能取到但是有错误是另一方面,比如一些老款手机有 bug,经常断电重启了以后系统时间就变成 1950 年,这需要在数据处理的时候进行清洗。诸如此类,举不胜举。

所以在 TalkingData 看来,“大数据”更多代表的是“大量的脏数据”,只有经过清洗和标准化的数据,才有可能产生价值。数据质量对他人算是可有可无,但对 TalkingData 却是生命线,即使再苦逼我们必须去做,也必须做好。我们在此投入很多资源,取得一些成绩,也在逐步开放能力给广大合作伙伴,让大家真正享受到大数据的红利。

第三个大坑:分析算法

数据统计分析中会用到各种数据挖掘的算法,比如预测收入和流失,或者对自己的用户做人群画像(比如打兴趣标签)。

通常,大家觉得架几台服务器,部署一个 Spark,跑一个 MLLib 任务也就差不多可以做挖掘了。对于刚起步的产品线的确如此,这时候数据量还比较小,怎么跑都能很快跑完,结果秒出,皆大欢喜。但是随着产品的发展,用户数不断增大,数据样本也随着增长。同时随着大家对数据需求的提升,需要刻画更加丰富的用户特性,于是样本特征维度也随之增长。这两个因素,导致普通的机器学习算法越来越没法满足需求。

从算法复杂度来说,传统算法的复杂度与训练样本数(如 SVM)或特征数量(如决策树)的关系是超线性关系。有一些模型学习中用到的优化方法,如牛顿法,需要计算训练特征维度规模的海塞矩阵的逆矩阵及其乘法,其计算复杂度为 O(n^3)。从 I/O 消耗上说,机器学习算法大部分都包含迭代,需要反复多次使用数据,而在处理大规模数据时,受硬件条件限制,训练数据集可能无法一次性全部加载到内存中,只能分批次从文件系统中读取,于是又带来巨大的存储 I/O 开销。

急剧膨胀的计算量和 I/O 消耗,使得训练时间变得越来越长,原来秒出的结果慢慢变成分钟出,再变成小时出,甚至最后隔天才能出,越来越无法接受。能增加硬件解决?实际上,硬件数量的扩充带来的计算效率的提升,大大落后于数据量增长带来的计算量和 I/O 消耗。扩充硬件并不是最有效的方案,依然需要从算法优化上去解决——这里面既需要对算法本身有深刻了解,也需要具有数据领域相关的知识。对于任何公司来说,必须要有一个有经验和积累的算法团队才能搞得定,资源和时间都必须投入。

TalkingData 的数据挖掘算法团队在移动大数据方面积累深厚,基于对算法和数据的理解,自主研发出高性能大规模机器学习算法框架,解决了计算复杂度和资源消耗的问题,即使在 2 亿样本和 300 万维度的状况下,也能应对自如。

第四个大坑:成本

不差钱不差人也不差时间的土豪,请自动跳过本章节,避免浪费时间。

小公司数据量小,统计分析平台可以简陋些,但是再简陋也至少需要统计分析功能。先不说各种算法各种数据规范化,至少要有一个后台开发吧?写写分析逻辑,搞搞数据库,这是必须的。另外 1 个数据运营人员少不了,要不然谁来定义分析指标的概念和计算方法,谁来跟踪数据的变化,谁来写报告?最后这个系统需要界面吧?再简陋,1 个前端做界面和维护也是需要的,因为大家总是对数据充满好奇心,需要做各种解读,因此不断会有新界面的需求。这样,至少 3 个人就牵扯进去了。对于目前起步大概 10 个人左右的小创业团队来说,3 个人放在这上面,谁受得了?

对于大公司来说,投入几个人做个统计分析平台好像也没什么。但是别忘记了,大公司的数据量要高出好几个量级,带来了计算量和复杂度的超线性增长。这时候不仅需要算法团队来研究算法的优化,也需要运维团队来规划更大规模的服务器集群。大公司的产品,不支持全平台简直都不好意思说,安卓、iOS、WindowsMobile 这样的主流平台先不说,光是游戏就至少还有 cocos2D、unity3D、ANE、Html5,于是有需要有专人去负责不同平台客户端的数据统一和规范的工作。这还不算完,公司大了,部门多了,要看数据的人也多了,有的人看新增、活跃、留存,有的人看转化漏斗,有的人看渠道 ROI……这么多的指标,总要有专门人归纳整理提炼维护,兼职的大猫小猫两三只搞得过来吗?这还不说一些垂直行业需要更加深入的指标分析和预测,比如移动游戏就需要分析过关数据、游戏时长、升级数据、付费数据等等,还有复杂的付费预测、流失预测……这就牵涉到产品团队和运营团队的支持。零零总总,做好一些统计分析平台,需要投入的就至少包含一个数据算法团队、一个 IT 运维团队、一个客户端团队、一个数据运营团队、一个产品团队。一个团队 2-3 个人,咱就准备 15 个人吧。对于有高标准要求的公司来说,还需要一些人做数据的标准化,一些人专门去谈第三方公司数据的引入(以提升自有数据的丰富性)……人数还会增加。还没完,除了人力资源成本和管理成本,还要算上带宽、服务器、IDC 租用等等,也要算上为了数据安全所需要的多机备份、多数据中心容灾等等……这绝不是一笔小投入了!

第五个大坑:数据的高效利用

最后的关键还在于,无论公司大小,即使花了钱,也未必做得好。而且,做出来一回事,用得好是另外一回事。依样画葫芦很容易,但是该下的功夫无论如何也省不了。

以前 app 开发者只关注推广,重视下载量和安装量(即使现在有一些 app 依然如此),后来慢慢知道新增、日活、留存这些指标了。但这还远远不够,如何通过这些数据来指导产品的改进和运营的优化?

并不是搭个框架放点数据做些图表就叫精细化运营,这些都需要有一套成熟的方法论的指导。从用户的获取,到用户进入应用以后产生活跃,到用户对应用功能或服务产生黏性,到应用如何通过服务或功能获取收入,并通过为用户提供超过预期的服务来产生分享,从而进入第二次传播,影响新用户的获取。这个循环中,每个环节都可能遇到大量问题。通过数据的指导,有助于我们发现问题并找出有针对性的解决方案。

TalkingData 服务于 6 万开发者和 8 万的移动应用,覆盖超过 15 亿智能设备,每天都有大量的客户交互和咨询,因此你遇到的问题,我们都不陌生。TalkingData 根据自己的经验以及业界的最佳运营实践,总结出 AARRR(Acquisition、Activation、Retention、Revenue、Refer)运营模型,融合到统计分析产品线中,来指导产品和运营。你能想到的功能,我们已经有了,你想不到的功能,我们也有。

很小的时候就学过,“知易行难”。空口说大话容易,踏踏实实做出一件事情来很难。TalkingData 经历了这么多坑,才把统计分析做出来,我们绝不希望小伙伴们还要经历一遍我们所经历的困难。TalkingData 也在创业中,深知创业艰难,无暇他顾。我们希望能够帮助大家尽可能的分担,让大家可以把全部热血和精力都投入到自己的焦点上,多增加一点成功的机会。

当然,依然想做统计分析的朋友,欢迎交流切磋,共同进步。

【后记】

最后要提到的是,有不少朋友认为 TalkingData 是数据工具公司。其实从我们的产品线就可以看出来,我们是以数据而不是工具为核心。我们致力于数据的研究,通过数据来改变企业做决定的方式,而工具只是数据的呈现。


感谢 Raymond Zhao 对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015 年 7 月 28 日 00:263997

评论

发布
暂无评论
发现更多内容

架构师训练营 week7 课后作业

花果山

极客大学架构师训练营

架构师训练营第十一周课后作业

Gosling

极客大学架构师训练营

周练习 11

何毅曦

苏州派发数字人民币红包:挺进线上消费场景,“双离线”功能首次曝光

CECBC区块链专委会

数字红包

架构师训练营 Week 8 总结

Wancho

架构师训练营第十一周学习总结

Gosling

极客大学架构师训练营

第十一周总结

Geek_ce484f

极客大学架构师训练营

水滴互助上链:利用区块链技术打造透明安全互助业务

CECBC区块链专委会

区块链

第七周作业

晴空万里

极客大学架构师训练营

造车失败后投身机器人和AI,我笑戴森太疯癫,戴森笑我看不穿

脑极体

ShardingSphere RAW JDBC 分布式事务 Atomikos XA 代码示例

Java MySQL 数据库 分布式事务 ShardingSphere

训练营第十一周作业 1

仲夏

区块链系统面临的风险和防范

CECBC区块链专委会

区块链 系统

第十一周作业

极客大学架构师训练营

架构师训练营第十一周作业

Shunyi

极客大学架构师训练营

训练营第十一周作业2

仲夏

第十一周作业

Geek_ce484f

极客大学架构师训练营

11周作业

橘子皮嚼着不脆

沉默的性能杀手 - false sharing

哈希说

golang

架构师训练营第二期 Week 7 作业

bigxiang

极客大学架构师训练营

第十一周总结

alpha

极客大学架构师训练营

架构师训练营 Week 13 总结

Wancho

架构师训练营 Week 14 总结

Wancho

架构师训练营第七周学习笔记

李日盛

笔记

架构师训练营第二期 Week 7 总结

bigxiang

极客大学架构师训练营

第十一周作业

alpha

极客大学架构师训练营

作业-第7周 性能优化一

arcyao

架构师训练营 第七周作业

文江

week11作业

追风

架构师一期

第七周-作业

ray-arch

回溯解决电话拨号字母组合,swift:Subscripts下标的花式玩法,swift5 Auto Layout入门,John 易筋 ARTS 打卡 Week 29

John(易筋)

ARTS 打卡计划 回溯算法 autolayout swift5 xcode 快捷键

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

移动统计分析—— 那些年一起踩过的坑-InfoQ