最后，我们再聊一聊数据采集中遇到的非技术性问题。一般来说，公司到了 A 轮以后，都会有专门的数据团队或者兼职数据人员，对公司的一些业务指标负责。即使为了拿到这些基本的业务指标，一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了，天下武功唯快不破。于是所有事情都要给产品迭代升级让路，快的都没有时间做数据采集了。殊不知没有数据指标的支撑，又怎么衡量这个功能升级是不是合理的呢？互联网产品并不是功能越多就越好，产品是否经得起用户考验，还是要基于数据说话的，然后学习新知识，用于下一轮的迭代。
回复 ( 10 )
我是神策数据的创始人桑文锋，属于利益相关者，最近正好写了篇文章，聊一聊“埋点”到底要不要。原文见：在数据采集上的痛苦、幻想与失望 – 瓦利哥的机器岁月 – 知乎专栏
随着移动互联网时代的兴起和数据量的大规模爆发，越来越多的互联网企业开始重视数据的质量。在我创业的这一年里，接触了 200 多家创业型公司，发现如今的企业对数据的需求已经不仅仅局限于简单的 PV、UV，而是更加重视用户使用行为数据的相关分析。
做数据的同学都知道，在数据分析的道路上，数据采集是重中之重。数据采集的质量直接决定了你的分析是否准确。而随着企业对数据的要求越来越高，埋点技术也被推到了“风口浪尖”。所谓，埋的好是高手，埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题，今天我们就来分析一下埋点是否需要。
首先我把数据采集的问题归结为三类：
上面这三类问题让数据团队相当痛苦，进而幻想弃用数据采集，而尝试新方案后，进而迎来的是更大的失望。这里我对这三类问题的现状及应对之策做一下分析。
► 不知道怎么采
一般创业公司的数据采集，分为三种方式：
第一种直接使用友盟、百度统计这样的第三方统计工具，通过嵌入 App SDK 或 JS SDK，来直接查看统计数据。这种方式的好处是简单、免费，因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求，基本能够满足。
但是，对于现在一些涉及订单交易类型的产品，仅仅宏观的简单统计数据已经不能满足用户的需求了，他们更加关注一些深度的关键指标分析，例如：用户渠道转化、新增、留存、多维度交叉分析等。这个时候才发现第三方统计工具很难满足对数据的需求，而出现这样的问题并不是因为工具的分析能力薄弱，而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一些基本的用户行为数据，比如设备的基本信息，用户执行的基本操作等。但是服务端和数据库中的数据并没有采集，一些提交操作，比如提交订单对应的成本价格、折扣情况等信息也没有采集，这就导致后续的分析成了“巧妇难为无米之炊”。
通过客户端 SDK 采集数据还有一个问题就是经常觉得统计不准，和自己的业务数据库数据对不上，出现丢数据的情况。这是前端数据采集的先天缺陷，因为网络异常，或者统计口径不一致，都会导致数据对不上。
第二种是直接使用业务数据库做统计分析。一般的互联网产品，后端都有自己的业务数据库，里面存储了订单、用户注册信息等数据，基于这些数据，一些常用的统计分析都能够搞定。这种方式天然的就能分析业务数据，并且是实时、准确的。
但不足之处有两点：一是业务数据库在设计之初就是为了满足正常的业务运转，给机器读写访问的。为了提升性能，会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表，这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了，隔天工程师又告诉你因为性能问题拆表了，你就崩溃了。另一个不足之处是业务数据表的设计是针对高并发低延迟的小操作，而数据分析常常是针对大数据进行批量操作的，这样就导致性能很差。
第三种是通过 Web 日志进行统计分析。这种方式相较于第二种，完成了数据的解耦，使业务数据和统计分析数据相互分离。然而，这种方式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞，这样的日志对于业务层面的分析，常常“缺斤少两”。并且从打印日志到处理日志再到输出结果，整个过程很容易出错，我在百度就花了几年的时间解决这一问题。
所以，以上三种方式虽然都多多少少解决了一部分数据采集的问题，但又都解决的不彻底。
► 埋点混乱
聊完采集方法，再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司，他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后，工程师就会按照要求增加埋点，然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常，可等产品上线之后，才发现埋的不对，再进行升级发版操作，整个过程效率极低。我们发现，一个公司发展到了一定程度，没有专人去负责埋点管理工作，数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后，才发现数据采集的工作没有做，也就是漏埋了。
于是数据团队又开始幻想，既然埋点这么容易出问题，有没有可能不埋点？这就像寻找可以祈求风调雨顺的神灵。
在 2010 年，百度 MP3 团队曾经做了一个叫 ClickMonkey 的产品，只要页面上嵌入 SDK，就可以采集页面上所有的点击行为，然后就可以绘制出用户点击的热力图，这种方式对于一些探索式的调研还是比较有用的。到了2013 年，国外有家数据分析公司 Heap Analytics，把这种方式更近一步，将 App 的操作尽量多的采集下来，然后通过界面配置的方式对关键行为进行定义，这样便完成了所谓的“无埋点”数据采集。使用这种方案，必须在产品中嵌入 SDK，等于做了一个统一的埋点，所以“无埋点”的叫法实际上是“全埋点”的代名词。
另外，这种方式同样也只能采集前端数据，后端服务器和数据库中的数据，依旧是无可奈何的。并且，即便进行前端数据采集，也无法深入到更细粒度。比如提交订单操作，订单运费、成本价格之类的维度信息，都丢失掉了，只剩下“提交”这一个行为类型。
对于非技术人员，容易被这种方式的名称和直接优势所吸引，但很快又会发现许多深度数据分析需求无法直接满足，进而有种被忽悠的感觉，会感到失望。其实不止是非技术人员，即使是技术人员，也都会让我解释一下“可视化埋点”的原理，说明“无埋点”真是个有迷惑性又不甚清晰的概念，难以细究。
这里说一下关键点：一是事先在产品上埋一个 SDK，二是通过可视化的方式，生成配置信息，也就是事件名称之类的定义，三是将采集的数据按照配置重命名，进而就能做分析了。
► 数据团队和业务工程团队的配合问题
最后，我们再聊一聊数据采集中遇到的非技术性问题。一般来说，公司到了 A 轮以后，都会有专门的数据团队或者兼职数据人员，对公司的一些业务指标负责。即使为了拿到这些基本的业务指标，一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了，天下武功唯快不破。于是所有事情都要给产品迭代升级让路，快的都没有时间做数据采集了。殊不知没有数据指标的支撑，又怎么衡量这个功能升级是不是合理的呢？互联网产品并不是功能越多就越好，产品是否经得起用户考验，还是要基于数据说话的，然后学习新知识，用于下一轮的迭代。
数据团队和业务工程团队是平级的团队，而数据团队看起来总是给业务工程团队增加麻烦事儿，似乎也不能直接提升工程团队的 KPI，所以就导致需求不被重视，总是被更高优先级的事情挤掉，数据的事情难有进展。
解决之道
前面给大家抛出了数据采集中常见的三类问题，下面我们来看一下应对之道。
对于不知道数据怎么采的问题，首先从意识上要重视数据采集工作。数据的事情归结起来就两点：数据采集和数据分析。可不能只看到数据分析而忽略了数据采集。事实上我个人在百度做数据的几年里，最大的心得就是数据这个事情要做好，最重要的是数据源，数据源收集得好，就成功了一大半。数据采集的基本原则是全和细。全就是把多种数据源都进行采集，而不只是客户端的用户数据。细就是强调多维度，把事件发生的一系列维度信息，比如订单运费、成本价格等，尽量多的记录下来，方便后续交叉分析。
其次，要有一个数据架构师，对数据采集工作负责，每次数据采集点的增加或变更，都要经过系统化的审核管理，不能顺便搞搞。最后，我这里要推荐 Event 数据模型（有兴趣的可阅读：数据模型 | Sensors Analytics 使用手册），针对用户行为数据，简化成一张宽表，将用户的操作归结为一系列的事件。
对于埋点混乱的问题，前面提到的数据架构师的角色，要对这块的管理负责。如果前面完成对 Event 的梳理，这里的埋点就会清晰很多。另外还要推荐尽量从后端进行埋点，这样便无需多客户端埋点了。当然，如果有行为只在客户端发生，还是要在客户端进行埋点的。对于业务复杂的情况，只有负责人还不够。目前我们神策分析针对这个问题，推出了埋点管理功能，对于每个采集点的数据收集情况，都能够做到全盘监控，并且可以针对一些无效采集点进行禁用。总之是希望把这个问题尽量好的解决掉。
对于数据团队和工程团队的配合问题，我这里是想说给创业公司的创始人听的。两个平行部门间的推动，是很难的。数据的事情一定要自上而下的推动，也就是创始人一定要重视数据，把数据需求的优先级提升，这样在项目排期时，能够把数据的需求同时做了。我们知道两军对战，情报收集工作的重要性。做产品也是一样，数据收集工作的重要性不言而喻。
最后，期望越来越多的创始人，从拍脑袋决策逐步向数据驱动决策做出转变。
然而growing io只能做到对某个按钮进行设置，如果你的APP页面较多，按钮较多，你会因为想看这些字段的报表而设置疯掉。数据统计一直都是以从“宏观→微观，从局部→全面”反复推演才能得出较为精准的分析结果。如果要像Growing io一样把所有的细节点完全拆开，那么为了某个键位转化后对应的金字塔式接口，我相信你会被大量的数据路径弄疯。
形式上简单说就是抄的heapanalytics.
功能上heap比growingio强一万倍。
原理上，用户点击页面时，把css选择器保存到server。统计用户点了哪些元素。用户可以把这个css选择器定义为无埋点元素来查看点击次数。
本质上，无埋点只是常规埋点的一个特别小的子集，因为无埋点只能选择页面上点击到的一个元素，或者加个选项比如这个元素的所有同类的元素。这就好比你每天只能吃蛋炒饭一样，但是实际上吃饭可以千变万化。
好处是，对于不会做饭的人来说，可以每天吃饭蛋炒饭。不需要厨子了。
但是你如果想统计当前页面的滚动条高度，页面上两个输入框里的值的和。等很简单的问题。无埋点完全没法做到。
鉴于后来gi张溪梦ceo的回答，我感觉到我之前说直接说抄的heap有点过了，只能说类似。也不能完全说是靠css选择器，只能说类似。当然heap的功能确实比gi强，这个毋庸置疑。而且无埋点只是埋点的一个子集，也是毫无疑问的。无埋点只是对于非技术人员的噱头，功能实在太受限制。如果到处宣称无埋点比埋点好，我觉得实在不能同意。
这就好像你说我花五毛钱买个烧饼，和花了50买个披萨。你说无埋点就想5毛钱的烧饼一样，我没有什么投入，但是我也能吃饱，满足需求。买个披萨，我还需要开发人员投入，但是你能得到你想要的所有数据，而且数据比无埋点精确可靠。
这也看用户的选择了，如果只是简单的填报肚子的需求，那用无埋点就ok了，简单省事，比如个人博客，个人小网站等不需要数据太精确的需求。如果需要精确的采集你要的数据，这必须要靠开发人员来埋点选择你想要的数据，比如电商网站，o2o站点等企业级需求。
感谢楼上的朋友对GrowingIO的关注。关于Heap，他们是湾区很好的创业公司，也是一个工程导向的团队。GrowingIO现在的产品和Heap产品在底层技术设计框架，分析理论以及核心功能上有很大的差异。您上面阐述的是Heap关注的CSS原理以及技术实现功能与GrowingIO专注的点是非常不同的，GrowingIO在技术上考虑的数据信息流框架不是以CSS选择器为核心进行的。过去10来年的网站和App分析的历程里，特别在LinkdeIn的分析过程中我们养成了更关注内容，而非只是容器的分析习惯。而且在后台的产品分析展示层，两种产品的设计思想有很大的分别。用户可以在界面和使用的方法上可以看出来基本完全不是一个思路。不过所有的创业公司都在各种分析自动化的都路上努力，我们希望中国的互联网企业也能用这种思想和产品提高效率。再次感谢您的关注！
首先直接回答题主的问题：
大多对于可交互式的应用程序，例如Android应用，iOS应用，网站，Windows Phone应用，Windows的窗体程序、Java的窗体程序等等，其实在界面渲染时都有几点共性：
1. 图形背后都有图形树，我们所看到的输入框、文本框、按钮等等其实都是view，而view的摆放其实也都是有对应的视图方式，例如线性布局、网格布局、表格布局、相对、绝对等等，然后view加布局就组成了我们要看到的界面，比如最简单的就是网站的DOM结构了，有层级关系，对于Android而言就是View视图的层级关系了，调用系统级API基本上都能获取这个树结果。
2. 窗体都有生命周期，比如Android的Activity的生命周期
3. 对于我们可视的这些界面元素，当他们显示出来、被点击了、被选中了、被滑动等等操作的时候，系统也都会有相应的接口给开发者通知他们去处理，所以也就是对于View而言可以绑定或者委托或者是监听他们的一些触发事件，比如刚刚提到的加载、点击、选中等操作。
讲到这里，应该很清楚了，应用程序在呈现程序界面的时候，其实有一套生命周期的准则在里面，控制了从界面元素创造到响应用户操作到销毁，同时也有一个图形树的准则在里面，控制了这些界面元素的显示层级和顺序，最后在用户交互（包括展现）各个界面元素的时候，会给开发者提供一系列的接口，让开发者去处理这些行为。
所以原理清楚了，后续无埋点其实也就能想到怎么做了，现在市面上主流有两种，一种是预先跟踪所有的渲染信息，一种是滞后跟踪的渲染信息。两种做法不太一样，后者要简单一些，前者要重一些，但是也有一些办法优化（不交互的元素肯定多于交互元素），各家也就都有自己的方法在里面。
多说几句，关于抄袭论，GrowingIO的CEO Simon已经回答了。诸葛io属于友商，也想站出来说两句，我们不能且以都为无码就论抄袭，无码也好，私有部署也好，多维分析也好，也只是方式或者功能，数据采集的方式或者数据分析的功能，但是分析工具承载很重要的其实是solution，也就是解决问题的场景，分析本身因为不同数据源，不同角色，不同部门，不同行业的需求不一样，所以场景也就很多样化。所以分析平台最大的差异也就不是功能，而是解决问题的场景。每一家都有自己的思考，经验以及方法论，从采集数据后的分析框架与擅用场景也就会有很多差异。
有人提及了无埋点和有埋点的优劣问题，选择无埋点还是有埋点也是建议大家从自身情况去选择，不同的分析工具和分析平台还需从自身分析场景来体验以及对比，才能找到最适合自己的。真正打动用户的不是趋之若鹜的功能或者噱头，还是在于能解决什么样的问题。
最后大家关注GrowingIO的同时，我也顺带提一句自家的诸葛io，国内（多次违反广告法）的精细化用户行为分析平台, 更多信息可以访问诸葛iO官网，或者诸葛io的知乎专栏和微信公众号，目前上线近一年，众多知名App和网站都已接入或购买我们的服务，专注于数据驱动产品分析和用户增长。
去网站注册了看看，但是没找到哪里下载SDK,,,,,,
找到了。。。敬请期待。。。
我的理解是 不是不必埋点，而是不需要代码埋点吧。
诸葛io, talking data都有类似产品。不过只能定义一个事件名称，简单地使用感觉还会不错的。但是如果要做类似GA AA那样的专业分析，能力上还是差了几个数量级的感觉。
这类tracking 和 百度统计的差距倍数大概等于百度统计和GA差距的倍数。但是，他们的确很方便。
第一代的采集：服务端访问日志
第二代的采集：页面埋点上报
第三代的采集：基于xpath（页面结构）的“无埋点”
第四代的采集：基于事件抽象的全量日志
第五代的采集：基于本地存储和客户端分析的全量日志
名词解析
如果把报表和可视化的问题加入考虑范围的话，我们会发现精确路径存在在一个缺点，就是同一个链接，可能因为头部加了一个公告或者dom结构上做了细微的调整，数组下标就会发生变化，让看多天数据变得困难。
概略路径在一定程度上能够屏蔽这种变化带来的影响，但依然只是程度上的区别，并且需要有较强的开发规范的把控。
全量日志由于不光考虑瞬发事件，还加入了持续事件，不做处理的情况下比前一代基于点击事件的上报要增加20-50倍的日志量，因此需要加入节流函数提升性能，和加入阈值机制把价值过低的事件放弃上报，以减少服务端对日志清洗的负担。
第四代和前三代最大的区别在于，无需因为分析方法和对象的改变而新增埋点，还有埋点上了之后还得等待几天的数据才能进行新的分析的等待过程。并且脱离了对业务代码、dom结构的侵入，以观察者的身份提交页面中发生的全量事件。拥有了全量信息的情况下数据分析方法的改变，立刻就可以进行。
第五代采集，目前处于设想和原型的阶段，已经跟身边的一些同事、朋友分享过，争议很大，姑且还是称做第五代采集。得益于localstorage、indexdb和v8引擎，浏览器端具备了简单的数据存储和分析能力。第四代采集中因为性能、流量考虑而被抛弃掉的日志依然可以保留下来，以5m本地存储来计算，保留一个用户近1星期甚至近1个月的操作日志都是可行的，服务端下发计算规则，浏览器在完成计算后上报计算的结果，而每次的计算结果可以作为一个单独的快照保留，在规则没有变化的情况下做增量的分析直到规则变化重新生成快照。
能做到和为什么要这样做是两个问题，说说第五代为什么要这样设计：
假设一个重交互应用场景：
对于第一次访问的用户，我们可以给出新手引导
对于已经访问过，但操作让不熟练的用户，我们可以提供有针对性的提示
对于熟练操作的用户，我们可以隐藏大多数的提示让操作界面变紧凑，甚至按照他的使用习惯调整页面结构。
简略说明一下熟练和不熟练的区别，任意两个事件可以组成一个任务，任务完成时间就以两个事件的事件差计算，通过任务的完成时间说明用户的熟练程度。
再假设一个性能优化应用场景：
通过全量日志我们可以知道，用户在访问a页面后最有可能的第一个操作是什么，做dns的预解析，静态资源的预测性加载。
伦理的问题，第五代和第四代的区别是全量日志是存本地的还是存服务端，第五代是把日志留在本地让用户自己可以进行管理，服务端得到的是计算后的结果。
最后提出一个假设：解决单个用户的“体验问题”，未必需要海量用户的参照。
———————-提问补充———————–
关于评论中对第五代设计上的一些疑问：
方案中不排斥全量日志上报到服务器端，只是提供了两种可能性：
1. 浏览器端对数据进行预处理
2. 前端可以通过本地日志提供更及时的“响应”
过去产品迭代的链条
数据采集–>报表–>发现问题(人)–>决策（人）–>开发变更（人）–>发布–>采集新一轮数据。
我认为这当中有三个环节特别低效：发现问题、决策、开发变更。因为都依赖人，每个人对同一个问题有不同的理解，解决问题的能力也有高有低，开发周期不可控。当上述的链条只能做到1周一次或者2周一次的情况下，一年下来对业务的改善往往是极其微弱的。
本地的全量日志，让浏览器端具备了简单的模式分析的能力，页面展现层可以在一个可控范围之内做出即时的调整，从而让用户的这次访问遇到的问题这次就得到响应，而不需要等待下一次的版本发布。
至于更远的未来中如何结合AI来做即时响应的事情，现在拿出来讨论太早，先做着就好了。
“不埋点”是噱头，看下 heap analytics 你就明白了。
利益相关：同行
有人说 跟 Heap Analytics 一样，这是不对的，你可以自己拿 Firebug 一类的工具抓包看看。 会抓取很多相关的上下文信息，也支持更复杂的查询和分析。然而所谓的“抓取所有的信息”是不可能，因为你根本没办法定义“所有的信息”。抓取的信息越多，也就意味着浪费的流量也越多，存储和索引的成本也越高。
做过信息检索的就应该知道，有一个最关键的概念是 precision/recall。 的策略是尽可能地提高 recall，而这个成本一部分是终端客户承受，另一部分是在 SaaS 服务的数据管线上增加压力。对于 PC 端的应用，这可能不是问题。但是对于移动端的应用，这就意味着更多的移动数据成本和耗电，此外还有相关的隐私风险。
个人觉得 的技术对于 Web 来说是比较适合的，但是对于移动数据采集而言，有一种用高射炮打蚊子的感觉。个人觉得 Mobile Analytics 的未来是 Lean Analytics，仅采集需要的数据，并且尽量在终端上进行预处理。
当然，真正的问题是开发者是否愿意为数据服务花钱，以及愿意花多少钱。商业模式永远都比技术细节更加重要。
数据采集与埋点 ，关于 无埋点/可视化埋点 的具体细节可以看看 SensorsAnalytics 的这篇 blog.
说的挺详细的.