产品的后端埋点应该怎么梳理？

最近开始接触精细化运营的相关数据需求，考虑要使用某数据工具。

但接入这些工具，需要在后端进行埋点。

于是产生了如下两个问题：

1、应该如何梳理后端所需要的埋点？

2、后端埋点与前端埋点有什么不同？

埋点一般是为了后续做数据统计分析或业务监控使用，

所以这里分埋点采集、数据计算方式、统计监控应用，倒过来说明，

1. 统计分析，一般常见的分析比如有用户行为分析、转化/成功/失败率分析（漏斗模型）、内容用户属性分析，以及监控上，常有每秒/分钟/小时/天数据量指标同比/环比变化的监控。

分析维度和指标主要看这个统计分析的目的，是用于考评业务的KPI，还是用于辅助产品设计方向，还是用于帮助业务及时发现问题，不同的目的，分析的角度和精细度要求等都不同。

统计报表的组织形式，要考虑报表是给谁看，面向公司大领导的报表、面向技术内部监控使用的统计报表、面向公司内部技术小白比如运营团队的运营数据报表，以及面向外部用户客户的产品化数据报表，使用的对象不同，报表的信息筛选和组织形式设计上都会不同。

2. 数据计算方式，根据不同的统计分析维度、指标结果要求，具体可能有基于日志方式统计计算、基于业务数据库源统计计算（离线或实时计算），

基于日志方式统计，例如pmcaff的用户回答问题时，需要发布回答这个按钮的点击量统计，就需要前端用户点击该按钮时发出点击日志，基于这个日志统计；而某个接口的执行成功/失败量统计，就需要该接口发起执行、执行成功/执行失败时各发出一条日志，基于接口发出的日志统计。

业务数据库计算方式，例如要统计当前所有状态正常/被屏蔽的回答数量，那么就基于数据库按回答的状态进行筛选查询就可得到，无需基于日志采集来统计。

再进一步举这个例子，假设这个回答的数据库里存有回答ID、回答发布时间、回答状态（正常、屏蔽）几个字段数据，再假设回答发布后，整体上它的状态是在两种状态之间动态变化互相覆盖的，
那么如果想要在2月10日周五，统计过去一周2月3日~2月9日每天的正常回答量，这里就有两种理解和处理方式，
第一种方式，基于2月10日统计那时刻的数据库数据源计算，那么在2月10日统计时，查询库里发布时间在2月3日的，状态为正常的回答量等等，依次得到各天的正常回答量；
第二种方式，在回答发布接口，采集记录回答状态变更的日志，比如发布回答成功默认为正常状态，记一次变为正常的日志，过会后台管理发现回答违规屏蔽掉，再记一次回答变为屏蔽状态的日志，那么基于这些日志，按日期时间范围+日志中变更后的回答状态值，并按日志中记录的回答ID去重，就可统计得到每天状态变为正常的不重复回答量。
两种方式各有优缺点，第一种方式优点是统计结果与数据库当前现有数据量一致性较好，缺点是得到的2月3日的发布数据其实是2月10日统计那一刻的数据，并不能反映2月3日当天的状况，并且如果在2月11日再去用当时的数据库数据筛选方式统计2月3日发布的数据量，得到的结果可能与2月10日去统计得到的结果不同。
第二种方式优点是基于历史固有日志，可以反映当天的数据状态变更量情况，无论过去多久，按同样规则对历史这一天的日志再分析，结果都不会变化，缺点是假如一个对象状态先发布正常，再被屏蔽，会在正常和屏蔽量的统计结果里各算入一次，各自结果量不能简单相加得到该日的回答总量。

还有一些统计需求，更适合使用基于日志的方式统计得到，比如要统计一天回答被修改的次数，只需在回答每次被修改成功时发一条日志，基于日志便可统计到。

在产品说明文档中，就需要说明具体的统计计算规则，比如使用哪个数据源的哪些字段，按什么公式计算，得到所需的统计数据。

3. 埋点采集，一般是基于日志的计算方式居多，那么日志里记录哪些信息，主要根据你要统计的指标、维度、最后需要的报表结果来定，理论上前期采集日志里携带的信息越多，后续想要增加一些维度指标时，就越不需要再动埋点处的代码，并且可以有历史日志现成的数据使用，但所需记录的信息太多也会造成日志量体积变大，甚至影响业务性能，比如社区用户发布一条回答时，假设你希望在日志中同时记录下发布当时的用户等级级别信息，而业务原本发布一条回答是不需要额外查这个用户等级数据的，如果为了你日志需要还做额外的查询，这就可能会影响业务执行效率和稳定性了，就要综合考虑这个信息的采集是否值得。

4. 前端埋点和后端埋点，举个例子，如果你要统计用户点击发布回答按钮的点击率，一般是前端点击按钮行为发送点击日志，页面按钮展示发送pv展示日志，然后点击量/展示量，就是点击率，这里就要前端埋点。

而如果你要统计回答发布成功量，那就要在后端发布回答的接口处埋点，因为只有执行发布回答的接口后端服务，才知道回答成功发布没有。如果你用的是点击按钮的前端埋点方式去统计，比如用户发布一条回答时，他在前端连续快速点了n次发布回答按钮，发送了n条点击日志，那你统计得到的发布数量是n，这就不准确了，实际发布一条回答，后端埋点会统计得到发布量就是1。

还有一些统计是要前后端都埋点，配合来用的，这时可能使用一个前后端统一定义的唯一TrackID，比如要得知有多少用户从A页面跳转到B页面，再有多少成功下订单，成功下的订单里，有多少是来自A页面的，就要在A页面就开始把跟踪ID带到B页面，前端埋点发送页面跳转日志，再由B页面将跟踪ID传给订单接口，再由订单接口执行成功时发出后端日志。

不知是否说的清楚。

来源：trijif 优酷 产品经理

关键字：产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！