什么是数据产品经理_数据看板搭建攻略，数据产品经理必看

在后台中&＃xff0c;数据面板能够直观反映出业务变化&＃xff0c;并有助于决策层发出业务调整与决策。那么搭建数据看板的时候&＃xff0c;要如何搭建呢&＃xff1f;又有哪些注意要点呢&＃xff1f;

产品背景分析

1. 什么是数据看板

数据看板一般用作后台系统的首页&＃xff0c;主要呈现公司当前业务相关或运营管理相关数据和图表&＃xff0c;方便公司内部人员实时了解公司内情&＃xff0c;掌握业务发展情况&＃xff0c;并能够对数据变化做出业务决策。

2. 谁在使用数据看板

数据看板是公司内所有人员都会关注的&＃xff0c;无论是公司高层还是基层业务操作者都会关注相关的数据指标。只是不同的角色的需求不同&＃xff0c;如下图&＃xff1a;

不同的角色的默认看板页面是不一样的&＃xff0c;要设计多份看板页面&＃xff0c;至于不同页面是否可以互通&＃xff0c;这就要取决于公司业务数据是否属于商业机密&＃xff0c;牵扯到RBAC权限模型的设计&＃xff0c;这里就不多赘述了。

设计看板的前置条件——报表设计

设计看板可不是脑子一热就开始画原型了&＃xff0c;那样得到的看板是不切合实际的&＃xff0c;而且也不一定准确&＃xff0c;尤其是对于数据大量且复杂的业务而言&＃xff0c;需要先设计好报表。数据看板中有不少数据是需要后台去实时计算的&＃xff0c;在数据量太大的情况下&＃xff0c;筛选条件和统计项较为复杂时&＃xff0c;图表加载速度会变慢&＃xff0c;也会耗费大量系统资源。而如果先设计好数据报表&＃xff0c;在数据看板中&＃xff0c;查看图表的速度才不会收到影响。

不要急于数据可视化的设计&＃xff0c;需要数据报表所呈现的数据经过多次测试没有问题&＃xff0c;再经过至少一轮的迭代优化&＃xff0c;再着手进行可视化方案的设计。

数据报表的设计需要经过以下流程&＃xff1a;

1. 构建分析体系

• 面向业务结果的分析

b端产品经理不同于c端&＃xff0c;业务是一切产品设计的核心&＃xff0c;必须围绕业务进行产品设计。首先要明确分析目的&＃xff0c;并进行业务诊断&＃xff0c;最重要的是打通分析链路。

例如要分析利润曲线&＃xff0c;与利润相关的数据有利润率、在架率、产品种类、报价策略、市场行情变动等

根据公司具体业务不同&＃xff0c;明晰哪些是需要重点关注的&＃xff0c;哪些是可以暂时搁置的&＃xff0c;特别是要跟业务团队多沟通协调&＃xff0c;共同商议出一个分析框架。

一般可采用枚举法&＃xff0c;列举可能干扰到核心业务数据所有因素&＃xff0c;再一一排查。

• 面向生产过程的分析

公司不仅要求分析业务结果等业务强相关数据&＃xff0c;生产过程关系到每个人的工作效率和工作成果是否达标&＃xff0c;生产过程同时也是对人员kpi的考核。

如对销售的拜访客户数、销售线索获取数量、签单客户数&＃xff0c;贡献利润占比等&＃xff0c;对客服的工单处理数量、客户评分、分钟会话数量等&＃xff0c;该部分分析主要根据使用者的操作记录产生数据。

2. 定义观察指标

• 进行维度下钻

定义好分析框架后&＃xff0c;要进一步确定观察指标&＃xff0c;主要是对观察维度进行拆分&＃xff0c;逐渐细化&＃xff0c;只有在更精细的维度分析数据才最有可能得到准确的答案。

比如在架率又可细分为日间在架率和夜间在架率&＃xff0c;还可继续细化为某某产品在架率&＃xff0c;甚至可以细化到业务员王二在日间12:33误操作某交易量极大的产品&＃xff0c;造成利润损失。这样就打通了从业务结果——生产过程的分析链条。

又比如报价策略有可细化为具体sku的报价问题&＃xff0c;该数据又可关联到上游供应商近期内价格调整频繁&＃xff0c;而报价策略未结合该特点导致该产品报价过高/过低。

维度细化的过程中&＃xff0c;可能会逐渐拆分为一级指标、二级指标……n级指标&＃xff0c;但并非拆分中的每一个维度都要作为观察指标。是否作为报表使用要结合公司业务特点并且和业务部门多次沟通协调达成共识。

在维度下钻的过程中确定哪些维度是需要进行统计的&＃xff0c;哪些是不需要用到的。

• 统一数据口径

数据口径指的是对于数据的定义&＃xff0c;如果系统内部统计口径不一致&＃xff0c;就会导致业务分析出错。如果不对数据口径进行清晰的定义&＃xff0c;开发人员在调用数据时可能会直接采用已有的口径&＃xff0c;这个已有统计口径不一定符合当前数据指标的需要。

产品人员应该单独书写一份关于数据口径的定义的文档&＃xff0c;并上传至系统内部的文档共享系统&＃xff0c;方便业务人员随时查阅。如果系统允许&＃xff0c;尽可能与业务部门达成共识&＃xff0c;形成一套标准的数据口径。

• 定义统计频次

确定好需要统计的数据维度形成观察指标后&＃xff0c;要对观察指标分类处理&＃xff0c;有些指标属于关键性因素&＃xff0c;有些指标属于次要因素。有些指标单位时间内产生的数据波动较大&＃xff0c;统计频次可能要到分钟级。而有些指标数据波动较小&＃xff0c;可能一天只有几次变动&＃xff0c;统计频次可设定为小时级。

3. 设计呈现形式

一开始的呈现形式以简单、好调整为主&＃xff0c;不必急于线上化&＃xff0c;也不必追求酷炫的交互效果。严格遵循mvp原则&＃xff0c;用最小功能集合去迭代产品。

报表在设计初期必然面临指标的频繁调整&＃xff0c;以及数据不准确&＃xff0c;统计范围需要变更等种种问题。初期可采用系统定时通过邮件发送报表&＃xff0c;报表的形式可以是一张简单的excel表格&＃xff0c;这样先试用一段时间&＃xff0c;确定要分析的数据字段、监控指标等没有问题后&＃xff0c;再着手进行线上化的设计。

确认好线下的报表迭代优化完毕后&＃xff0c;设计线上化的方案&＃xff0c;一般考虑以下几个方面&＃xff1a;

• 默认查询时间&＃xff0c;统计具有延时的特点&＃xff0c;有些数据统计必须等待订单完成才能纳入统计范围&＃xff0c;比如默认查询时间定为t-6至t-2
• 排序规则&＃xff0c;默认按照哪一项数据排序
• 筛选项设置&＃xff0c;哪些数据选项需要筛选
• 统计项设置&＃xff0c;哪些数据需要合并统计
• 其他极端情况考虑&＃xff0c;数据极限值&＃xff0c;最大时间范畴&＃xff0c;取数为空时的处理等等

大致的形式如下&＃xff0c;但在实际业务中数据远比这个复杂&＃xff1a;

4. 复盘报表设计

报表线上化固然有其优点&＃xff0c;方便、快捷&＃xff0c;效率高。但是也存在一些弊端&＃xff0c;比如不够灵活&＃xff0c;excel表格可以方便做成各种你想要的数据透视表&＃xff0c;而线上只能固定其中的几种。线下还可以采用任何关联要素利用vlookup进行匹配&＃xff0c;线上则已经固化了分析指标。

因此&＃xff0c;产品上线一段时间后&＃xff0c;要及时复盘功能是否好用&＃xff0c;是否得到认可。

• 使用率&＃xff1a;可通过数据埋点看该项功能的使用率&＃xff0c;使用率不够要和业务部门沟通问题&＃xff0c;及时迭代优化
• 观察是否实现最初想要得到的目的&＃xff0c;分析链路上是否还存在障碍
• 用户满意度: 与业务部门沟通&＃xff0c;看使用过程中有什么不方便的地方&＃xff0c;效率方面是否还可以得到提升

数据看板的设计

当数据报表完善之后&＃xff0c;那么实现数据可视化也就非常方便了&＃xff0c;效率是b端产品的核心&＃xff0c;设计看板也不应该花费太多时间在交互体验上。这里主要满足以下几个设计要点&＃xff1a;

• 简单高效&＃xff0c;优先满足查询效率&＃xff0c;而不是酷炫的交互

• 信息具有强关联性而不是孤立的一个数据&＃xff0c;具体就是要有环比、同比来体现变化

• 数据图表的刷新频次和统计频次要符合业务的需求&＃xff0c;最好能做到实时更新
• 选用的数据能够体现出趋势和规律&＃xff0c;对于无趋势特性的数据&＃xff0c;直接展示数字比较好
• 对于不同的数据指标&＃xff0c;不同的数据特性需要选用合适的图表。
• 数据波动、对比、排序&＃xff0c;不同的衡量方式也应该选择其对应的图表类型

1. 需求分析

数据报表可能有十几种报表&＃xff0c;几十个数据指标&＃xff0c;但这些并不是都需要呈现出来的&＃xff0c;选用哪些数据指标和衡量方式&＃xff0c;需要和业务团队沟通确定。

需求是分层级的&＃xff0c;有些需求处于核心业务的需求&＃xff0c;有些属于经营管理层面的需求&＃xff0c;而前者永远是公司发展的核心&＃xff0c;因此其重要性和优先级要高于后者。

对于上图来说&＃xff0c;部门员工的相关kpi&＃xff0c;个人绩效属于经营管理层面的数据要求&＃xff0c;第一期工程可以先不考虑实现&＃xff0c;先确保实现核心业务相关的数据看板的可用性和准确性。

2. 战略看板设计

战略看板设计主要突出简洁、唯结果论的特点&＃xff0c;要主次分明&＃xff0c;并且多的展现纯数字内容而非图表&＃xff0c;下图举例&＃xff1a;

一般设置6个左右的数据指标&＃xff0c;有利于专注于分析最重要的指标。

需要支持自定义配置&＃xff0c;可根据业务发展需要灵活调整看板需要呈现的数据。

之所以采用数字形式而不使用各式各样的图表&＃xff0c;一是为了保证第一时间掌握业务现状&＃xff0c;二是公司中高层对业务数据非常敏感&＃xff0c;不需要曲线来表示规律&＃xff0c;只用看到数字就能看出业务异常。

产品经理也应该培养数据敏感性&＃xff0c;以便于能够理解业务&＃xff0c;做出更符合业务需求的数据产品。

3. 业务看板设计

业务看板设计主要突出垂直细分的特点&＃xff0c;研究业务增长就是业务增长的图表&＃xff0c;研究活跃用户就是活跃用户的看板&＃xff0c;或许这其中会有写关联性&＃xff0c;但这种关联是弱关联&＃xff0c;如果数据看板之间含混不清&＃xff0c;那么分析业务也会有很多阻碍。

业务看板与战略看板最大的不同点是&＃xff0c;注重生产过程&＃xff0c;所以多使用增长曲线来体现数据规律和数据变化。研究增长曲线&＃xff1a;

销售漏斗&＃xff1a;

上图所示仅为单一维度&＃xff0c;实际业务场景往往是一个关键业务指标关联着其他的数据指标&＃xff0c;图表要支持维度下钻&＃xff0c;点击能够查看二级指标的图表信息。

要能够支持x轴平移和缩放&＃xff0c;y轴的刻度能够根据数据大小自适应。

业务看板解决的核心问题是&＃xff1a;及时发现业务问题和便于分析业务异常&＃xff0c;视觉设计上要注重各个指标的色彩鲜明&＃xff0c;便于察觉指标与指标间的关系。

业务看板描绘的业务不同&＃xff0c;数据不同&＃xff0c;需要安排在不同的页面上&＃xff0c;业务看板需要足够细分&＃xff0c;绝对不能互相杂糅&＃xff0c;纠缠不清。

4. 选用合适的图表类型

选择合适的图表类型能够最大程度满足视觉可视化的呈现效果&＃xff0c;满足业务数据查看和分析的需求。

以下选用几个典型的业务场景做说明&＃xff1a;

(1)描述业务增长曲线&＃xff0c;利润曲线、销量曲线、用户数量等&＃xff0c;重点表示业务发展的趋势

常规面积图&＃xff1a;

所有数据都从相同的零轴开始&＃xff0c;使用与展示总量与分量之间的关系&＃xff0c;必须设置透明度以避免重叠

堆叠面积图&＃xff1a;

数据起点为上一个数据集&＃xff0c;主要用于展示数据分量占数据总量的百分比&＃xff0c;然后对分量所占百分比进行对比

折线图&＃xff1a;

折线图和面积图都可以用来展示连续数据随时间变化的趋势&＃xff0c;但选用还是有其侧重点&＃xff1a;

• 常规面积图适合表现总量和分量之间的关系&＃xff0c;比如总量是总用户量&＃xff0c;而分量是各个渠道的用户&＃xff0c;那么选用面积图较为合适
• 堆叠面积图适合表现分量所占数据总量的比例
• 折线图更适用于展现分量与分量之间的对比(不含总量)&＃xff0c;避免了面积图阻塞的问题
• 通常情况下&＃xff0c;需要展示数据总量的业务&＃xff0c;使用面积图会更好些

(2)描述业务流程问题

描述业务流程最常用的图表是漏斗图&＃xff0c;销售漏斗图、用户留存漏斗图&＃xff0c;但漏斗图只能表示单一流程&＃xff0c;如果想要表示具体的用户数据流向&＃xff0c;和多维度更加复杂的流程数据&＃xff0c;就很难表示了。

桑基图&＃xff1a;

桑基图能够很好地表示用户从加入购物车到收获的全流程&＃xff0c;主支宽度总和与分支宽度总和相等&＃xff0c;不同宽度代表不同流量的大小。

漏斗图这里就不过多赘述了&＃xff0c;比较简单。

(3)描述数据分布

气泡图&＃xff1a;

气泡图最适合展示数据的分布范围&＃xff0c;横坐标可设置为时间&＃xff0c;纵坐标可设置为商品的价格&＃xff0c;表明商品价格区间随时间变化的趋势&＃xff0c;而不同的颜色表示不同的商品&＃xff0c;这样对于价格频繁变动的商品&＃xff0c;查看其每天的价格分布以及趋势很有帮助。

不常用以及过于简单的图表&＃xff0c;这里就不再详细展开了&＃xff0c;使用图表以好用、够用为原则&＃xff0c;不必过于追求复杂图表&＃xff0c;否则业务团队觉得麻烦&＃xff0c;不愿意使用&＃xff0c;那就背离了产品设计的初衷了。

另外&＃xff0c;自行开发可视化图表耗时耗力&＃xff0c;常见的解决方案是使用ECHARTS 、QCHART、AntV等开源可视化库&＃xff0c;只需调用相应的api接口即可。

其他注意事项

由于b端业务的特性&＃xff0c;后台系统不对外开放&＃xff0c;仅企业内部人员使用&＃xff0c;因此着重强调的还是围绕业务问题进行业务数据建模&＃xff0c;打通分析链路、维度下钻和报表设计等层面&＃xff0c;看板的设计反而较为简单(b端对于视觉体验的要求不高)&＃xff0c;况且市面上已经有很多非常成熟的可视化解决方案可供调用&＃xff0c;视觉体验的设计下限比较高&＃xff0c;因此后台产品经理应该把主要精力集中在后端逻辑层面。

产品经理要尽可能的多参与前期业务设计的过程中去&＃xff0c;旁听业务讨论也有助于理解业务部门痛点和难点在哪里。业务调研和访谈的形式不够深度&＃xff0c;业务方在表达诉求时也可能会偏离他们的初衷&＃xff0c;产品经理只有深入业务逻辑才能对业务方提出的需求多加辨别分析&＃xff0c;形成有产品经理专业意见的设计方案。

声明

来源&＃xff1a;人人都是产品经理&＃xff0c;人工智能产业链联盟推荐阅读&＃xff0c;不代表人工智能产业链联盟立场&＃xff0c;转载请注明&＃xff0c;如涉及作品版权问题&＃xff0c;请联系我们删除或做相关处理&＃xff01;