数据分析实际案例复盘

date
Mar 26, 2019
slug
data-analysis-in-practice
status
Published
summary
数据分析可以说是产品的基本功之一了,网上也有很多相关的文章对数据分析做了非常详尽的讲解,包括各种各样的思维方式、拆解模式等等。
tags
数据分析
实际案例
type
Post

一、场景和问题

数据分析可以说是产品的基本功之一了,网上也有很多相关的文章对数据分析做了非常详尽的讲解,包括各种各样的思维方式、拆解模式等等。
但是在实际工作中,我们有时候不一定能够意识到如何去使用这些方式方法。
因此,我以自己在实际工作中遇到的问题为例,介绍一下这些方式方法如何在实际工作中使用。

1.1 场景还原

不知道大家是否遇到过这样的场景,产品的某个页面有一天突然出现流量大幅降低的情况,而且还是核心流程上的关键页面。
比如说我有一次在走查数据的时候发现,在我负责的一个产品上,核心页面的昨日流量突然下降了24%。

1.2 解决问题

在这种情况下一定要首先找到事故发生页,以该页面作为方向进行分析。

技术角度

首先需要排除是否由BUG、技术故障等等因素造成,如果是技术上的原因导致的,需要进一步拆解原因,看下是内部因素还是外部因素。常见的内部因素有APP崩溃、卡死,网页上有400系和500系错误等等;常见的外部因素有第三方接口报错、运营商网络问题等等。
根据找到的不同问题,去看到底影响了多少用户,是否与数据表现一致。
另一方面,也需要及时开始处理问题,内部出错尽量当天沟通、解决;外部原因也需要尽早反应,同时一定要告知客服团队或者运营团队问题所在,以免出现用户反映问题时,还没有准备好相关的话术以及解决方案。
同时,搭建一个相对比较完善的错误通知系统,能够大大提高确认问题的效率。

业务角度

其次,在排除技术上的问题之后,需要看看是否为业务层面上面的问题导致。
举个例子:有一次我发现,一个主推商品的详情页面流量大幅度下滑,因此我找到了事故页查看,但是在进入事故页的时候,原因就已经很明了了。
因为在4月份时,市场部门在做一个折扣比较大的活动,原价99的商品,活动价为9.9,同时配合了各渠道的推广,流量涨的很快,但是就在前几天,由于一些内部原因,市场人员将价格从调整回原价,同时也减少了推广力度,因此带来了流量的突然下降。
所以,这边建议大家一定要跟市场部门的同事沟通好,如果在业务上发生了一些调整,产品需要尽早获知,不然在不知情的情况下比较容易浪费自己的时间。
先确认技术问题还是先确认业务问题,需要视完成的效率而定。
比如说如果在先排除技术问题,会比较容易一些,那就先去排除出现BUG的可能性;反过来,如果在确认业务是否有调整上更加容易,那就可以优先排除业务上的问题。

流程角度

在流程上去寻找问题也是一种很常见且有效的思路。比如说开头我举的例子中,我在回到流程上看的时候,发现事故页面本身的情况是正常的,但是之前一个页面的退出率从百分之几,增加到了百分之二十多。
显然,问题出现在了前一个页面上,不过为什么这个页面的退出率会突然增加呢?这个时候可以分析该页面(后称问题页)在流程上的作用,具体流程如下:
经过分析,问题页在流程中主要是让新用户完成一个动作后进入事故页,而用户也必须完成这个动作才能进入事故页。
因此上一个问题也可以转化为:为什么用户没有在问题页去完成需要进行的动作,反而直接退出。

用户角度

这一步其实就可以对用户进行分类分析。
在问题页的用户从新老属性来看,都属于新用户,也就是说只有新用户才能进入到问题页,在问题页完成操作之后,就直接进入事故页。之后再回到这个产品的时候,也不会再进入到问题页,而是直接到事故页。
因此,该问题主要是发生在新用户上,那么相比于之前的新用户,昨天的新用户为什么不愿意完成操作呢?
为了解决这个问题,可以对用户分类进行进一步拆解:昨天的新用户和昨天之前的新用户有什么区别?
其实乍一听,这个问题很奇怪啊,都是新用户,哪有什么区别?
但其实这两者是有区别的,不过由于涉及到具体业务,我就不详细说了分析过程了,直接说结论吧:和运营沟通后发现,对于这个产品的推广在前天已经结束。推广渠道主要是公众号文章,文章内容包括了对产品的解释和说明,因此昨日之前的新用户对于要在问题页完成一个操作才能进入事故页是有预期的
而结束推广之后进入的新用户,由于对产品不了解且没有清晰的说明,所以才造成了退出率突然提高。

解决

因此,在找到了原因之后。解决问题的方向也就有了。不过限于篇幅,这里就不细说了,主要还是从流程上思考,在流程上解决——比如说在这个例子中,我就是通过修改问题页前的着陆页文案,提供给用户一个预期,从而解决了这个问题,目前问题页的退出率也维持在3%左右。

二、总结

其实在面对不同的场景还可能有不同的方案,有时候从流程角度分析会更加准确,但是有时候需要先从用户角度去分析。
比如说假如一个商品的访问流量下降,通过对业务流程图的分析可能没有发现问题,但是如果对比两个时间段的新老用户占比,可能会发现老用户的流量下降影响到了整体的数据。
导致这个问题的原因有很多,比如说召回——邮件进入用户垃圾箱、短信发送失败或者APP&微信推送发送失败…
同时,代入本文的场景中,在核心页面上通过新老用户的时间段流量差异去发现问题也是可以的。不过需要注意的是,我前面提过推广已经减少,因此在新用户量上肯定存在波动,这对在实际情况中的分析上也容易起到误导作用,所以在这个时候如果能够对数据的波动有一个大致准确的预判,会减少分析过程中的干扰。当然,我自己暂时还做不到这一点。
这篇文章主要分享了我自己在实际工作中针对流量下滑时是如何分析的,分析的过程总得来说是优先排除技术故障和业务调整,然后再通过流程角度用户角度去分析、发现问题。
同时,我个人建议,大家不要太过于执着于那些看似高大上的分析方法和分析工具,发现问题、找到问题、解决问题才是更加需要关注的主题