书籍：《首席增长官：如何用数据驱动增长》
作者: 张梦溪
本文基于该书的第三章 增长框架
一种非常传统、非常普遍的方式就是通过写代码去定义这个事件。在网站需要监测用户行为数据的地方加载一段代码，比如说注册按钮、下单按钮等。加载了监测代码，我们才能知道用户是否点击了注册按钮、用户下了什么订单。
所有这些通过写代码来详细描述事件和属性的方式，我们都统称为“埋点”。这是一种非常耗费人力的工程，并且过程非常烦琐重复，但是大部分互联网公司仍然有人数众多的埋点团队。
1.埋点采集数据的七个步骤
（1）确定场景或目标
确定一个场景或者一个目标。
（2）数据采集规划
思考哪些数据我们需要了解，帮助我们实现这个目标。
（3）埋点采集数据
我们需要确定谁来负责收集数据？这个一般是工程师，有些企业有专门的数据工程师，负责埋点采集数据。
（4）数据评估和数据分析
对收集上来的数据质量进行评估和分析。
（5）给出优化方案
发现问题后，给出解决方案。比如，是否在设计上改进，或者工程上是否有bug。
（6）实施优化方案
确定方案的实施责任人。
（7）评估解决方案的效果
下一轮数据采集和分析，回到第一步继续迭代。
知易行难。这整个流程里，第二步到第四步是关键。
2.埋点采集数据的四个缺点
Capture模式采集到的数据非常精准，对于非探索式分析来说是一个非常有效的方法。同时，对参与整个流程的人也提出了非常高的要求。
（1）依赖经验导向
Capture模式非常依赖人的经验和直觉，采集哪些指标和维度的数据，都需要提前想好。不是说经验和直觉不好，而是有时我们自己也不知道到底什么是好的。经验反而会成为一个先入为主的弊端，我们需要用数据来测试、来证明。
（2）沟通成本高
一个有效的分析结果，依赖于数据的完整性和完备性。在跟不少企业沟通后，我发现很多的问题都跟数据格式有关，比如“连日志格式都统一不了，更别提后续分析了”。这不是具体人的问题，更多是协作沟通的问题。参与人多，如产品经理、分析师、工程师、运营等，每个人的专业领域各不相同，出现误解太正常了。
（3）大量时间数据清洗
另外，由于需求的多变性、埋点分成多次加入，缺乏统筹设计和统一管理，代码自然是无比混乱的。所以我们的数据工程师还有个很繁重的工作是数据清洗，手动跑ETL出报表。根据统计，绝大多数分析工作，70%～80%的时间是在做数据清洗和手动ETL，只有20%左右在做真正有业务价值的事情。
（4）数据漏采错采
如果说上面的缺点很让你头疼，那么接下里的问题就更让人抓狂。很多时候埋点监测代码上线后，发现数据采集错了或者漏了；修正后，又得重新跑一遍流程，这样一个星期、两个星期又过去了。这也是数据分析工作为什么如此耗时，一般以月计的原因，非常低效。
