不过我们还是来看看优点。

首先，全埋点确实会自动采集非常多的数据，而且未来在使用数据的时候就可以从数据库中直接查询，不会面临我想看的时候因为没有埋点采集而获取不到的情况。这是非常受分析师喜爱的方式，因此经常会听到“能采集就尽量都采集，后续分析总能用得到”。其次，埋点是比较耗时的工作，需要业务方提供方案，工程师进行埋点，测试团队进行测试。而由于实际工作中埋点数量比较多，每次发布新功能或新活动都需要新的埋点，所以埋点不但费时，而且错误率也难以控制。有了全埋点，数据用不用都先收回来，由于都是程序自动完成，业务人员想要A 而工程师埋成B 这种错误也几乎不存在。

然而任何事务都有它的两面性。

首先，全埋点的“全”并非真的全部。基本的电脑浏览器和移动应用中页面内常见的用户操作包括鼠标行为、键盘行为和手指行为。例如网页端常见的鼠标点击、鼠标滑动、屏幕滚动、键盘录入、光标选取甚至静止等，移动端除了类似点击的按下，还有多指开合、拉动、用力按下等等行为。但这些操作并不会都被“埋点”，能埋点的通常仅限点击或者按下，这显然是远远不够的，甚至我们都不能称之为全埋点。

其次，全埋点的“全”以采集上报的数据量为代价，随着数据量上升导致客户端崩溃的概率也会上升。尤其是移动端，更多的数据量意味着更多的电量、流量和内存消耗。从这个角度来看，想做到真正的“全”在现阶段也是很难。

第三，即使全部行为数据可以被接收回来，具体分析时的二次梳理和加工也无法避免，甚至痛苦。因为机器无法在采集时能按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的。于是前期埋点时节省下来的人力成本，这个时候又都搭进去了。

第四，现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。

那么这个功能到底是我需要的吗？这其实是个度的问题。关于这个问题，只能说得结合你实际情况，如果你更需要随机探索过去点击行为的趋势，那么这个功能就还合适，否则还有更好的选择。

▌可视化埋点：一种所见即所得的埋点方式

代码埋点和全埋点并没有在易用性和准确性方面达到平衡。可视化埋点，很多时候也被称为“无码埋点”。前文提到，代码埋点的缺点对于网站还好，但对于移动应用来讲无疑是格外低效的。为了解决这个问题，在一部分厂商选择全埋点的同时也有大量厂商选择了一种所见即所得埋点的道路，即可视化埋点。

可视化埋点的好处是可以直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确，这还不算完，将埋点部署到所有客户端也是几乎实时生效的。因为可视化埋点的这些好处，分析的需求方，业务人员，没有权限触碰代码或者不懂得编程的人都可以非常低的门槛获取到用于分析的数据。可谓是埋点的一大进步。

可视化埋点的部署原理