数据产品——聊一聊数据埋点体系

1. 数据埋点介绍

  随着互联网，数字化，智能化的发展，企业的触点（如App，小程序，官网等）从以前的单纯展示曝光，到数字精细化运营甚至未来的AI运营，数据在辅助策略和个性化运营中都变得越来越重要，而在个性化运营中，除了传统保存到数据库的Transaction Data（交易数据，如合同，订单，物流等），在各个触点产生的用户Behavior Data(行为数据，如用户曝光，点击，停留时长等)也同等重要，实现用户行为数据的合理设计，规范上报，数据应用价值的起点正是埋点体系，今天笔者就跟大家一起聊一聊数据产品中举足轻重的埋点体系产品。

1.1 埋点的概念

  Transaction Data（交易数据，如合同，订单，物流等），此类数据往往为了实现业务流程通过各类微服务提交保存到数据库的数据，此类数据的缺失或崩溃，直接代表业务流程的不完善或中断。
  Behavior Data(用户在企业的App，官网，小程序等终端触点行为数据，如用户曝光，点击，停留时长等)，这类数据最大的一个特点就是你会发现即使不做任何收集，它本身并不影响系统的正常功能使用，因此产品在完善功能或者引流客户的早期，确实有可能不怎么重视此类数据，只是到了产品运营阶段，如果少了它，企业会发现对自己的用户在自己产品终端上的行为洞察就趋近于零，因此采集此类数据的技术体系就是埋点体系。
  总而言之，埋点就是一种常见的收集用户在终端触点行为数据的技术体系，埋点技术即数据采集技术，而基于此类需求产生的产品，就是埋点平台。

1.2 为什么要埋点

  从业务和产品角度而言，自然是为了更好地洞察用户在自己产品上的行为，从而更加精准地实现个性化营销；
  从数据的角度而言，如果说各种数据应用的产品是枪、炮、坦克、飞机等，那么数据仓库就是兵工厂，埋点就是钢和铁；如果说各种数据应用的产品是包子，饺子等，那么数据仓库就是早餐厅，埋点就是面粉。

1.3 埋点的分类

• Web端（含小程序）埋点：主要是通过在页面中注入一段JavaScript代码，然后对收集的数据进行上报的技术，时至今日，互联网从Web 1.0到Web 2.0，再到移动互联网（手机Web端，小程序等）；Web埋点技术也经历了网页信息，增加Cookie，增加事件等变革，截止笔者写这篇文章，已经有比较成熟的服务厂商把JavaScript封装成了通用的SDK，有些甚至也开源。

• App端埋点：主要是通过在代码中加入特殊的代码或者也引入一个SDK，对App中的信息进行收集的一种技术，截止笔者写这篇文章，App埋点的SDK通常又分为IOS端SDK，Android端SDK，以及新起之秀HarmonyOS（华为）端的SDK；App端是典型的移动互联网，随着App的兴起和大数据技术的普及，也标志着埋点技术进入大数据时代。

• 服务端埋点：也叫接口埋点，本质上是通过一个接口服务，将一条业务需求需要的日志按照符合埋点规范的格式上报给到埋点系统。

• 实体店端埋点：随着埋点概念的普及，有些新兴的智慧门店，也把门店定义成一个用户的终端触点，通过在保护用户隐私且得到用户授权的前提下，在门店安装摄像头，录音器等来捕捉门店内的用户行为，如用户量，服务人员是否着装规范，有无客户被冷漠等。

  以上相关的埋点类型中，通常用的较多的还是 Web端（含小程序）埋点和 App端埋点，但需要注意的随着笔者写这篇文章近些年的发展， Web端（含小程序）埋点和 App端埋点的埋点终端并不局限于手机，比如号称新的移动终端的新能源车机，以及各种数字穿戴设备如智能手表，智能眼镜等等都可以是一个终端。

2. 如何管理埋点

  上一节阐述了什么是埋点，此章节一起聊聊如何管理好埋点。

2.1 目标数据的确定

  数据价值的起点是埋点，埋点的起点则是目标数据的收集，即所谓的需要收集哪些数据；目标数据收集的关键则是必要的全面，即业务或产品提出需求需要的数据进行埋点，而不是埋点越全越好，本质上用的是产品迭代的飞轮效应，而不是在设计阶段就用有限的时间去追求和挑战无限的全面。

  需要收集的目标数据主要分为3部分，用户信息，页面元素，触发的事件。

• 用户信息：主要是用户身份与硬件环境，通过对用户信息的收集，个性化营销和千人千面成为可能。

  • 用户身份：用户登录后唯一ID，用户登录前的游客ID等；
  • 硬件环境：硬件设备码，操作系统，网络IP，经纬度等；

• 页面元素：主要是是三个级别，页面，某块和元素，通常情况下，这三个级别之间，同级别之间可能会存在从属关系，类似某个元素属于某个模块，某个模块属于某个页面；但在埋点收集的时候通常只上报最子集的模块（含模块ID），而某块之间，模块与页面的层级关系，则一般作为一张级联的主数据表存在埋点系统的服务器端。如统计微信点击朋友圈的次数，只要上报朋友圈这个元素的点击事件即可，通常建议不需要将发现页上报上去，而朋友圈和发现页的关系则是维护在一张关系级联表上，为什么说是建议呢？其实此处的处理和数据库冗余是一个原理，如果你洞察到业务通常使用到的数据就是要包含这一层级联关系，则为了查询的高效快速，冗余上报一下其实也无可厚非。

• 触发的事件：事件，顾名思义就是用户对页面元素做了什么，通常分为曝光，点击，页面事件……

• 其他：……

  综上所述，埋点就是收集谁（用户信息）在什么时间对什么（页面元素）做了什么（事件），举个电商中常见的加购(加入购物车)为例，点击加入购物车这个按钮就是要埋的点，首先这是一个点击事件，其次要包含点击的用户的用户ID（用户唯一标识码）、操作系统、城市（可以来自用户选择的，IP解析的，经纬度获取的等）等信息，最后因为加入购物车的是商品，所以商品的商品ID（商品唯一标识码）也要上报。

  那是不是所有发生的事件及其涉及的相关信息都要上报呢？报的越多越好？显然不是的，其实这跟存入数据库的数据是一个道理，通常只上报现阶段能产生业务意义的事件及其相关信息（通常以业务分析师定义的口径为准）才会上报，毕竟如果用户量一多，上报的流量，存储的费用，计算的费用都是不小的费用，所以永远不要忘记业务的本质是赋能商业变现，而不是炫技。

2.2 埋点的工作流程

  为了避免业务侧抱怨这个数据都没有？这不是业内通用的？这不是很简单？通常的埋点工作也是有一套比较正规的流程的；

1. 首先埋点编码是由技术部门完成的，需要建立一套完整的、适用于全公司的埋点规范；
2. 业务侧的业务分析师或者产品经理提出埋点需求，只需要将埋点的点位和逻辑需求写清楚，然后到埋点的技术管理部门申请；
3. 埋点的技术管理部门依据制定好的规则，对新增的页面、模块、元素及事件进行编码，然后更新埋点文档；
4. 测试人员根据埋点文档对业务侧的产品经理提出的需求进行确认。测试通过的埋点在埋点管理系统中状态变更为验证通过；
5. 待版本发布后，埋点状态变更为有效。
6. 业务侧产品经理也可以通过埋点信息上报后的数据逻辑对埋点进行业务验证。

  通过此流程，往往将业务或产品侧正常提出需求的埋点，作为必须完成的数据指标，作为没有提出过需求的埋点数据，则记入下次的埋点需求中，从而平衡好业务、产品侧与开发侧对埋点工作的认知偏差。

2.3 埋点元数据管理

  做完了埋点，只是保证了收集到了信息，但信息一多就容易乱，紊乱的信息就很难产生真正的业务价值，甚至带来业务损失，因此管理好埋点也很重要——埋点的元数据管理。

  埋点的元数据管理和其他元数据管理的要义是一样的，通常是2点；

• 埋有所编：茶壶里有饺子要倒得出来，埋点也是一个道理，你需要给每一个埋点一个名分，即一个埋点对应一个标识编码；这个标识不论是在埋点管理还是后续的数据分析中都至关重要；

• 编的望文生义： 给埋点对象标识编码以及备注成中文时，为了便于检索和维护，需要有一套统一的原则，如全路径原则（页面—>模块—>元素—>事件），如微信的朋友圈点击事件（发现页—>朋友圈—>点击）。

  是否需要建立一套埋点元数据库甚至系统呢？这个需要结合公司的自身情况，如果公司是技术型公司，业务和产品侧又十分重视在埋点的投入，则无口厚非；但就埋点元数据本身，维护在一些在线表格，然后按照角色赋权对表格的只读或编辑，也能实现类似的目的。

2.4 埋点管理平台化

  从埋点埋点工作流程中参与的角色可以发现，整个埋点流程并不止技术人员，因此，通常为了更好的实施整个埋点管理，一般都会有一套图形界面化的埋点系统，此埋点系统一般会包含哪些部分呢？

• 元数据管理：2.3节已经着重介绍；

• 埋点测试工具：

  • 可视化埋点测试：将页面和上报的埋点数据所见即所得的展示出来，方便测试人员测试或弥补埋点设计上的遗漏，原型设计如下图；
    

  • 实时上报埋点测试：可视化埋点测试的实现还是有点难度，如果短期做不到，那实时上报埋点测试一定是要支持的，即测试或产品在终端操作时，能有一个区域可以实时接收到埋点数据，从而验证操作后是否正确收集到了数据，如下图；
    

• 埋点监控：主要对元数据定义了的埋点是否正常上报了，是否有未知埋点和异常埋点上报进行提醒。是否正常上报一是通过测试人员的回归测试，二是通过算法模型按期检测；未知埋点主要是通过与已经注册的元数据进行对比分析，异常埋点则是根据上报数据数值本身是否异常或超出阈值；

• 埋点（使用）分析方法：内嵌分析模型，结合埋点上报的数据，实现开箱即用，利用托拉拽实现人人都是数据分析师，以数据分析为飞轮更好的驱动企业产品效率，实现更好的增长与转化；

• 埋点数据实时/离线导出：埋点数据终究不是企业的全部数据，有时为了满足业务或产品的数据应用，少不了企业的埋点数据和业务系统落库数据的结合，而处理此类数据需求，往往还是需要先将数据集成到一个统一的地方如数据仓库，因此埋点平台往往也要支持通用的数据实时或离线导出；

• 其他：……

3. 如何实施埋点

  接下来此章节从技术原理的角度剖析下埋点的具体技术实施，由于篇幅的原因，次篇章重在讲解技术原理，暂不涉及过多的技术代码，如有相关的需要，笔者可后续再单独整理相关技术代码。

3.1 采购还是自研埋点工具？

  是自研埋点还是采购业内通用的埋点工具（分SaaS版本和On-premises版本）呢？其实这个没有固定的答案，需要结合公司内部的需求，其中的区别在于：

• 采购业内通用的埋点工具：不论是开发成本还是维护成本，业内通用的工具平台已经在其他企业得到了实践，采购的费用往往只会折射在系统的license费用上，一般都是要远远小于组建埋点基建团队（前端、后端、产品、架构师、测试、UIUX、DevOps等）的费用，缺点也比较明显，业内工具往往偏向业内通用的场景，一些满足个别企业个性化的功能需要定开或者完全不支持，新功能往往也只能等待埋点工具厂商的升级迭代。

• 自研：一般有两个极端情况会进行自研埋点，一是埋点需求的场景足够小，比如只有几个页面，此时的埋点收益并不足以让业务侧或产品侧买单去构建一个完整的埋点系统，此时往往只是开发侧自己捣鼓一个埋点方案并实现；另一个是公司高层或者部门性质本身就负责相关平台的基建，此类埋点平台的使命不仅是本部门使用，公司层面需要作为基建推广到其他门部门，以便于追求足够的个性化服务。

3.2 选择全埋点还是自定义埋点

  此选择也是要分析公司状况，以下给出一些可参考的情形：

• 公司刚启动，技术人员少且人员流动大，公司目标主要是业务扩张中，尚未进入精细化运营阶段。此类场景比较适合无埋点技术；
• 项目在天使阶段之后的融资阶段成长期，相关业务复杂度高，App、小程序，Web应用的技术多样化，业务扩张增长也遇到一些瓶颈，业务运营需要转向进入精细化运营阶段，此时就不太建议再用无埋点技术了；
• 公司流量巨大，业务复杂度高。当公司进入这个阶段的时候，就需要有埋点和无埋点技术联合使用。对无埋点技术也要进行一定的修改，上报阶段要通过后台配置项进行配置上报。这个阶段建设自己的埋点管理平台了。

3.3 Web端埋点

  JavaScript埋点是主要应用于Web应用的埋点，通过在页面的底部加入一段JavaScript代码来完成埋点。一般在页面上显示为一个GIF小图标，图标的来源是一个JavaScript文件地址。JavaScript埋点一般支持自定义事件的收集，这样就可以充分地对用户的行为进行收集JavaScript埋点也会应用Cookie技术，对用户身份进行标识，但是如果用户清除了Cookie，会导致用户身份丢失。

  业内对这一块的技术已经很成熟了，因此往往也会集成封装成WebJS SDK以 支持 谷歌浏览器、搜狗浏览器、火狐浏览器、QQ 浏览器、Safari 浏览器、Mobile 端浏览器，并且全面支持 H5，覆盖市面上主流的浏览器。只要在 layout 文件里面加入几行代码，就可以集成JS SDK，可以采集用户的行为数据。

3.4 小程序端埋点

  小程序埋点的本质也是基于JavaScript，同样业内SDK 一般已经支持微信小程序、阿里(支付宝)小程序、百度小程序、抖音小程序、QQ小程序、淘宝小程序、快手小程序、京东小程序等应用。

3.5 App端埋点

  App埋点在操作系统层面又分为IOS端埋点，Android端埋点以及目前兴起的HarmonyOS（华为）端，这些端的埋点方式又分有埋点（也叫自定义埋点）技术和无埋点（也叫全埋点）技术。

• 有埋点技术：在App刚兴起时，并没有无埋点技术，都是有埋点技术。有埋点的本质就是在逻辑代码中插入一条需求需要的埋点代码进行数据上报。以此达到业务需求精准埋点，但是也带来了挑战——埋点管理问题。往往公司越大，部门越细，业务越复杂，以及伴随人员的流动，一旦埋点规则或者埋点人员的认知及水平良莠不齐，很容易就慢慢导致埋点丢失或者改变，从而给后续数据使用者带来数据错误，数据紊乱打架的各种现象；伴随着大家对有埋点技术的质疑，无埋点技术应运而生。结合此篇文章的介绍，其实有埋点出现这样的问题本身并不是技术问题，是管理问题，埋点技术只是承接了管理体系缺失的锅罢了，同理，无埋点技术就真的高枕无忧了吗？
• 无埋点技术：无埋点技术也叫全埋点技术，很多不了解埋点的业务人员一听这个名字，感觉仿佛等到了自己的救世主一般，无埋点技术的本质是通过接入SDK自动完成埋点，从而规避很多人工错误。乍看之下，无埋点显得清新脱俗，其实无埋点本身还是有不少缺点的:
  • 技术名字取得吓人，实际上只能监控部分事件，并不能上报所有事件信息；
  • App开发的复杂性上升，无埋点技术并不能兼容所有的场景；
  • 无埋点事件过渡强调标准化上报，哪怕很多业务不需要的无效信息也上报，大量的无效信息上报占据的流量、计算处理带宽，甚至拖累App的响应速度；
  • 无埋点事件有自己标准化的采集模式，许多场景无法按照业务逻辑实现非标准化的的信息跟踪。

3.6 服务后端上报埋点

  以上提到的Web端埋点，小程序端埋点，App端埋点等，本质上可以归类为客户终端触点的埋点，埋点系统内数据存储的本质其实是存在一个个如用户表，事件表等对象中，无非是这些表是存在数据库中还是存在消息队列（如Kafka中）罢了，那只要熟悉这些数据的存储及流转，完全可以利用后端代码如Java、Python等跟数据库或者其他存储对象交互提供打点上报到相应的表中，已实现与企业内部数据打通，此类技术就是服务后端上报埋点，发展到今天一般也是有现成的服务端上报SDK提供参考。

  以下是某埋点工具的各大SDK的参考功能。

  由于笔墨和时间关系，以上是笔者基于产品视角对埋点技术体系的一个解读和总结，如果读者对埋点技术需要更加详细的介绍，笔者建议也可以阅读一些国际、国内通用的埋点工具平台的说明帮助文档，往往读透一篇该领域优秀代表的说明文档，往往是了解这个领域及落地工具最好的途径。