数据人学习平台上线了:www.shujurenclub.com
作者介绍
@图图
BAT数据产品经理
专注数据产品、持续学习中
“数据人创作者联盟”成员
从做数据产品开始,自己的日常工作就被埋点占据了大部分,到后面做平台类数据产品之后发现埋点问题依旧占据很多精力且治理困难,写这篇文章也是跟大家讨论讨论自己做埋点治理的心得以及深入剖析下为什么埋点质量这么难保障。
做埋点时间长了,越来越觉得埋点并不像自己想象的那么简单,仅仅是开发在自己要统计的业务场景下写埋点代码打包上传统计数据就完成工作,从最开始的埋点需求规划再到最后数据上报只要有一个环节有坑就会影响数据准确性,而数据准确性估计是每个数据人工作中必须要面对的难题。下面简单聊聊自己遇到的坑,这些或许仅仅是表述了现象,至于导致此现象发生的本质相信就仁者见仁 智者见智了。
01
埋点需求混乱且缺少管控
产品和运营作为埋点需求的常见提出方,当新功能或活动上线时会提很多埋点需求,数据产品在这个环节如果对埋点需求没有明确的提需规范和把控,就会导致埋点需求爆炸,对于开发和维护成本都是压力,并且后续做数据分析的时候经常会发现数据不可用或数据不准确,那其实后续排查问题的成本非常大,所以数据产品一定要对埋点需求有全局把控。
1
明确埋点要统计哪些指标
数据产品在评审埋点需求的时候很重要的一点就是:明确埋点要统计哪些指标。埋点统计是服务于指标的,如果对埋点需求没有管控放任提需,经过几个版本的迭代就会发现埋点维护很难,而且这样也能反推运营和产品思考自己到底关注哪些核心指标,对后期的数据统计和复盘都是有帮助的。
2
明确埋点提需规范
埋点需求规范的价值是帮助业务方和数据产品拉齐对即将开发的埋点认知一致,所以在设计埋点提需规范时不仅仅要让业务方标明要统计哪些指标、事件如何规划、触发时机,最好能写出每个自定义参数的触发时机、参数打在哪个层级、是否需要透传等,对于刚起步做埋点治理的阶段可以先将精力focus在提需规范的设计和落实上,划重点:埋点提需规范越详细越好,可以帮忙拉齐各方对埋点的认知。
3
埋点需求评审会及设定需求接口人
埋点需求评审就不具体展开了,大体说就是将业务方、开发、测试、数据产品等组织起来对埋点需求进行评审。我想多说说需求接口人这个角色,进了大厂发现需求接口人很重要,没有接口人的话仅靠数据产品跟业务对接在大体量和复杂业务场景的公司里是不现实的,所以接口人的定位是埋点需求master甚至是数据需求master,划重点:建议接口人可以考虑经常对接埋点需求的业务或是有开发背景的业务方,这样沟通起来会方便一些。
02
埋点设计环节缺少整体性思考
规划埋点是数据产品的基本工作,但真正能做好埋点规划很难,我觉得这个环节的痛点在于:很难以全局视角规划埋点并且具有可扩展性,所以为了后续的可扩展性,我简单列几条可参考的tips:
1
埋点设计要具有简洁性
这里的简洁性是指同类场景下的埋点是否能合并成一个埋点规划,比如“点击支付按钮”事件,该事件在很多页面都可以触发,那么就可以把这个事件规划为一个埋点,在不同的页面点击时将页面名称或页面ID作为参数传递,但这些还是比较初阶的埋点设计方案,当很多业务属性以参数形式传递时,如何管理及规划这些参数,让数据RD看到埋点日志时很容易就能理解这条埋点携带了哪些信息,那么就引出来我要讲的下一点:
2
埋点设计要具有规范性
其实规范性这个词很宽泛,我们通篇也都在探讨如何基于埋点治理的痛点制定规范。上面讲到我们如何管理埋点日志里的参数,我觉得可以按照性质和层级给这些参数进行个简单划分:
这里的层级指的是埋点日志的json层级,如果能做好json层级的划分那么对于不同角色的RD可以按照自己关注的参数去解析,大大降低了解释成本。
当埋点设计形成了规范,那么其实也完成了埋点最难的高度抽象的部分,接下来就是基于抽象好的规范甚至是数据模型来复用到后续的埋点规划中,抽象的思路可以先关注重点场景:先设计核心指标有关的核心点位或者场景复杂的点位。
3
埋点设计要具有可扩展性
埋点设计的可扩展性与上面的规范性密不可分,当规范建立好数据产品要思考是否具有较强的扩展性,还有后面规范的新增和变更该如何管理和维护。
要知道埋点不仅仅只是服务于指标统计,想要全面的规划埋点还要设计分析产品性能、使用体验的埋点,比如上报启动时间、崩溃事件、页面加载时间等事件。
03
埋点开发不规范
这个问题也很有意思,数据产品经常有个疑问:为什么我规划好了的埋点,实际开发或上线后根本不符合预期。这个环节共设计到两个角色:数据产品和埋点开发,那么到底是哪一方在沟通理解上出现了问题呢?
大家发现了吗,当埋点场景复杂时,由于两个角色的侧重点不同很容易会出现gap,有人问有什么好的办法去规避吗?其实除了上面讲的,只能不同角色补齐自己的短板,还有就是两方一定要多沟通,埋点开发在埋点评审时要思考不同实现逻辑和异常场景是否会影响埋点上报,在开发埋点之前尽量把问题暴露出来。
04
埋点验收不够全面
埋点验收环节作为埋点上线的最后一道保障,也是很容易踩坑的。具体的现象不多说,只说如何在验收环节尽量不踩坑:
(1)验收是否多报
(2)验收是否少报
(3)验收是否缺参数上报
(4)验收上报参数是否符合预期
(5)验收上报为空日志的比例
(6)验收上报不符合预期日志的比例
除了上面的验收重点,验收方式一定要手动验证+平台自动化一起配合,最好能进行一遍回归测试,多方式进行验收。
05
欠缺埋点生命周期的管理
做埋点治理和数据治理的小伙伴应该深有体会,当缺少生命周期的管理一味放任熵增,后续治理的成本实在很高,所以埋点生命周期的管理必不可缺。简单来说要做好后续埋点梳理、埋点瘦身、埋点升级的工作,定期统计一段时间内低频上报的埋点和这些埋点相关指标、报表的访问量,以此为依据开展埋点生命周期管理工作。
说了这么多,越写越觉得想埋点想不踩坑对数据产品的要求实在很高,不仅要有需求管控能力、数据抽象能力,技术背景,还要有多部门协调能力和全局把控能力。所以本文也只能大体讲讲这些关键环节,但估计也是日常困扰大家比较多的问题了。
相信有此经历的小伙伴们看到文章应该很有共鸣,欢迎留言交流~如果有更好的想法欢迎一起讨论学习~
▊《大数据实践之路:数据中台+数据分析+产品应用》
林泽丰,许秋贵,陈斌,陈丽媛 著
每个企业都会面临各种各样的数据问题,有数据质量的问题、数据获取效率的问题、数据应用价值的问题等。
本书首先介绍数据中台的建设,确保数据的质量,为企业的数据质量体系建设提供坚实的基础;然后,进行深入业务的分析探索,介绍如何从数据分析角度更好地赋能业务发展;最后,介绍数据应用,解决数据获取效率的问题,并把一些分析思路和业务策略沉淀为数据产品,从而更好地将数据应用于业务。本书结合多个大型互联网企业的实际项目案例,让读者真正掌握数据产品经理这个新兴职业的必备技能和核心能力。
(京东满100减50,快快扫码抢购吧!)
如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连
热文推荐
Kubernetes生态系统与演进路线
吃透HTTP原理,建立安全的HTTPS网站
如何在AI工程实践中选择合适的算法?
书单 | 做数字化转型,离不开这10本书!
▼点击阅读原文,查看本书详情~
本文分享自 博文视点Broadview 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!