极客时间已完结课程限时免费阅读

22 | 产品经理需要具备哪些基本的数据能力和意识?

22 | 产品经理需要具备哪些基本的数据能力和意识?-极客时间

22 | 产品经理需要具备哪些基本的数据能力和意识?

讲述:邱岳

时长13:01大小5.97M

极客时间的专栏读者你好,我是邱岳。
在前一段时间里,我们利用了大约七周的时间,一起探讨了产品增长相关的内容。希望这个模块的内容可以给你的工作带来一些启发。
上一季有一些读者朋友留言,谈及了数据对产品经理的重要性,希望可以看到数据产品经理相关的内容。所以,从今天开始,我们会花几周时间,谈一谈产品经理的数据分析能力和数据意识。
数据是产品经理最忠实的伙伴,它是理解产品现状的基础,是做出产品抉择的依据。数据分析能力通常也是产品经理技能图谱中最显著的内容。
我们在这里就不浪费时间,专门花费篇幅说明数据对产品经理的重要性了,不过想要特别提到的是,产品经理的数据分析能力和数据意识,和数据产品经理的技能树还不是一码事。所有的产品经理都需要有数据能力,但并不是所有的产品经理都会负责数据产品。
由于专栏的篇幅有限,我们没法像教科书一般分门别类、循序渐进。所以,在这个模块中,我会从与数据相关的场景出发,尽可能多地覆盖相关的知识点。希望这些内容能够帮助你理解数据能力在产品设计中的价值和作用,并启发你继续深入训练和学习相关技能的兴致。
我们从一个场景开始数据分析的旅程,这也是我们做产品和运营每天都有可能会遇到的情况:某天早晨,你例行看数据时发现,昨天产品的流量环比骤降 20%,这时候,你该怎么办?
这也是我曾经在面试中使用过的题目,面对这样的情景,一个人的反应很大程度上可以代表他整体的产品素养。

1. 养成数据走查习惯

在我们开始分析这个问题之前,需要先注意一点,就是刚才提到的“例行看数据”。作为产品经理或运营,看数据应该是每天的必修课,这也是整体了解产品健康程度最有效的手段。
我每天睁眼的第一件事情就是掏手机看数据,因为全天的数据统计有几个小时延迟,早晨醒来的时候,刚好可以看到前一天的数据情况。
这时我们可以通过一些第三方数据工具,看一下宏观指标,比如日活、用户新增、留存等。另外也会看一下收入情况,比如总收入、总订单笔数等等。
这个过程基本不会超过十分钟,一般来说看完这些数据我才会起床,很有仪式感的一件事。这是每天看数据的第一阶段。
第二阶段是我到办公室之后打开电脑,第一件事情还是看数据。这个时候我会更多地利用我们自己的数据工具,看得相对微观一些。比如我会看各个渠道的用户数据,以及分时数据(就是每小时的情况),收入部分则会关注具体的收入构成以及变化。
另外,我还会关注一些业务数据,比如 Readhub 会看一下昨天收录和筛选的资讯总量,资讯的聚合情况;抽奖助手则会看一下抽奖发起量,参与人次等等。这个过程通常不超过半小时,抽个空就可以查阅完毕。
如果你需要负责的产品线很多也没关系,我在之前的工作中,由于团队负责了很多产品线,所以我可能不会每条线都看得很细,而是每个产品关注几个宏观指标。如果有显著波动的话,我会给具体的产品经理留言,等他上班后,会把细节和原因分析一下告诉我。
只有养成这样的数据走查习惯,在出现“流量环比骤降 20%”这样情况的时候,我们才有可能第一时间发现、分析以及做出反应。
另一方面,作为产品经理,我们也应当保证自己是第一个获知产品健康动态的人。如果别人发现了产品的数据情况,来问我们的时候,我们什么都不知道,一头雾水,就会影响其他人对我们的信任。
相反,如果每次产品数据有波动,别人问过来你都知情,而且可以反馈具体的原因,甚至还有应对措施,久而久之,也会建立起团队中对产品经理的信任。

2. 建立数据体系

“工欲善其事必先利其器”,要看数据,我们需要先建立产品的数据体系。我们在增长相关的分享中曾经提到过,数据体系有几种实施策略,可以完全自建,也可以利用第三方数据工具。
第三方工具(比如 GA、MixPanel、Growing IO 或 Umeng,对于小程序来说,可能是微信的官方后台或阿拉丁等等)功能丰富、性能稳定、上手比较快,而且能搜到很多相关资料;但是,它们的分析维度相对受限,只能对一些相对通用的行为数据进行分析,比如日活、月活、次日留存等。
当然,如果我们可以深入研究一下工具本身的配置和能力,再配合一些复杂的筛选和区隔功能,也可以对用户和行为做出一些细分。
但如果需要与具体的业务相结合(比如销售转化率、客单价等),或者更加细致的分析工作(比如相同页面、相同功能,但不同形态的行动点转化率差异),就需要做一些个性化的埋点工作。
有些第三方工具有一些机制,它们支持通过简单的编码对自定义事件进行追踪和记录,比如 GA 的事件记录和自定义用户维度等,它们也非常强大,但稍微有一点门槛,你可能需要专门花费一些时间了解。
另外,我们也可以通过在页面路径上做一些手脚,曲线实现类似的功能,比如在 URL 里带一个不影响实际使用的参数,去区分不同路径等等,不过后者不太适合做系统性地分析。
我在这里说一句题外话,第三方数据工具的教程和文档也可以成为我们学习数据分析的参考材料。你可以从中学习到应当关注哪些数据维度,每个数据维度的详细定义,以及为什么关注这些维度。如果你可以长期使用某个数据工具,观察它的升级和变化也很有趣。
比如 GA 对于用户的定义从流量到独立访问者,而如今更是与移动端对齐,更新为“用户”这样的指标概念。伴随着概念的变迁,GA 也不断推出留存分析、用户轨迹等“以用户为中心”的分析功能,这从另一个角度也佐证了,互联网从粗放的流量时代到精细化用户时代的变化。
第三方数据工具虽然强大丰富,但面对个性化业务指标时会有些力不从心。这时就需要我们自建数据体系,将行为和业务指标结合起来。行为数据可能是通过页面上的日志系统,而业务数据可能来自自己的数据库。
建立数据体系通常需要专业的数据产品经理或数据工程师对业务进行抽象分析和系统规划,需要前后台工具,以及专门的软硬件支持。
初期可能会会有一个相当长的阶段,我们自己的工具平台可能远不如第三方平台丰富、易用和强大。这是很正常的现象,在这个过程中一定要有大局观念,咬牙尽可能多地使用自己的数据工具,只有这样才能帮助自建数据体系,快速度过尴尬期,发挥最大效应。
还有一种情况是,可能在很长的时间内,我们没有足够的资源去充分优化和迭代自建数据工具使用体验,那就需要将第三方工具和自建数据体系混合使用。事实上,在很多创业团队,包括我自己所在的团队,都会使用这样的方案。
我们会使用 GA、小程序的官方统计工具等第三方数据平台,也会使用自己的日志系统和业务数据系统,通过 Tableau 进行各种维度的交叉分析。最大化地提高数据资源的投入产出比。

3. 数据仪表盘视图

不论是使用第三方工具还是自建数据工具,我们都应当有自己的“数据仪表盘”,也就是俗称的 Dashboard。
这个仪表盘有可能是第三方工具默认提供的(比如小程序数据统计工具),也可能是通过第三方工具自定义的数据视图(比如 GA 的自定义 Dashboard),也可能是自建数据平台的前端视图(比如我们是通过 Tableau 来构建业务数据的分析视图),还可能是从各个数据源拉取数据之后,在本地构建数据视图(比如用 Excel)。
(图来自网络)
不论哪一种,它们的目的都是保证数据阅读的效率,尽可能全面而详细地看到整体数据状态和变化情况。通常看上去就是大量的曲线、柱状图、饼图、表格、散点图以及直接放数字等等各种形式。
这里我们不展开分析各种表现形式了,只是我们要注意一件事情,就是所有的数据图示究其目的,都是为了尽可能直观地展现对比。单个数据指标是没有意义的,只有在进行横向或纵向对比时,它才有意义。比如文初我们提到的流量骤降的场景,就是基于流量指标的环比。
基于此,我们就可以从对比出发,去设计我们自己的日常数据仪表盘,包括横向对比(不同渠道、模块的拆解,我们后面会详细说),纵向的对比(按不同时间粒度观察环比、同比),以及逻辑上的对比(比如观察用户新增与留存数据的趋势,通常因为运营活动带来大量新增时,留存会略降)。
总之,我们不要被动地依赖已经设计好的仪表盘,尽可能根据自己的业务和阶段性目标做一些个性化订制工作,提高数据阅读的效率。

4. 总结

关于数据意识和数据能力的第一次分享,我们就先到这里。我们从一个场景出发,介绍了数据走查习惯以及相应的日常数据体系建设。基于这些内容,在下一次的分享中,我会介绍对于“流量骤降 20%”这一事件的分析思路和相应的数据项。
你平时是否有观察数据的习惯呢,你会关注产品的哪些指标?欢迎在留言中分享交流,我们下次再见。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 11

提建议

上一篇
21 | 增长黑客的阴暗面
下一篇
23 | 突发式流量数据暴跌,产品经理应该如何应对?【分析篇】
unpreview
 写留言

精选留言(11)

  • Novelty
    2018-10-08
    尝试回答下二爷的面试问题(坐等周三进行自我迭代) 针对产品流量环比下降20%事件,首先我会确定它的统计口径,标准是什么,保证分析基本框架的正确性。 其次不能孤立的看待数据,我会调出近7日环比数据,以及同比数据,以此决定分析时间维度的长短。 然后对问题进行逐步拆解,首先拆解为外部因素,内部因素。外部因素重点查看竞品动作以及社会重大事件是否影响到流量。再对内部因素拆解为被动型原因,主动型原因。被动型原因主要看是否由于系统问题造成闪退,白屏等从而使流量流失。主动型原因再拆分为运营因素与产品因素,运营因素重点查看是否因为运营策略的变动影响了用户行为。而产品因素,重点通过数据分析用户行为,查看流失用户此前的产品访问数据,分析他们的产品使用地图,从而查看每个节点上流量下降的环比数据,找出问题点。同时对剩余用户的产品使用数据进行分析,找出这两者的不同点以此更加准确的锚定问题点。 最后按照此前拆分问题的维度将其进行归类,根据不同的问题类型提出假设,制定方案,跟踪数据,再进行迭代。
    展开
    共 1 条评论
    45
  • 听天由己
    2018-10-08
    说起数据,每个人都有很多困惑与好奇,二爷提供的反向学习方法值得借鉴。 扪心自问,有多少人愿意花时间去研读这些已经成型的文档或是手册呢?就像微信小程序官方开发与设计文档,这两年来真正做好的小程序并不多见。虽然有很多坑,也那是宝贵的经验。 快速学习最好的方法就是通过问题,一步一步寻找方案,并且从实践中回顾总结。再次感谢提醒。
    展开
    5
  • Dylan
    2018-10-08
    自己现在刚入职,做的第一个业务有关渠道新增,每早关注的就是该渠道的新增数据以及渠道总新增,同时对照着埋点的行为数据、留存数据、涉及页面的大盘数据一起分析。当下就准备对一个按钮进行迭代。 然后在熟悉业务的过程中,数据也是我在逐步由微观到宏观去学习的,通过各个分类的点击、用户使用时长、整体大盘,我通过数据理性认识产品。
    3
  • 听天由己
    2018-10-08
    说来惭愧,每天例行看数据这几年都没有做到,早上我一般会总结工作,列出大事,开始工作。每周我会根据产品线进行汇总,长期都是利用系统后台管理来实现数据记录,导出 Excel 表格后另行分析。 而后,采用了第三方统计工具,增加了更多维度的了解与认识,只是还是处于初级阶段。 以前还在忙活赛事时,印象最深刻的就是,我几乎认识在平台上注册的所有业余网球选手,大大小小几十场比赛,每次报名、排阵、录分、统计,来来回回就是那些固定人群,作为平台方,最关心的就是注册用户数、比赛数量、报名情况与赛事进程,限于条件所限,人工操作比系统操作要更快捷。 那时的自己边做边学习,却总是跟不上变化。
    展开
    3
  • 刘容Caroline
    2018-10-08
    做产品不重视数据,路边卖包子都卖不好
    共 1 条评论
    3
  • charlesybb
    2019-08-29
    目前产品经理的工作,逐渐从端体验到链路闭环发展,研发也是如此,很多研发尤其是后端研发,会在设计系统加购的时候,建很多表存储数据,建议产品学点sql,取数和分析数据会非常方便,查问题也会非常方便,项目初期这样会非常爽
  • 一朵蔷薇花
    2019-07-20
    我们之前是用友盟在监测app的数据
  • 宝宝
    2019-05-27
    今天第一次在二爷下面评论(分享),所以我想尝试回答一下我每天最胆战心惊的工作环节,也就是当数据下降时我该采取怎样的行动。 1.访问运营人,排除外部的不可控因素,首先询问是否进行正常推广,排除人员调动因素如离职调岗;其次就是是否正常进行推广。 2.排查内部因素,第一排除是否出现bug性能等问题,导致流量折损。 第二如果不是因为bug等性能问题,则排除功能流程问题,利用第三方数据工具或分析平台,分析当日的流量的入口,年龄及意向,形成用户地图,从流量入口到落地页每一个路径进行分析,尝试推断是哪一个页面流程出现问题再针对该页面进行优化。 以上就是针对日常数据问题的一些处理方式,处处入行,想请问二爷及各位PM平时针对自己产品的业务都有哪些建模方法,有无典型案例或工具。
    展开

    作者回复: 不得不说,好像还真没有可以通吃所有产品形态的建模方法,但总体来说,都是根据用户在产品中的路径和生命周期,找到关键节点,然后建立模型的。

  • 和小胖
    2019-05-15
    另外看数据真的蛮重要的,对于产品如此,对于开发更是如此,开发产品一般也会接入一些bug统计的sdk,但是很多人就是接入了,然后就没有然后了。这个其实也需要时常去看,可能因为某个bug在某些机器上就会出现,但是这些影响对于整体业务数据来看可能影响不大,但是在bug统计平台就比较容易看出来,所以,对数据敏感,时长看数据,也是开发的事儿。
  • 和小胖
    2019-05-15
    自建数据平台还是蛮重要的,因为第三方做的再好,可能还是没法满足一些需求,第三方之只能够满足一些常见的需求,另外自建数据平台也是对数据的一种备份,不然数据都给到了第三方,万一某天第三方数据没了,就很尴尬了。其次是可以用自己存储的数据与第三方的数据做对比,如果差别很大,那么一定是其中一方的统计有问题。 对于流量骤降20%,原因还是挺多的,理论上产品直接把这个问题抛给开发就好了,但是一般产品不会这么做,会先自己去做分析,到底是不是开发原因,万一是运营或者市场减少了投放,或者是由于自己投放的某一渠道出了问题,或者是突然用户群体发生了变化等类似这样子的问题,那么这种问题开发一般是查不出来的,也只有产品去跟其他部门协调才能查出来,如果都不是这些原因,那么就真的该交给开发了,可能真的是程序出了问题。
    展开
  • 小今今
    2018-10-11
    我一个测试都要每周走读两次数据(只要公司权限允许),何况产品经理呢。