随着互联网用户体量增长日渐达到瓶颈，用户增长的关注点由花大精力投放拉新，转向对已有用户的精细化运营，“留住老客”成为越来越多企业的关注点。然而仅仅通过GMV，销量等最终业务数据并不能全面反映用户在平台上的行为、这些行为是如何影响最终kpi，以及用户的行为偏好。
为了能够在不影响用户体验的前提下尽可能捕捉、追踪用户的行为，我们需要通过埋点来记录用户在平台上的浏览、点击、曝光的数据，但是在笔者帮助各个企业进行埋点实践的过程中，遇到了不少问题，也踩了不少坑。笔者想就这个话题为大家讲解用户行为埋点实践中会涉及的问题，为各位读者扫清障碍。
01
埋点的含义和分类
为了帮助第一次接触埋点的读者更好理解这篇文章，笔者先简单讲一下埋点的含义和不同类型的埋点以及使用场景。
埋点，就是把一段追踪代码放入已经写好的app，小程序或者网页开发代码中，从而能在不打扰用户体验的前提下追踪用户在平台上的行为。（为了保证采集数据的完整性，企业可能会在发布新版本迭代时就会同步上线埋点代码，这样就可以看到从新版本上线以来完整的数据）
从开发方式分类，埋点可以分为以下这几种：
- 全埋点：通过加载sdk包，可以不用花太多的人力物力去自动抓取一些埋点，比如最基础的浏览、点击、启动、退出等。其中又包含可视化全埋点，它可以方便业务同事在前端进行页面或者按钮的圈选并获得页面浏览或者按钮点击的相关数据，可解释性强，便于理解，而且可以绕开技术的埋点开发流程轻松地拿到相关数据。但是全埋点或可视化全埋点的缺陷在于，他们只能抓取最基础的pv、uv。如果要进行维度下钻分析，那全埋点的可用性就比较低了。
- 主动埋点：也叫自定义埋点，开发同事把埋点代码主动嵌入到平台的开发代码中，从而实现更加深度的用户行为抓取。这种埋点开发的优势在于，业务同事能够进行维度下钻分析，因为主动埋点不仅能采集用户的动作本身，还能采集一些这个动作附属的属性，比如在电商场景中，用户点击“立即购买”按钮时，我们不光想采集点击这个动作本身，还想采集用户点击“立即购买”时，该用户下单的是什么商品、商品属于什么类型、价格如何等，这就要使用主动埋点而不是全埋点；
主动埋点的缺陷在于，该过程强依赖开发部门的资源进行埋点开发，等待时间长，且开发质量依赖于技术同事的水平，可能会出现埋点上报错误的情况。
02
埋点实践中可能会遇到的问题和解决方案
1.埋点设计过程中不注意事件和属性的命名规范，导致埋点无法使用或难以理解
这个问题在很多企业中都有出现，一开始的时候随便起一个事件名或属性名，也没有标准的规则去限制。这种做法在埋点比较少的时候还勉强适用，但是一旦业务线增加，埋点数量成倍上升的时候，就会出现混乱：比如有同事离职，下一个同事交接项目时，根本无法理解前一位同事是如何设计埋点的；还有就是如果埋点设计工作是由不同业务线的同事完成的，没有命名规范的话就会出现混乱，开发同事和分析数据的业务同事都会相当痛苦。这些问题会导致之前辛辛苦苦开发出来的埋点无法被使用，进而需要额外花很大的力气去做数据治理。
所以笔者认为，与其在后面亡羊补牢，不如在前期就定好规则让所有同事去遵守，减少后续不必要的治理成本。埋点事件的命名规则没有标准答案，只需要结合企业目前的发展现状，比如拥有产品线（app、小程序等）的个数、业务线个数等进行制定即可。一般来说，可以依照“产品线_业务线_页面名称（按钮名称）_动作”这个规则，比如说“app_ShengXian_BuyNowIcon_Click”（app中生鲜业务线内“立即购买”按钮点击），企业也可以根据部门和业务线划分去自定义规则。
2.埋点可解释性差，需要花费时间进行理解
如果第一个问题说的是埋点命名不规范，那么第二个问题就是使用埋点的人不知道某个埋点是埋在了哪里，以及该埋点的确切含义，想要使用某个埋点也是胆战心惊，需要不断询问埋点开发的同事或者靠自己的理解瞎猜，这极有可能会导致数据结果偏差，进而得出错误的业务决策，而且需要额外花费时间进行理解，降低工作效率。
解决这个问题可以通过“埋点地图”的方式实现，方法也很简单，就是每次在设计埋点的时候，顺手把该埋点涉及的页面或者按钮截图并圈选，放在埋点需求文档的第一列或者最后一列，如果有必要的话可以在备注列进行补充说明。这样可以方便开发同事理解需求，避免埋错点，也可以让使用埋点的业务同事快速了解点位埋在了哪里，减少无效的沟通成本。如果有余力的企业还可以开发一套属于自己的埋点管理平台，业务同事将要埋的点位截图上传并做简单说明，开发同事依照平台上的需求进行埋点，验收上线后即可便捷使用，这样就可以减少维护文档带来的不便，尤其适用于业务线多，场景复杂的企业。
3.埋点冗余，浪费开发资源
即使解决了问题（1）和（2），还是不可避免会出现埋点事件或属性的冗余，因为每位同事的埋点设计习惯不同。比如同样都是页面浏览这个行为，有的同事会用page_name（页面名称）这个属性，有的同事会用page_title（页面标题），但是这两个属性都代表用户浏览的是哪个页面，很明显可以统一这两个属性。从这个例子可以看出，如果不加以限制，就会出现事件或属性冗余的情况，浪费开发资源和服务器资源。
为了能让各个事件和属性名称重复利用最大化，在前面埋点规则和埋点地图的基础上，我们可以设计一个“埋点资源库”，内含所有之前已经被使用过的埋点事件名和属性名，如果在后续设计过程中发现有的名称可以被重复使用，则可以直接利用而不是重新设计。但是，如果某个企业是通过文档去迭代埋点的话，该方法会比较麻烦，因为检索之前用过的名称需要时间和精力，如果有能力且有资金和资源的话，最好是设计笔者在第（2）个问题中所述的埋点管理平台，直接通过系统管理埋点资源池，方便又高效。
03
写在最后
埋点设计和开发看似是需要消耗大量资源和时间的脏活累活，但这是之后能够精确洞察用户行为，帮助产品和运营策略快速有效迭代的基础。笔者希望通过这篇文章让更多读者明白做好埋点的重要性，并通过上述解决方案避免一些不必要的麻烦。当然了，如有读者想进一步了解文中解决方案的一些细节，或者有任何的建议，欢迎与笔者沟通。
作者：数据人创作者联盟
来源：一个数据人的自留地