用户行为埋点常见问题和陷阱讲解

随着互联网用户体量增长日渐达到瓶颈，用户增长的关注点由花大精力投放拉新，转向对已有用户的精细化运营，“留住老客”成为越来越多企业的关注点。然而仅仅通过GMV，销量等最终业务数据并不能全面反映用户在平台上的行为、这些行为是如何影响最终kpi，以及用户的行为偏好。

为了能够在不影响用户体验的前提下尽可能捕捉、追踪用户的行为，我们需要通过埋点来记录用户在平台上的浏览、点击、曝光的数据，但是在笔者帮助各个企业进行埋点实践的过程中，遇到了不少问题，也踩了不少坑。笔者想就这个话题为大家讲解用户行为埋点实践中会涉及的问题，为各位读者扫清障碍。

为了帮助第一次接触埋点的读者更好理解这篇文章，笔者先简单讲一下埋点的含义和不同类型的埋点以及使用场景。

埋点，就是把一段追踪代码放入已经写好的app，小程序或者网页开发代码中，从而能在不打扰用户体验的前提下追踪用户在平台上的行为。（为了保证采集数据的完整性，企业可能会在发布新版本迭代时就会同步上线埋点代码，这样就可以看到从新版本上线以来完整的数据）

从开发方式分类，埋点可以分为以下这几种：

这个问题在很多企业中都有出现，一开始的时候随便起一个事件名或属性名，也没有标准的规则去限制。这种做法在埋点比较少的时候还勉强适用，但是一旦业务线增加，埋点数量成倍上升的时候，就会出现混乱：比如有同事离职，下一个同事交接项目时，根本无法理解前一位同事是如何设计埋点的；还有就是如果埋点设计工作是由不同业务线的同事完成的，没有命名规范的话就会出现混乱，开发同事和分析数据的业务同事都会相当痛苦。这些问题会导致之前辛辛苦苦开发出来的埋点无法被使用，进而需要额外花很大的力气去做数据治理。

所以笔者认为，与其在后面亡羊补牢，不如在前期就定好规则让所有同事去遵守，减少后续不必要的治理成本。埋点事件的命名规则没有标准答案，只需要结合企业目前的发展现状，比如拥有产品线（app、小程序等）的个数、业务线个数等进行制定即可。一般来说，可以依照“产品线_业务线_页面名称（按钮名称）_动作”这个规则，比如说“app_ShengXian_BuyNowIcon_Click”（app中生鲜业务线内“立即购买”按钮点击），企业也可以根据部门和业务线划分去自定义规则。

2.埋点可解释性差，需要花费时间进行理解

如果第一个问题说的是埋点命名不规范，那么第二个问题就是使用埋点的人不知道某个埋点是埋在了哪里，以及该埋点的确切含义，想要使用某个埋点也是胆战心惊，需要不断询问埋点开发的同事或者靠自己的理解瞎猜，这极有可能会导致数据结果偏差，进而得出错误的业务决策，而且需要额外花费时间进行理解，降低工作效率。

解决这个问题可以通过“埋点地图”的方式实现，方法也很简单，就是每次在设计埋点的时候，顺手把该埋点涉及的页面或者按钮截图并圈选，放在埋点需求文档的第一列或者最后一列，如果有必要的话可以在备注列进行补充说明。这样可以方便开发同事理解需求，避免埋错点，也可以让使用埋点的业务同事快速了解点位埋在了哪里，减少无效的沟通成本。如果有余力的企业还可以开发一套属于自己的埋点管理平台，业务同事将要埋的点位截图上传并做简单说明，开发同事依照平台上的需求进行埋点，验收上线后即可便捷使用，这样就可以减少维护文档带来的不便，尤其适用于业务线多，场景复杂的企业。

3.埋点冗余，浪费开发资源

即使解决了问题（1）和（2），还是不可避免会出现埋点事件或属性的冗余，因为每位同事的埋点设计习惯不同。比如同样都是页面浏览这个行为，有的同事会用page_name（页面名称）这个属性，有的同事会用page_title（页面标题），但是这两个属性都代表用户浏览的是哪个页面，很明显可以统一这两个属性。从这个例子可以看出，如果不加以限制，就会出现事件或属性冗余的情况，浪费开发资源和服务器资源。

为了能让各个事件和属性名称重复利用最大化，在前面埋点规则和埋点地图的基础上，我们可以设计一个“埋点资源库”，内含所有之前已经被使用过的埋点事件名和属性名，如果在后续设计过程中发现有的名称可以被重复使用，则可以直接利用而不是重新设计。但是，如果某个企业是通过文档去迭代埋点的话，该方法会比较麻烦，因为检索之前用过的名称需要时间和精力，如果有能力且有资金和资源的话，最好是设计笔者在第（2）个问题中所述的埋点管理平台，直接通过系统管理埋点资源池，方便又高效。

埋点设计和开发看似是需要消耗大量资源和时间的脏活累活，但这是之后能够精确洞察用户行为，帮助产品和运营策略快速有效迭代的基础。笔者希望通过这篇文章让更多读者明白做好埋点的重要性，并通过上述解决方案避免一些不必要的麻烦。当然了，如有读者想进一步了解文中解决方案的一些细节，或者有任何的建议，欢迎与笔者沟通。