十年经验产品经理分享:如何搭建一个行之有效的“数据闭环”体系

简介: 打造数据闭环体系,就是要完成数据对于产品产生价值的闭环,让数据驱动产品增长。本文作者从数据闭环的概念出发,结合具体案例,从目标、洞察、迭代、落地这四个方面对搭建数据闭环体系的关键要点进行了分析讨论,一起来看看~

随着互联网进入下半场,流量红利逐渐消失,一方面,企业开始重视如何通过数据来挖掘同一个用户的更多价值;另一方面,不管是产品经理、运营还是市场都开始通过“数据驱动”寻找新的增长空间。

01 数据驱动,在国内企业的落地中很“骨感”
在国外,有一个名为Instagram的照片分享软件,这个软件早期并没有火起来,后来他们通过数据分析发现了一个非常强硬的用户需求点,即“纯粹拍照并分享”。围绕这一点,他们对产品进行了大改版,并在较短时间内实现了用户数量快速增长,这是一个很好的数据驱动案例。反观国内,大一点的创业公司会优先考虑如何做概念,如何存活下来,像上述那样用数据实现业务驱动的很少。

对于数据驱动,很多人做到一定程度之后,脑海中会形成一定的方法论和体系,进而形成驱动流程和组织机制。大家也听了很多方法论,包括增长黑客等,貌似自己已经很懂数据驱动了,但是实际操作起来可能连“什么是事件属性这种基础的概念都不了解”,这是很多业务线同学普遍的现状。

另外,很多公司认为做数据驱动就应该有一个高大上的数据平台,这两年标签画像平台或者数据中台的概念比较火,它们真的能够实现数据驱动吗?不见得。目前,很多公司的数据质量非常差,数据驱动就更无从谈起,这是国内大中小企业普遍存在的情况。

早些时候,大家对“数据驱动”的理解是“报表驱动”。2016年、2017年的时候,一家处于C轮、D轮的深圳公司,该公司有1000多份报表,每张有10个Sheet,每个表格有20多个指标,大家可以算下一共有多少个指标,他们内部的数据团队都不知道哪些指标有用、哪些没有用。为了督促大家去看这些报表,公司还监控了邮箱。

“早前,我做数据产品和数据分析的时候,很多产品同学说所有的都要埋点,包括头像、点击次数等,他会问这些点真的有用吗?想好这些指标数据的目的了吗?这些都是十分有意思的现象和问题。数据驱动是一件好事,但在国内企业的落地中确实很“骨感”。数据驱动不是一个简单的工具,也不是多个分析师或者少个分析师的问题,而是整体的格局问题。“陈新祥在直播中提到。

02 从几个案例进行拆解
现在,很多企业都想实现数据闭环,其实闭环就是非常典型的方法论。那么,这个方法论究竟能不能解决问题?能不能在组织和团队里运行起来?背后是否缺失了哪些环节?在这里,陈新祥分享了一个国内的实际案例。

1.jpg

如上图所示,Phase 1是初定的观测指标,包括日活、PV、注册书、功能使用次数、收入、客单价、日活跃占比、新老用户占比、增长率、X转化率等。他们的CEO发现,虽然该有的指标都有,但就是因为都有才失去了聚焦。于是开始精简思路,把团队力量凝聚到一根绳上,Phase 3是最终剩下的两个指标。

当然,这是他们根据产品的情况以及公司所处的发展阶段做的取舍:当时公司不急着变现于是收入被拿掉了,日活做的数据没有太大作用于是被拿掉了,拉新也被拿掉了。他们觉得产品留存很好,在当下阶段团队已经做到能力范围的上限了,投入更大的精力也不会有很大的提升。之后,他们只留下了日活跃占比和日活跃参与度,并调整了内部的报表体系。

今天,很多C端产品要改版要升级,那么,在改版之前要搞清楚为什么要改?目标是什么?之后所有的工作都是以这两个问题的答案为导向。

以友盟+服务的客户为例,每一年都会提出很多新的需求,比如进一步提升产品粘性、进一步提升用户量等诸如此类,我们要做的是尽力满足他们,但不论对产品做什么样的功能升级,都要以客户的目标为主。

2.jpg

上图是非常典型的2B行业自上而下的流程图,大家要做的第一件事就是定一个目标,不要忽略这件事,它真的非常重要,因为不管是升级产品的功能还是其它,一定要十分清楚公司的KPI,这样才能决定产品最核心的KPI。

搞清楚这些之后,要跟横向团队配合好,还要跟下面的人对齐。2B 行业企业的目标非常明确,一般是提高付费企业客户量,这背后有产品的日活周活,以及新增注册客户数等。再往下就是产品板块,包括产品版本、功能模块以及跟其他产品的协同。

向上要跟公司目标对齐,横向要跟合作团队对齐,向下是具体的产品功能拆解。需要注意的是:定好目标,目标不要多,最好只有一个或者两个。

3.jpg

B端的产品比较复杂(如上图所示)包括官网注册、H5、注册账号、创建项目、集成代码、使用产品、留存日活、pro付费等,KPI拆解到了注册账号数、注册转化率、有效集成数、首次完成激活等。在这之中,有些目标需要自己做,有些需要跟别的团队协同合作。

定好目标后,一定要了解产品背后的数据质量。关于数据质量,公司内部、部门之间的指标定义各不相同,不过普遍存在数据不准、没有数据、数据脏乱差、易用性差等问题。如何解决?其实,数据中包含着业务需求,需求弄清楚了才会转化到埋点设计,埋点方案再转化为具体的研发。

随着产品功能迭代,还需要重新走一遍全部流程。在这个流程里,业务需求来自很多团队,包括产品团队、运营团队、市场团队等,橙色标注的文字是一个产品经理一定要重点关注的节点和事项(如下图所示)。

4.jpg

从业务需求到需求规范,一定要做统一收口,如果没有线上工具化的体系,可以指定一个人,让他做统一收口,收口完成之后要形成公司或者部门内部比较完整的指标字典和维度字典。与此同时,一定要对指标字典进行拆分,看看哪些是公共性指标(跨部门或者公司级别)和个性化指标。

有些公司需要这样的同步方式,再往下是具体的采集方案设计,前面已经拆分出了公共性指标和个性化指标,它们延伸出来就是公共埋点和个性埋点,公共埋点是非常重要的业务性指标,这个指标很长时间都不会变。再往下是研发口径,不管是公共埋点的事件规则、属性规则,还是采集时机,都要做统一管理,最后再进行验证。

在整个流程里,最关键的是要有专人做统一收口,基于对数据和采集的理解做分流,中间规范跟标准动作要规范,因为不论是新版还是新功能上线都要走这个流程。

5.jpg

这是一个视频类的案例,要针对具体需求设计数据采集方案,互联网领域比较流行基于事件和属性进行分类。相关人员可以把属性融到事件里,之后再去做限定,等到哪一天想看XXX视频的点击,基于属性可以直接看到。这是一个非常理想的体系,可以实现数据采集埋点的规范化。

在此基础上,还得针对两类事件做统一的设计和规划,浏览页面和功能交互是统计数据中最多的,如果浏览页面和功能交互没有规范化就会导致数据脏乱差。

为什么这么说?以手机淘宝为例,手机淘宝的终端有网页、安卓、iOS、小程序等,页面浏览和功能交互都有不同的部分,如果完全分开按照最糟糕的情况永远规范不好。

6.jpg

目前,一个比较好的解决方法就是把它前置,所有的功能在某一个页面的某一个位置,以一个具体的按扭呈现出来,并设置一个唯一的参数ID,再用事件和属性进行归类。这样一来,所有的页面和功能只需做一个埋点,所有页面的标记都可以用ID来标记。

不同终端都有一个ID是长期关系,后面都会用相同的逻辑和体系进行标注,只要维护好需求、事件命名,以及业务层级ID,最终采集到的数据质量是非常好的。

以友盟+服务的客户场景来说,比如在拿到一份高质量的数据之后,KPI在确定情况下进行了拆解,现在要做的就是希望团队里的人知道自己的KPI,KPI大屏就可以轻松解决这个问题。

同时,要把数据结果融入到团队的工作流程里去,比如可以在早上八点把团队最关注的东西发到邮箱,市场推广人员可以看到相应的报表。在上午十点的时候,产品经理可以登录后台看到更新的产品功能。

目前,由于疫情的原因,很多人在家使用钉钉移动协同办公, 如果某个人的KPI出现异常或者波动就会自动同步到群里,分析师会到后台分析异常原因。另外,团队运营人员在后台可以直接用运营弹框来组织活动,并对相关人群做触达并观看效果……

以上内容主要围绕数据驱动的闭环展开,包括目标、洞察、迭代、落地等各个环节,在这之中有一套标准的方法论,如果能把这套标准方法论体系化和产品化,可以极大的提升决策效率。

作者:友盟+产品专家,数据传承官 陈新祥

相关文章
|
1月前
|
项目管理
NPDP|产品经理的沟通协调能力:塑造产品成功的核心力量
产品经理的沟通协调能力对于产品的成功和团队的高效运作至关重要。只有具备了强大的沟通和协调能力,产品经理才能更好地履行职责,推动产品的发展和公司的业务创新。
|
6月前
|
人工智能 自然语言处理 文字识别
飞天技术观丨大模型如何真正在应用环节产生价值
大模型揭开了智能时代的序幕,其技术发展日新月异,创新成果不断涌现。可即便如此,最终不可避免地要回答一个问题:大模型如何真正实现商业化应用落地?
飞天技术观丨大模型如何真正在应用环节产生价值
|
数据采集 存储 运维
作为一线开发对数据治理的认知
数据治理的目的是为了让数据更加准确,降低后续数据清洗的难度,节约成本,加强把控,好处是说不完的,但这实际开发中所遇到的问题却比好处要复杂,你可能考虑到所有的问题,但却无法预估问题解决的难度。
172 1
|
Cloud Native 前端开发 IDE
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
本文作者将给大家提供一些简单的容易实操的方法,能够让所有人都知道什么是效能的提升,如何提升个人的效能,如何提升团队的效能。
1634 11
「技术人生」第10篇:如何做研发效能提升(即指标体系建设过程回顾)
|
运维 监控 Cloud Native
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力
434 0
《研发效能嘉年华:跨越敏捷——闲鱼敏捷转型之路》电子版地址
研发效能嘉年华:跨越敏捷——闲鱼敏捷转型之路
115 0
《研发效能嘉年华:跨越敏捷——闲鱼敏捷转型之路》电子版地址
|
敏捷开发 搜索推荐 架构师
|
人工智能 运维 监控
8 年产品经验,我总结了这些持续高效研发实践经验 · 研发篇
在产研全链路流程上,协同最大的目标就是团队信息的透明化,即在清晰目标的指引下进行团队信息透明的日常研发工作,助力项目/产品成功发布。基于此,研发过程是否行之有效就成为我们关注的另一重点要素。通常「研发过程」是指:代码到制品再到部署上线的全链路,这个过程是持续集成的重中之重。
652 0
8 年产品经验,我总结了这些持续高效研发实践经验 · 研发篇
|
监控 安全 Cloud Native
阿里产品专家:高情商的技术人,如何做沟通?
不愿沟通是固执,不会沟通是傻瓜,不敢沟通是奴隶。——德拉蒙德
阿里产品专家:高情商的技术人,如何做沟通?
|
敏捷开发 移动开发 监控
从用户扩张到技术更迭复盘社区的体系搭建
社区也借用了第三方数据产品——友盟+,不管是哪一家公司的数据产品,都会有对应的使用场景。在教育、医疗、金融等不同的行业,所用数据的使用目的都不同,用户分群而视之,如医疗行业是提高用户留存,金融行业进行网站优化、提高线索转化等,每个行业都有各自的数据优势。
从用户扩张到技术更迭复盘社区的体系搭建