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

出门在外，被问得最多的问题就是“应用开发者为啥要用 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 读者交流群）。