【outdated】对埋点的一些思考
— 1 min read
本篇文章迁移自笔者草稿 RepoPenumbra, 并做了一些修改
这篇文章涉及到了许多为各种不同应用设计埋点方案，以及为什么这样设计的概念，而在实际开发中我只接触/使用过
Google Analytics以及试了下国内的可视化埋点平台，因此文中的观点可能存在疏漏与错误, 本文部分内容来自于网络整理/筛选，请仔细鉴别后使用。如果有什么错误遗漏，欢迎提 ISSUE/PR~ 本文中提到的埋点包含错误监控
为什么我们需要埋点？
我自己将埋点译作 User Action Tracking，很明显的，即是对用户在我们的应用表现层里做出的各种动作。从子页面的 PV/UV/VV 等指标，到网页上哪一块交互被触发的次数最多，实际上都可以纳入埋点的范畴。只要我们关心这些数据，我们就可以使用埋点的方式来收集，如：
- 用户在哪个页面停留的最多？哪个页面进来一瞅就叉掉了？
- 哪个交互被触发的最多？有没有误触哇（切图的出来挨打）？
- 从哪个渠道来的最多？SEO 做的不行啊，就这么点人是百度来的？出来挨打
- 这个应用首屏/白屏时间有点长啊？没加载出来用户就 × 了？挨打
- 这个 http 请求的响应时间这么长？轮到后端挨打了
- 为啥每个用户这段代码都出异常了？
- ...
这些信息实际上可以细分为用户行为监控、前端性能监控、以及异常告警监控的实例，我把他们统一归类为用户行为。因为我们通常是以用户体验为出发点而进行埋点实行的~
这些数据反映出来的信息对于产品爸爸（？）来说是很宝贵的，它们即能成为产品新需求（🙄 ）的来源，也能检验已经上线的功能是否达到了预期。当然，不同产品和不同产品经理，所关注的数据是不同的，因此采取的埋点方案也就多种多样。GA 是很方便, 但是同样也有不够细致的缺点, 这也是为什么近年前有MixAlpha后有国内神策数据/诸葛IO等一批企业开始提供更 "细致" 的埋点服务.
有哪些埋点方案？
随着埋点技术的发展，越来越多的埋点方式被提出，大致可以分为以下几种：
代码埋点，在你需要进行数据收集的地方植入代码，并在用户触发了某些行为时，自动进行统计分析，生成可视化图表。如GA一把梭，但是 GA 主要是以页面浏览和会话为核心的。当然代码埋点是高度可定制化的，你可以很精确地针对特定属性/事件进行设计功能，这是优点之一，但缺点也很明显：
如果有多个控件或多种行为信息需要收集，就需要为各处的埋点都添加相应的代码。而且在更新产品后需要新增埋点代码，这也是一项额外支出。对于需要手动更新的 APP 来说，如果用户不更新，那你就失去了他的数据。因为用户拒绝更新你可没有机会更新埋点代码噢, 而且有可能更新之后原来的埋点数据有一部分就被弃用了.
可视化埋点，通过可视化工具配置需要进行采集的节点，会在前端自动解析配置。如 Mixpanel 与 诸葛 io 等。我觉得可视化埋点实际上还是代码埋点，只是用一个可视化的自动系统代替了自己写埋点代码再植入的过程，也可以在业务代码中增加自定义的埋点事件。
可视化埋点的具体流程，移动端，以 MixPanel（它开源了自己的安卓与 IOS 代码）为例：
点击某个支持的控件类型实例，设置点击该按钮发送
Refresh事件，点击 Deploy，把这个配置下发下去，然后所有安装了此 SDK 的 APP 都会在 APP 启动会更新配置，以后便能够收集信息。（当前很多 APP 如手游，核心代码和配置资源是分开的，可以使用网络下载资源）网页端流程，以诸葛 IO 为例
在 HTML 中预装 SDK，然后在平台中确定哪些控件需要被跟踪，在应用启动时 SDK 会自动更新哪些控件需要被更新。同样的，网页的核心代码和配置也是分割开的。
但是！由于是通过可视化系统埋点，当然不是所有的控件都能够被支持的（我一时没想到哪些应该不能够支持）。与上面的代码埋点比起来，可视化埋点的最大好处就是非技术人员也可以使用，可以让产品爸爸自己搞埋点了~~而且，后续产品更新时，对埋点进行更新的成本也小多了。这也是我们考虑采取的方案, 因为要搭建数据中台的话, 只靠 GA 数据是远远不够的.
无埋点，无埋点并不是“淦我不搞埋点了累死俺了”，而是“每个地方我都给你埋个点”。也就是全部埋点，前端的每一个事件都会被绑定一个特殊的标识（
type），所有的事件触发记录及其标识都会被保留下来。定期进行上传到服务器（有可能以天为单位也有可能以小时？）, 在这里我的理解是, 除了需要和接口交互的控件以外, 其他静态的行为也会被 APP 保存起来, 然后定期上传, 这样既不影响用户使用又能神不知鬼不觉(?), 然后配合专门配置的解析工具提取出真正需要的那部分信息，再进行可视化处理~~所有数据都被采集了，那么我们就不用担心产品迭代着迭代着突然发现之前有一些特殊类型的数据忘记进行埋点处理了（可回溯！），也不会出现“淦这个控件有毒事件埋错了”的情况。但是这种方式会采集全量数据，服务器压力就大咯，也不能灵活定制了~
当然无埋点的实现也很简单，比如直接造个轮子把各种 dom 事件啥的监听起来，开局引入就好了，然后再使用一些可视化的库把数据展示出来。举例
- 统计页面停留时长逻辑（代码埋点/无痕埋点）：
阻塞页面关闭 -> 发送阻塞式的 ajax 请求，等数据发出去后再跳转（对不起用户哥哥影响宁体验了）
跳转到新页面后再发请求 -> Beacon API
（更多方案以及具体实现见： 前端全（无）埋点之页面停留时长统计）
- 统计页面停留时长逻辑（代码埋点/无痕埋点）：
后端埋点，暂不记录，有兴趣的同学可以自行查找相关资料~
CSS 埋点，emmm，没啥意义，只图一乐，猛戳
总结
实际上在我查阅网络文章的过程中，大部分作者对于埋点方案的区分并不十分明显，就如无痕埋点在部分文章中被认为叫做可视化埋点，但我认为二者还是有一定区别的，可视化埋点不一定能 cover 所有业务场景，但无痕埋点（全埋点）或许可以。相反，如果是无痕埋点也无法 handle 的苛刻场景，可视化埋点一定做不到。二者的选择完全看选型时更在意“简易”还是“全面”。（要是我看武侠小说就可以拿两种武功出来比了...）
不同应用怎么设计埋点？
以设计一个全局 PV 统计方案思路引入（代码埋点）：
- 对于 SPA 应用，只要在入口文件进行路由钩子绑定事件即可, 如 Vue 的路由守卫.
- 对于 MPA 应用，可以抽离封装公用逻辑，为每个入口文件注入, 比如每个 HTML 模板植入公用的 SDK.
- 混合应用采用 MPA 应用的方案
- SSR 应用，以 Jinja（Python 模板）为例，调用 TemplateView 则为渲染页面（不同于前后端分离项目，服务端无法获知接口调用与页面渲染的对应关系），统计其调用次数及 TemplateName 可知页面 PV。（这段我抄的，不过我猜大概意思类似 Koa 调用 EJS 渲染页面时统计调用次数？）
这只是一个很简单的例子，进行埋点方案选型时需要意识到埋点方案实际上没有最好的，只有最合适的。以下继续纸上谈兵，研究下前端埋点方案和上报方案设计~
明确监控数据，这个产品，或者精确到网页/app 等，其中普遍需要监控并收集的数据
监控分为三个阶段：用户进入网页首页、用户在网页内部交互和交互中报错
定制埋点方案，上述的几种方案中，我觉得应用面最广的还是代码埋点，灵活、带宽压力小、埋点控件/事件高度可定制。比如在用户离开时，发送一个请求给服务端，告知停留信息等。
确定上报周期及数据类型，如果埋点的事件不是很多或者数据不是很多，周期频率可以紧凑一些，比如监控用户的交互事件，可以在用户触发事件后，立刻上报用户所触发的事件类型。如果埋点的事件较多/数据量大，可以通过本地存储的方式先缓存上报信息，然后定期上报。
至于上报哪些信息，当然就看业务需要啦~
前后端通信方式，主要是需要加密部分，需要和后端哥哥商讨加密的方式和机制~
可视化/数据提取，之前接触过的 Antd Pro ，感觉就很适合用来做这类事情，配合 AntV 等数据可视化类库进行可视化工作~，其实我觉得这一步可以完全自动化，后端提取数据并初步整理，前端开发一个二次封装过的可视化平台，从接口中取得数据，直接通过已经写好的逻辑展示出来，岂不妙哉（我瞎想的我可能还不会）？
总结
会突然想写这篇文章来整理一下埋点的知识，是因为昨天突发奇想给只有两篇博文（还有一篇是特么的寒假计划）的博客配上了 Google Analytics，今天突然发现还有另外一个人访问了？感觉这也是一个平常可能会忽视的领域，所以特此整理。许多论点是我在很多文章的基础上加工整理出来的，可能违背了作者原本的意思。在此向诸位作者说一声抱歉。