作者:刘煦萍
『数据表明这次xxx的优化效果明显……』总结会上总监老K的一句话突然引起了小L的注意,数据表明?这些数据从哪来的?项目过程中自己好像没有关注这块,是从开发那边直接获取的吗?还是有什么工具?…会后小L将一股脑的好奇和疑问抛向Q姐。只见Q姐不紧不慢喝了口茶,说道:『我们通常通过客户端埋点来收集数据,然后将收集的数据进行分析并呈现出来』;『啊!?客户端埋点收集数据是什么意思啊?』小L一头雾水的问道,『给你举个例子吧,诺,你看,比如你想知道昨天网易新闻客户端里有多少人点过发现按钮,一种很直接的办法就是在发现这个按钮做埋点事件,当触发后就会被记录下来,然后就可以用作统计了』Q姐接着说,『杭研有相应的统计支撑部门,他们会将这些数据进行处理并展现在平台上,便于查看。』
听到这小L似乎明白了,同时又陷入了另外的问题,如果是这样的,那么每个版本中都可能会有数据埋点工作,版本中的数据埋点工作是怎么运转的呢?这些问题似乎只有小L自己去找答案了。经过一番打听,了解到目前版本的埋点行为由需求owner主动发起,运营组的一位同事进行补充。同时也存在几个问题:
1. 有时候会出现未提埋点需求的情况,待上线后要查看相关数据时才想起,此时也只能等下个版本再进行埋点。
2. 由于不同的人可能会在同一功能不同版本上交叉负责,有些交互上的变化需要埋点数据同样做更新,但会由于信息的不透明和未及时沟通而导致例如:看到的数据其实是另外埋点的数据,前一个人的漏斗分析失效等这样那样的问题。
3. 埋点数据无测试和验收环节,需求owner们等版本上线后去查看相关数据,此时如果发现有问题,只能等下个版本再更新。
小L一边用笔写下这些问题,一边嘴上还说着『看我怎么逐个消灭你们!』
问题1、2有个根本原因就是对数据埋点的重视程度不够,由于不是每个需求都有埋点工作,所以这个非必选项在意识不够的情况下容易被忽略。可是需求owner怎么会不重视数据反馈的实际效果呢?又经过一番摸底后才知道,原来很多人是没有直接的数据权限,那么前面的疑问就自然消失了,要解决的问题或许就变成了:1.提高大家对数据的重视程度;2.提供大家可见的数据;找到了问题,方案就不会太远了,小L想着想着不禁的脸上露出了灿烂的笑容。
再看看问题2,除了刚才上述说的原因外,还需要解决埋点数据透明性的问题,整个系统的埋点数据如果是公开透明的,那么每个需求owner就可以方便的查看他本次所改动的部分之前是怎样的情况。然后有变化随时更新,大家一起来维护这张表。
问题3需要跟测试和开发们沟通下是否有好的办法,经过一番沟通,好的是我们可以在发布前验证埋点数据的有、无和对应属性的正确性,不好的是目前暂时无法验证数据的精准度,就是用户在客户端触发了事件我们可以验证事件是否有以及是否对,但还不能精准确认用户操作的次数和后台显示是匹配的,小数据可以验证,大数据就难落实了。这个我们可以逐轮迭代进行完善。
小L将想法跟相关负责人沟通后,很快决定召开一次埋点培训/动员会。目的很清晰:1. 提高大家对数据埋点的重视程度;2. 解决大家看相关数据的问题;3. 建立数据埋点的整个流程。大会也就分为三部分:
1. 领导讲话,目的在于提高大家对数据埋点的重视程度。
2. 介绍埋点业务知识和数据考察核心指标等,用于让大家了解我们常规考察的核心指标是什么。
3.
介绍数据埋点工作流程,在整个版本过程中有哪些环节以及如何开展。前面两点就不多介绍了,第三点做个介绍供大家参考(请见下图)。
数据埋点工作在整个版本过程分为三个阶段:计划、执行和验收阶段:
计划:需求owner在确定需求同时提埋点需求,并根据埋点标准格式(根据标准模板)提交指定同事及统计组同事进行初步review,用于确认埋点数据的格式以及合理性,比如有些事件可以做合并,将多个事件转变为一个事件多个属性等。指定同事确认没有问题后提交开发进行确认和埋点。
执行:各端开发根据已确认的埋点需求文档进行埋点;
验收:分为三步:
1. 在测试阶段,开发会提供埋点debug包,需求owner可以通过触发事件然后界面显示所被触发的事件进行简单的验证;
2. 上线前,指定同事会通过平台查看埋点数据的情况,做二次确认;
3. 上线后,需求owner会观察线上数据是否有异常;
会后小L高兴的告诉Q姐整个过程,只见Q姐还是不紧不慢的喝了口茶说道,『恩,做的不错!是个好的开始』,『好的开始?』小L疑惑的看着Q姐,『没错,是个好的开始,现在是给大家了一个guideline,具体实施的时候需要仔细跟进,看看存在什么问题,怎么进一步优化,真正执行的时候你会学到更多,加油吧!哈哈』Q姐笑着走开了。
网易云大礼包:https://www.163yun.com/gift
本文来自网易实践者社区,经作者刘煦萍授权发布