相信很多数据分析师在写数据分析报告的时候也会遇到一些困惑,因为我最近也在写一个报告,在这里就梳理一下如何写数据分析报告
成都创新互联公司成立与2013年,先为湖州等服务建站,湖州等地企业,进行企业商务咨询服务。为湖州企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
数据分析报告是数据分析师常见的工具,写好一份数据分析报告,不但能够清楚描述问题,洞察数据并且提出一些有思考的举措,也很能反映出一个数据分析师的思维和用数据讲故事的能力,网上虽然也有很多关于写好数据分析报告的文章,但是大部分都是偏重于理论,具体实践的很少,我就在这里做一个汇总,希望能帮助一些朋友,以期抛砖引玉
--------分割线--------正式开始--------
一份好的数据分析报告离不开两部分:数据部分和分析部分。巧妇难为无米之炊,数据之于数据分析师就好像食材之于巧妇,数据的重要性可见一斑,分析部分是数据分析师将数据做成报告的最重要一步,是最体现一个数据分析师功底的部分,也是拉开差距的部分,下面就针对两部分分别进行阐述
一. 数据部分
数据部分最重要的就是数据质量,数据质量的好坏直接决定一份数据分析报告的好坏,如果报告中某一个数据被质疑,会直接影响这份数据分析报告的可信度,本章说一说跟数据有关的一些内容
1.数据的质量
1.1数据类型
数据类型比较好理解,就是数据以什么样的类型存储的,不同的数据类型有不同的使用方法,因此在处理数据之前,必须要先了解数据类型,常见的数据类型有(这里只说一些常见的数据类型):
整数型
int :用于存储整数,存储从-2的31次方到2的31次方之间的所有正负整数,每个INT类型的数据按4 个字节存储
bigint :用于存储大整数,存储从-2的63次方到2的63次方之间的所有正负整数,每个BIGINT 类型的数据占用8个字节的存储空间
smallint :用于存储小整数,存储从-2的15次方到2的15次方之间的所有正负整数。每个SMALLINT 类型的数据占用2 个字节的存储空间
浮点型
real :存储的数据可精确到第7 位小数,其范围为从-3.40E -38 到3.40E +38。 每个REAL类型的数据占用4 个字节的存储空间
float :存储的数据可精确到第15 位小数,其范围为从-1.79E -308 到1.79E +308。 每个FLOAT 类型的数据占用8 个字节的存储空间。 FLOAT数据类型可写为FLOAT[ n ]的形式。n 指定FLOAT 数据的精度。n 为1到15 之间的整数值。当n 取1 到7 时,实际上是定义了一个REAL 类型的数据,系统用4 个字节存储它;当n 取8 到15 时,系统认为其是FLOAT 类型,用8 个字节存储它
字符型
char : 数据类型的定义形式为CHAR[ (n) ],n 表示所有字符所占的存储空间,n 的取值为1 到8000, 即可容纳8000 个ANSI 字符。若不指定n 值,则系统默认值为1。 若输入数据的字符数小于n,则系统自动在其后添加空格来填满设定好的空间。若输入的数据过长,将会截掉其超出部分
nchar : 它与CHAR 类型相似。不同的是NCHAR数据类型n 的取值为1 到4000。 因为NCHAR 类型采用UNICODE 标准字符集(CharacterSet)。 UNICODE 标准规定每个字符占用两个字节的存储空间,所以它比非UNICODE 标准的数据类型多占用一倍的存储空间。使用UNICODE 标准的好处是因其使用两个字节做存储单位,其一个存储单位的容纳量就大大增加了,可以将全世界的语言文字都囊括在内,在一个数据列中就可以同时出现中文、英文、法文、德文等,而不会出现编码冲突
varchar :VARCHAR数据类型的定义形式为VARCHAR [ (n) ]。 它与CHAR 类型相似,n 的取值也为1 到8000, 若输入的数据过长,将会截掉其超出部分。不同的是,VARCHAR数据类型具有变动长度的特性,因为VARCHAR数据类型的存储长度为实际数值长度,若输入数据的字符数小于n ,则系统不会在其后添加空格来填满设定好的空间。一般情况下,由于CHAR 数据类型长度固定,因此它比VARCHAR 类型的处理速度快
时间和日期型
date :‘2018-01-17’
time :‘10:14:00’
timestamp :‘2018-01-17 10:14:00.45’
以上就是常用的数据类型,如果有其他的数据类型没有说到,可以去网上搜一下,都比较好理解
1.2噪音数据
因为网上有非常多的关于噪音数据的解释,都非常专业,我就不在这里做过多的详细解释了,我们只探讨从sql取出数据的时候有一些异常值的处理办法:
null
一般跑过sql的朋友肯定会发现,在跑出来的数据中会有null的情况,这个时候需要对null进行替换,如果是计算用,就把null替换成0,这个步骤可以在sql里面完成,也可以在excel里面完成
极大值
极大值会影响数据的计算结果,一般会进行处理,要么替换成除极大值以外的最大值,要么直接弃用
作为分母的0
如果0作为分母,在excel里会出现#DIV/0,这个时候可以直接把结果替换,或者在sql里面直接进行替换,用case……when……就可以替换
1.3数据的口径
数据的口径很重要,根据经验看,大部分的数据出现问题是口径造成的,数据的口径一定要跟业务的口径一致,拿留存率举例:
留存率是周期比率型指标,一般在计算留存率的时候需要确定 留存周期 和 活跃判定的口径
留存周期:留存周期通俗来讲就是指用户在多长时间范围内活跃,并在下一个周期内仍然活跃,这里的多长时间就是指留存周期
活跃判定:指怎么判定一个用户活跃,可以是启动App,可以是登陆,也可以是完成了一次其他特定行为,这个主要依照业务需求而定
实际计算:
周留存率的计算
分子:本周活跃 且 上周也活跃的用户数
分母:上周活跃的用户数
2.可能会用到的工具
在处理数据的过程中可以用很多工具,在这里就介绍一些比较常见的工具,大家耳熟能详,学起来也不是特变难
2.1提取数据
mysql
hivesql
两者的查询语句有相似的地方也有不同的地方,主要看自己所在公司的数据存储情况
2.2数据处理
python:一般写个脚本做一些机械的操作(我目前是这么用),也可以用来做计算
mysql:在查询的时候可以进行处理
excel:数据量比较小的时候,可以在excel上简单处理
2.3数据可视化
python:可以用来做一些词云图
Tableau:可视化一些图表,可以和sql结合着用
excel:做一些简单的图表,实际上数据处理的好的话,一般用excel就足够了
二. 分析部分
在处理了数据以后就要开始进行报告的撰写,写报告会涉及到几个部分的工作,这里分别进行介绍一下:
1.报告结构
一篇数据分析报告的结构是十分重要的,一个好的结构能够将他人带入到你的报告中,让他人更好的明白你的意图,减少信息传递之间的丢失,同时你的思维也主要展现在结构上,这就意味着在写数据分析报告前,一定好想清楚数据分析报告的结构,当然这里说的报告结构即包括整个报告的结构,也包括每一个章节的结构,这里就放到一起说了
1.1 总 - 分 - 总(多用在整体结构)
我们在读一本书的时候,打开目录,会发现整部书的结构一般包括:
前言
第一篇
第二篇
……
第n篇
结尾
这就是典型的总 - 分 - 总结构,是最常见的结构,如果是对一个专题进行分析,用这种形式是非常好的,举个例子:
某电商App近一个月内的销售额出现下滑,让你针对这个问题进行一次专题分析
分析思路:拿到这个问题,我们很容易想到的是,销售额出现下滑出现的原因有两个,一个是付费用户数减少了,另一个是付费用户的人均付费金额减少了,这两个原因属于并列的原因,不存在递进关系,也就是说付费用户数减少了与人均付费金额减少并不存在因果关系,没有什么相关性,因此需要对两个原因共同分析,最后输出结论和提升建议,分析完以后,会发现总
- 分 - 总结构很适合这样的分析,所以列出以下提纲
问题描述
销售额近一个月下降多少?绝对值,环比,同比数据
原因假设:付费用户数下降/人均付费金额下降
付费用户数下降分析
付费用户数降幅是多少?绝对值,环比,同比数据
定位下降人群:是整体下降还是某一群体用户数下降
这里就涉及到用户分群,用户分群的方法有很多,涉及到用户价值的分群常见的就是RFM模型,将分完群的用户进行数据对比,看看上个月付费用户的结构占比跟本月有什么不同,当然用户分群的方法也不止这一个,还有按照会员等级分群(主要用会员等级进行用户分群),按照活跃程度(新用户/留存用户/回流用户),按照消费习惯(一般用户表里面都会有用户的标签,标识这个用户的消费习惯,表示这个用户更喜欢购买哪一类的商品),不管用什么分群方法,都需要纵向对比,也就是这个月和上个月付费人群的对比
原因分析:
如果是付费用户整体下降(这种是大家都不想看到的现象,欣慰大盘数据的驱动需要投入大量的资源,也有可能是自然波动),考虑可能的原因主要有:用户整体流失,比如用户流失到竟对;或者本月有什么特殊情况,影响到了整体的用户活跃;或者是从活动维度去观察,是不是活动的力度减小,影响了用户付费的欲望
如果是某一个用户群体下降:考虑的原因可能有商品品类的影响,是不是某一类商品在平台没有上架,或者某一类商品涨价;或者这一类用户受到了哪些影响,一般可以从属性和行为角度去分析
提出策略:
针对分析出的原因提出可落地的策略(策略一定要落地,要具体,比如如果你提出一条策略是:提升新注册用户数,那么等于没说,老板多数会diss你,但是你如果说,通过减少注册时填写的非必要字段,如年龄/职业,来简化注册流程,挺升注册转化率,进而提升新注册用户数,那感觉是不一样的)
人均付费金额下降分析
人均付费金额的降幅是多少?绝对值,环比,同比数据
定位原因
人均付费金额下降可能的原因主要有:订单数量下降;每个订单包含的商品数的下降/某一个品类购买数下降
提出策略:针对分析出的原因提出可落地的策略
总结问题
明确造成销售额下降的原因到底是什么(定性以后,记得一定要量化,不量化会被diss)
提出有针对性的建议
如何预防再次发生
1.2 递进(可用于整体结构和章节内部结构)
这种结构适合对一个问题进行探索,就像上一个例子中,我们针对每一个可能原因进行分析的时候,就是采用的这种分析方法,这种分析结构特别适合对一个小问题进行深入的探索分析,层层递进,深挖原因,这里在举一个例子:
某一个App的新注册用户数环比上个月减少,需要你做一个深入的分析,找到原因,提供改进策略
分析思路:新注册用户数的的影响因素是一个典型的漏斗结构,也是一个典型的单向性用户旅程,画一张图就能说明白:
如图所示,影响注册用户数的原因全部标注在漏斗里面,但是注册全流程这个漏斗只能看个大概流失,所以我们会对某一步进行细化,这张图上,我们对用户从启动到注册成功进行细化,细化到用户行为,这样能够提出一些产品上的改进意见,这个时候,如果想要提升新注册用户数,只需要针对每一步流失原因进行分析,找到提升策略就可以了,基本上是所见即所得的分析
比如:我们想对提交注册信息到注册成功这一步进行优化,那么首先我们要找到用户注册失败的原因有什么,一般有:
用户已注册
密码格式不合规
系统错误
未勾选《隐私协议》
在提出建议的时候,只要针对以上原因提出具体改进意见就可以了
1.3并列结构(多用于整体结构)
这种结构一般遇到的情况不多,常见的有对不同的校区进行经营分析/对不同品类的商品进行售卖分析,基本都是以描述型分析为主,因为分析的主体是并列关系,所以只需要每个主体就行单独分析就好,基本采用的分析思路是一样的
1.4因果结构(多用于章节内部结构)
这种结构一般用在复盘分析报告中,复盘是常见的数据分析报告类型之一,也是很多公司比较重视的一个报告,比如双十一复盘/新手活动复盘等等, 以电商某一次大促复盘为例 ,这里直接写结构:
总体描述:
本次大促整体数据表现,整体活动节奏的介绍;销售额是多少,同比提升多少;利润情况;参与用户有多少,同比提升多少;卖出商品有多少,同比提升多少;各个子活动的贡献是多少
子活动1的效果分析
子活动1的简介,作用,发力点
子活动1的贡献是什么,对于直接提升结果指标或者间接提升指标有哪些贡献
子活动1的成本是什么?投入产出比是多少?
子活动2的效果分析
子活动x的效果分析
最后汇总,提出优化建议
2.分析方法
讲完了整体结构,我们就该进入到具体分析的过程里面,这里的分析方法,主要想说说怎么去针对不同的数据进行分析,也就是说怎么通过数据看出问题,这里介绍常用的5种分析方法,但是有一句话非常重要,想写这节的最前面: 数据分析师一定要懂业务,在分析之前最好能把问题定位个大概,再去捞数,再去分析,否则每天会沉浸在漫无目的取数中,我认为一个数据分析师最重要的能力是要懂业务,从数据的角度看业务,才能驱动业务
2.1 对比分析
横向对比
横向对比就是把一个指标按照不同维度拆分,去对比不同维度的变化,举个简单的例子来说就是:
昨天的DAU增长了30%,那么把DAU进行拆分,可以拆分成以下三种方式:
DAU=新注册用户数+留存用户数+回流用户数
DAU=北京活跃用户数+河北活跃用户数+山东活跃用户数+……
DAU=北京活跃用户数+河北的活跃用户数+……
=北京的新增用户数+北京的留存用户数+北京的回流用户数+河北的新增用户数+河北的留存用户数+河北的回流用户数+……
这里留一个疑问,怎么去选择优先下钻的维度?想明白以后分析的效率就会有很大提升
纵向对比
在进行完横向对比以后,就要开始进行纵向对比,纵向对比主要是在时间维度上,还拿上一个例子来说,我们按照第一种方式进行横向对比以后,就要纵向对比,见下表:
2.2分布分析
分布分析一般是应用的场景比如用累计消费金额去分组/按照用户一个月活跃天数去分组,这些场景都有两个共性的特征:
属性值都是数值类型,或者日期类型
属性值非常多,比如累计消费金额可能从1-90000中间任意一个数字,也就是属性值非常多,没办法用每一个属性值去单独分析,因此需要分组
还是上图说明:
2.3交叉分析
交叉分析一般指多维度交叉,或者不同指标之间的交叉
多维度交叉其实有点类似对比分析的第三类分类方法,这里不在赘述了,还是那个图,但是在实际分析中的作用其实很是强大,具体如何应用就需要大家举一反三啦,仔细看看这张图,可以换成哪些分析场景下的哪些场景的交叉分析:
不同指标交叉一般用在分析变化趋势中,或者寻找相关因素的时候,上图:
这样既能看绝对值的变化,又能一目了然的看出变化趋势,如果不同指标之间呈现一定的相关性,那就是相当完美了
2.4漏斗分析
漏斗分析模型比较好理解了,一般在行为分析中常用到,直接上图吧:
是不是有点眼熟?漏斗分析一般分析应用在分析用户使用某项业务时,经过一系列步骤转化的效果,因为用户会沿着产品设计的路径到达最终目标事件,在分析每一步转化的时候会用到这个模型
2.5矩阵分析
矩阵分析是一个不错的分析模型,主要用在分类上面,常见的有用户分类、产品分类等,比如像常见的RFM模型是一个三维矩阵,有八个象限,上两个图看看:
矩阵分析其实不难理解,但是涉及到一个比较关键的问题,就是临界点怎么选择,通俗来说就是第一象限和第二象限的临界值是多少,有的是0,有的不是0,举个例子:
我想用活跃度和累计消费金额对1万个用户进行分群,使用矩阵分析
我建好了这个二维矩阵,我第一件事就是先要确定原点的坐标值,也就是说用户的累计消费金额大于x,就会出现在第一/四象限,如果小于x,就会出现在第二/三象限,想确定这个值需要一定的方法,会用到一些分类算法,这个可以去网上查一些关于分类的教程,有很多,后续我会写一盘文章来介绍分类,这里就不细讲了
以上就是数据分析最重要的两个模块,当然在实际操作中还有很多需要思考的地方,太细节的东西不太能够面面俱到,这里留给大家去思考的空间,比如:
数据分析报告怎么讲成一个故事,比如背景-现状-原因-策略-预期结果-复盘结果?
每一页PPT怎么排版会让你的数据分析报告可读性更高?
如果你的数据分析报告不采用上述的结构,还能用哪些结构?
怎么让你的数据分析报告显得更高大上?
可以留言交流哦
1.具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
2.查找瓶颈时按以下顺序,由易到难。
服务器硬件瓶颈 ?? 网络瓶颈(对局域网,可以不考虑)?? 服务器操作系统瓶颈(参数配置)?? 中间件瓶颈(参数配置,数据库,web服务器等)?? 应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
分析的信息来源:
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据
颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD
1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473
同样,从图中可以看出,在4个小时的时候,web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图,从开始到进行到4个小时反弹之前呈降低的趋势,这是因为系统在初期调用的资源都是直接来之服务器,运行一段时间后系统的部分资源来自缓存。
6.下载组件大小
每个页面的组件大小,且包括组件的标头的大小!
页面组件大小的分析表格比较复杂,实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件,如果其影响到了页面的下载速度,则要想办法将其改小!
7.Apache资源
显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。
颜色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201
三.服务器资源监控指标:
(目前通过top监察)
内存:
Linux资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。
实际测试中,当并发点击数出现突然剧增前后,内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈!
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器:
Linux资源监控中指标CPU占用率持续超过80%(对该值的要求,根据具体应用和机器配置而要求不同,有资料表明95%),表明瓶颈是CPU。
实际测试中,当并发点技数出现突然增加前后,cpu的占用率持续保持在86%以上!
说明,目前系统用应用的cpu也是测试的瓶颈!
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
四.数据库服务器:
数据库服务器目前测试观察,当web服务器点击率增大时,观察mysql数据库的最大连接数,仍未超过系统设置的最大连接数。所以,暂时未发现数据库的瓶颈!
五.结论
以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显,比较利于观察的作为分析案例。
根据以上综合分析,当前测试环境下,当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析,用户在4个小时的时候,并发数迅速增加前后的值在400左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时,测试服务器的硬件配置和实际服务器的配置还有一定的差距!
问题描述:
启动数据节点
/usr/local/mysql/bin/ndbd--initial
/usr/local/mysql/bin/ndbd:unknown variable 'log-bin=mysql-bin'
解决过程:
解:vim /etc/my点吸烟 f注释log-bin=mysql-bin、server-id=1、skip-locking
原因分析:
111015 7:30:10 [Warning] '--skip-locking' isdeprecated and will be removed in a future release. Please use'--skip-external-locking' instead.
经验总结:
新的版本会抛弃有些参数,只要按照常规方法做,遇到问题按提示的解决就好了。