作者：闫鹏（公众号：yanpeng-info），转载请注明作者及出处。
无埋点，即前端全自动埋点；可视化埋点，即前端半自动埋点。为了表述更达意、简练，下面我会将“无埋点”称作“全埋点”，将二者统称为“自动埋点”。
注：二者都是前端埋点方案，初衷是替代前端人工埋点；而对于后端来说，“自动埋点”则无从谈起。
一、属性缺失
全埋点和可视化埋点，初衷都是希望免开发。
这就很难实现给特定事件携带上特定属性。
很多人会举类似这样的例子来说明这个问题：
“用户在电商购买商品时，对应的套餐类型、数量、折扣等信息通过自动埋点无法采集，也就无法统计分析”
我觉得这个例子举得不好，因为这个数据显然是服务端（后端）能获取到的，并且我认为前端埋点和后端埋点本就不可互相替代。
因此，应该让“前端自动埋点”与“前端手动埋点”做对比，不要把后端埋点掺和进来混淆视听。
我举一个例子，比如工具类产品的使用，因为他们大多数的使用场景都是不需要与服务端进行交互的，那么我们想要收集数据，必然要在前端埋点。
比如我在使用某卫士的清理功能，清理前它会让我选择清理哪几类垃圾，选项有：垃圾文件、插件、注册表、cookie、使用痕迹、低分软件等。
正常埋点的话，记录这个清理事件时，我会给该事件加一条LIST类型的属性，用于记录用户选择了哪几类的垃圾进行清理。
目的是未来在做分析的时候，可以知道各选项的使用率高低，从而针对性地优化或阉割。
然而，自动埋点是记录不到这条属性的，因为程序不会知道页面上的哪些元素能够成为哪个事件的特有属性，它最多只能把页面上所有元素作为所有事件的属性，但这样成本太高。
不过，对于属性的缺失，我认为并不是完全没有解决之道，但对于全埋点来说，解决了属性的缺失，就会面临数据的过载。
而对于可视化埋点，我觉得让使用者选完事件再选事件的特有属性，倒是可以实现，值得尝试。
二、优先后端埋点
有些数据只存在于前端或后端，自然只能用前端或后端埋点，我就不多说了。
那么说说那些既存在于前端又存在于后端的数据，为什么要优先后端采集：
1.前端采集的数据可能会因各种原因丢失：如网络不佳，采用批量上报策略时还可能会在上报之前被用户清理掉数据，或用户长时间不联网造成本地存储的数据溢出。而用户与服务器成功交互的数据则不会丢失，因为交互成功的同时，数据已经到服务端了，此时只需内网传输存储一下就好了。所以后端采集会更全更准。
2.如果前后端都去采集这部分数据，则会造成数据冗余，并且浪费流量、存储和清理成本。
因此，我们需要在前端采集的数据应该只是后端数据的补充，是后端拿不到的那些数据，如请求交互失败时的数据或不需与服务器交互的数据等。
三、数据过载
很多人总是想从海量的数据中挖掘价值，因此想尽可能多地保存数据，以防各种万一。
但是海量数据同样是个坑，抛开成本不说，数据太多是会干扰我们分析的。
就好比你把一个书店的书不作区分全部买了下来，反而会选择困难不知道从何读起，并且其中一定有很多书是你用不到的。
那么如果你说你有方向，有计划，有清单，为什么不照着计划一批一批地买书和看书呢。
所以，无论是最初的数据埋点，还是最终的挖掘分析，我认为一定要有方向，要有理论依据，要有取舍，否则很容易被数据的大海所淹没。
并且，如果你的产品不是足够的简单暴利，那么当你埋了过多的点（或使用了全埋点）时，这些数据所产生的传输、存储、清洗成本可能是你所承受不起的。
当然，我认为随着技术的发展，带宽、存储和计算成本在不久将来都不再是问题，但是虽说不久，至少也要5年。而且怕就怕数据量的增速比硬件的发展更快。
四、数据回溯
数据回溯不应倚仗全埋点。
一是成本太高，为了几个可能存在的需要回溯的点，导致传输、存储、清洗成本数量级的提升是否值得？
二是全埋点先天缺陷导致属性太少，进而导致每个点的回溯价值低。
所以，我认为我们还是要有预判，可以多埋一些暂时不用但是可能有价值的点，而数据的回溯也尽量依靠我们预判的埋点。
简单总结一下我的观点：
优先后端埋点，前端埋点作为后端埋点的补充。
如果产品很简单，没什么复杂的功能，也不需要精细的分析，那么当然可以使用自动埋点，它比较方便。
如果产品并不简单，那么：
在产品量级还比较小的时候，可以尝试全埋点，这个时候可以尽情地挖掘、回溯、熟悉数据。
当用户量级起来之后，我们应该已经清楚该埋哪些点了，那么人工埋点效果会更好，虽然成本也高一些。
而可视化埋点，就等到它可以让产品运营人员方便地选择各事件的特有属性时再用吧。