相信大部分做过埋点相关工作的朋友，都曾经在“无止境”的埋点方案制定、埋点部署实施、埋点检查等“枯燥”的工作中，幻想过——

会不会有一天，什么都不用做，或只需要做最最简单的一步操作，然后各种数据就自己“自动地”、“准确地”纷至沓来，让我们从此不再为埋点而感到烦恼。

这似乎是一个“不可能”的需求，但事实上很早就有提供“类似”解决方案的产品出现，甚至可以说，这种“需求”的满足，已经成为了大多数相关产品会提供的一种“标准化”的功能。

这也就是我们今天想闲扯一下的——“无埋点”技术。

什么是“无埋点”？

回答这个问题，我们需要先回到“埋点”这个经常接触的名词中，所谓“埋点”简单来说就是在我们的应用、网站中收集一些特定的信息。

它是我们一切数据化工作的基础，因为数据不会主动地跳出来，“埋点”的过程，就像在一条沙河中淘金。

那什么是“无埋点”呢？从字面理解是“不埋点”，但这种解读显然是错误的，“无埋点”仍然是在埋点，只是不需要开发人员以代码形式一条条手动埋点。所以理解为“无痕埋点”、“全埋点”相对来说合适一些，但这几者之间内在存在很大不同。

“无埋点”与常规的“埋点”方案有何差异？

从流程上看，常规“埋点”，首先需要制定埋点方案（确定需要进行哪些点位的监测、哪些数据的抓取、传值如何、有哪些设置等），其次进行埋点部署，接着进行审查、验证，都执行完毕后，再开始分析查看数据，并在网站、应用出现变更或需求发生变更后，再开始一波新的循环。

而“无埋点”，流程上则可能显得“简单一些”，开发人员部署好SDK，SDK开始自动捕获用户发生的所有行为，并且全部上报，开发人员不需要部署其他代码，业务人员可以在后台对上报的数据进行圈选、分析。

从上述的内容中，我们可以清楚的看到两者的优劣。相较“无埋点”而言，“埋点”是一项极其复杂而繁琐，并且要求很高的工作，在执行过程中，往往会陷入几个难点的坑爬不出来。

容易踩的坑一：

“埋点”工作首先需要清晰自己要什么数据，自己想做什么样的分析。

但令人头疼的是，很多时候真的很难知道自己想要什么，或者“现在”的我们说“我知道我想要什么”，然后“未来”的我们，狠狠地抽了我们一巴掌，然后说：“不！你不知道！”

表现为一种常见的场景即：

“这块的数据呢？”

“这块为什么没有埋点？”

“早干什么去了？”

“你们不做检查的吗？”

真，灵魂拷问。

容易踩的坑二：

此外，还需要能清晰的传达需求，并让开发理解，准确、无误地部署实施；

容易踩的坑三：

最后就是 “无尽的埋点炼狱”——“埋点”这件事没有明确的完工时间，每当需求变更、网站改版，我们都不得不重新审视&规划现在的方案。

从这种角度来看，“无埋点”确确实实显得讨喜，正如 Heap（国外一款主打无埋点，或者说 ’auto-capture’ 的工具）在列举自身优势时，频频提到的——

“The data is there.”

数据通过SDK，“自动”、“全部”地抓取后，就存储在数据库里，任君攫取——

忘了部署了？

不可能的，因为会自动抓取所有事件；

没有数据？

不会的，只是从全部抓取的行为数据中，圈选出来的事情

网站改版了需要再麻烦开发？

没必要，继续全部抓，抓完后我自己更新就是了……

听起来很美好。

但在现实操作中，真的如上述所说那么完美？

现实往往很残酷，全量的行为获取固然是美好的一件事情，但如果考虑到这种方式对服务器产生的压力呢？考虑到全量数据存储在服务器的数据存储压力呢？

试想一下如果GA使用无埋点方案，那将是多么可怕的服务器压力，多么可怕的数据量——而且其中大部分还是无价值的数据。这也是为什么无埋点数据往往对应更短的数据存取期限，或需要使用服务器进行本地私有化部署的原因。

此外，“无埋点”是否真的能准确抓取用户行为数据？

以WEB前端为例，文档通常是以DOM Tree的形式呈现，如下图所示，通过一个元素在DOM Tree中的位置，以及其自身的属性，我们就可以定位到某个元素。

（图片来源于网络）

比如我们常用的JSpath/Xpath，以公司官网的LOGO元素为例，通过JSpath，可以表现为这种形式：

document.querySelector(“body>header>nav>div>div.navigation__column.left>div >a”)

如果通过Xpath则可以表现为这种形式：/html/body/header/nav/div/div[1]/div/a

通过JSpath或Xpath等方式，我们可以定位一个元素，甚至为这个元素生成一个独特的Md5标识ID，如此将其他点击、曝光等行为与之绑定，这样后续数据可以此ID进行汇总，我们再进行分析时，只要圈选出该元素即可获取相应的数据。

但这种方式在一定范围下适用，对于一些复杂网页而言，尤其随着前端技术的发展，虚拟化、动态化的DOM结构，使得之前按图索骥这种方式会产生难以回避的问题。

当然我们始终也在寻找更好的方案，比如可以在规则上弱化绝对路径，而采用更加宽泛、概略、智能的定位方式；可以选择通过相对位置进行圈选；可以设置一些更加复杂的配置、设置条件等等，但这始终难以和人工埋点的准确性相媲美。

除了上述问题之外，“无埋点”还有一个致命缺陷——数据上下文、相关信息获取等一类难以自动获取的数据。

举个例子，我可以同时知道一个留资页面上所有按钮、链接的点击量，但是如果我想看的是留资提交按钮的成功提交次数呢？此类信息我们不得不根据请求的响应状态进行判断，单纯的知道提交按钮的点击次数不一定没有用，但很显然，更重要的是那些有“状态”的提交信息，提交成功、提交失败等。

如上的问题，固然存在，当然该领域也在不断更新、发展，很多的解决方案也在持续提出。

但总体而言，依然难以令人“满意”，此类产品变化就是一个体现。例如国内曾经主打无埋点的Growing IO，现在主推的也是 “无埋点”+“埋点”的双模采集方案。

“无埋点”有优也有劣，并非有一个绝对的定论：一定可取或者绝无可取。

从市场反应看，“无埋点”方案认可程度较高，大部分第三方工具厂商如今或多或少都提供了相应或类似的解决方案。

除了“无埋点”外，还有一种“可视化埋点”的方案，“可视化埋点”方案其实定义并不清晰，“埋点”方案和“无埋点”方案都有对应的“可视化埋点”方案，前者使用可视化的窗口定义参数部署埋点，相当于把需要部署的代码转换为可以手工操作的界面，这样业务可以直接通过界面操作，甚至可以不需要开发参数；后者通过“可视化方案”进行配置、设定，相当于弥补了“无埋点”的一些不足。

这听起来似乎是一种很好的方法，但无法回避一个问题，“可视化埋点”有时操作很麻烦，复杂程度、繁琐程度甚至远超使用代码进行的“埋点”，而且大多数情况下需要开发。

另外一类解决方案是和开发紧密绑定，例如某个元素在开发时就绑定好相应的属性，参数，然后配以工具，自动化的完成埋点，这种方案的好处在于和开发紧密结合。

但问题也在于此，至少对于大多数第三方工具而言，想要如此和开发紧密关联，几乎是不可能的，甚至我们需要强调工具对现有开发的无侵入性、解耦，例如现在大家接受程度越来越高的GTM（Google Tag Manager）。

后端埋点也是一种发展已久的方案，但是后端埋点很明显的问题在于，它不可能离开前端埋点单独使用，否则，我们将无法获取用户在前端发生的那些无法和服务器交互的互动行为，同时后端埋点的复杂度、技术难度、安全性也是难以回避的问题。

那么是不是就没有一种完美的解决方案了？是不是我们就无法逃避“埋点”的炼狱呢？

其实我觉得目前看来确实如此，数据的获取，实实在在是一个“淘金”的过程，但从长远来看，仍有一些令人欣喜的角度、方向或许可能实现。

例如LocalStorage / IndexedDB此类前端数据存储的发展，可以允许我们在客户端存储远超以往的数据信息，以往需要持续上传至服务器的数据，我们可以简化为日志信息，大量、持久的存储在用户的本地。

而前端类SQL的发展以及一些机器学习，甚至神经网络算法在前端领域的实现，也使得我们在前端进行数据ETL与建模变为可能。

试想一下：

– 如果日志数据存储在本地，那么网络状态带来的丢数问题可以得到极大的缓解。

– 全量存储在本地的行为日志，也无需考虑大规模用户量情况下服务器的请求&存储压力，同时一定期限的存储，还保证数据一定的可追溯性。

– 对日志的提取&分析，基于前端类SQL语言和使用前端算法建模，对于从事相应工作的工程师而言，也更加贴近于数据本质，从而可以和复杂、繁多的前端技术、业务流程、UI界面等等解耦。

当然这种方式在实现上也存在相应的障碍&难度，本身形式也存在问题，但乐观的是前端技术发展迅速，许多周边生态逐渐成熟，我们诸多畅想实现的可行性也在不断增加。

未来可期。