“埋点”到底要不要？——源自数据采集的痛苦、幻想及失望.pdfVIP

“埋点”到底要不要 ？——源自数据采集的痛苦、幻想与失望 随着移动互联网时代的 起和数据量的大规模爆发 ，越来越多的互联网企业开始重视数据的 质量。在我创业的这一年里 ，接触了 200 多家创业型公司 ，发现如今的企业对数据的需求已 经不仅仅局限于简单的 PV 、UV ，而是更加重视用户使用行为数据的相关分析。 做数据的同学都知道 ，在数据分析的道路上 ，数据采集是重中之重。数据采集的质量直接决定了你 的分析是否准确。而随着企业对数据的要求越来越高 ，埋点技术也被推到了“风口浪尖”。所谓 ，埋 的好是高手 ，埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题 ，今天 我们就来分析一下埋点是否需要。 首先我把数据采集的问题归结为三类 ： 1. 不知道怎么采 ，包括采集什么数据以及用什么技术手段采集 ； 2. 埋点混乱 ，出现埋错、漏埋这样的问题 ； 3. 数据团队和业务工程团队配合困难 ，往往产品升级的优先级大于数据采集的优先级。 上面这三类问题让数据团队相当痛苦 ，进而幻想弃用数据采集 ，而尝试新方案后 ，进而迎来的是更 大的失望。这里我对这三类问题的现状及应对之策做一下分析。 不知道怎么采集数据 一般创业公司的数据采集 ，分为三种方式 ： 第一种直接使用友盟、百度统计这样的第三方统计工具 通过嵌入 A pp SDK 或 JS SDK ，来直接查看统计数据。这种方式的好处是简单、免费 ，因此使用 非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求 ，基本能够满足。 但是 ，对于现在一些涉及订单交易类型的产品 ，仅仅宏观的简单统计数据已经不能满足用户的需 求了 ，他们更加关注一些深度的关键指标分析 ，例如 ：用户渠道转化、新增、留存、多维度交叉分 析等。这个时候才发现第三方统计工具很难满足对数据的需求 ，而出现这样的问题并不是因为工具 的分析能力薄弱 ，而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一 些基本的用户行为数据 ，比如设备的基本信息 ，用户执行的基本操作等。但是服务端和数据库中的 数据并没有采集 ，一些提交操作 ，比如提交订单对应的成本价格、折扣情况等信息也没有采集 ，这 就导致后续的分析成了“巧妇难为无米之炊”。 通过客户端 SDK 采集数据还有一个问题就是经常觉得统计不准 ，和自己的业务数据库数据对不上 ， 出现丢数据的情况。这是前端数据采集的先天缺陷 ，因为网络异常 ，或者统计口径不一致 ，都会导 致数据对不上。 第二种是直接使用业务数据库做统计分析 一般的互联网产品 ，后端都有自己的业务数据库 ，里面存储了订单、用户注册信息等数据 ，基于这 些数据 ，一些常用的统计分析都能够搞定。这种方式天然的就能分析业务数据 ，并且是实时、准 确的。 但不足之处有两点 ：一是业务数据库在设计之初就是为了满足正常的业务运转 ，给机器读写访问的 。为了提升性能 ，会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表 ，这些 表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时 间搞懂了 ，隔天工程师又告诉你因为性能问题拆表了 ，你就崩溃了。另一个不足之处是业务数据表 的设计是针对高并发低延迟的小操作 ，而数据分析常常是针对大数据进行批量操作的 ，这样就导致 性能很差。 第三种是通过 Web 日志进行统计分析 这种方式相较于第二种 ，完成了数据的解耦 ，使业务数据和统计分析数据相互分离。然而 ，这种方 式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞 ，这样的日志对于业务层 面的分析 ，常常“缺斤少两”。并且从打印日志到处理日志再到输出结果 ，整个过程很容易出错 ，我 在百度就花了几年的时间解决这一问题。 所以 ，以上三种方式虽然都多多少少解决了一部分数据采集的问题 ，但又都解决的不彻底。 无法解决的数据采集问题 埋点混乱 聊完采集方法 ，再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司 ，他们 的数据采集有 4 00 多个点。每次数据产品经理提出数据采集的需求后 ，工程师就会按照要求增加 埋点 ，然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常 ，可等产品上线 之后 ，才发现埋的不对 ，再进行升级发版操作 ，整个过程效率极低。我们发现 ，一个公司发展到了 一定程度 ，没有专人去负责埋点管理工作 ，数据采集就完全没有准确性可据采集就完全没有准确性 可言。甚至有时产品上线之后 ，才发现数据采集的工作没有做 ，也就是漏埋了。