数据分析实际案例复盘

本篇文章主要适合这一人群：能够接触到业务数据并且需要通过数据指导工作，但是在分析业务数据时，经常用抓瞎的方式，而非系统性的思考。

内容简介：复盘之前工作中的一次数据分析过程。

具体内容

数据分析可以说是产品的基本功之一了，网上也有很多相关的文章对数据分析做了非常详尽的讲解，包括各种各样的思维方式、拆解模式等等。

但是在实际工作中，我们有时候不一定能够意识到如何去使用这些方式方法。

因此，我以自己在实际工作中遇到的问题为例，介绍一下这些方式方法如何在实际工作中使用。

1. 问题背景

不知道大家是否遇到过这样的场景，产品的某个页面有一天突然出现流量大幅降低的情况，而且还是核心流程上的关键页面。

比如说我有一次在走查数据的时候发现，一个产品核心页面的昨日流量突然下降了20%以上。

2. 解决过程

在这种情况下需要找到事故发生页，以该页面作为方向进行分析。

技术角度：

首先需要排除是否由BUG、技术故障等等因素造成，如果是技术上的原因导致的，需要进一步拆解原因，看下是内部因素还是外部因素。常见的内部因素有APP崩溃、卡死，网页上有400系和500系错误等等；常见的外部因素有第三方接口报错、运营商网络问题等等。

根据找到的不同问题，去看到底影响了多少用户，是否与数据表现一致。

另一方面，也需要及时开始处理问题，内部出错尽量当天沟通、解决；外部原因也需要尽早反应，同时一定要告知客服团队或者运营团队问题所在，以免出现用户反映问题时，还没有准备好相关的话术以及解决方案。

同时，搭建一个相对比较完善的错误通知系统，能够大大提高确认问题的效率。

业务角度：

其次，在排除技术上的问题之后，需要看看是否为业务层面上面的问题导致。

举个例子：有一次我发现，一个主推商品的详情页面流量大幅度下滑，因此我找到了事故页查看，但是在进入事故页的时候，原因就已经很明了了。

因为在4月份时，市场部门在做一个折扣比较大的活动，原价99的商品，活动价为9.9，同时配合了各渠道的推广，流量涨的很快，但是就在前几天，由于一些内部原因，市场人员将价格从调整回原价，同时也减少了推广力度，因此带来了流量的突然下降。

所以，这边建议大家一定要跟市场部门的同事沟通好，如果在业务上发生了一些调整，产品需要尽早获知，不然在不知情的情况下比较容易浪费自己的时间。

同时，技术问题和业务问题的排除优先级，需要视完成的效率而定。

比如说如果先排除技术问题，会比较容易一些，那就先去排除出现BUG等情况的可能；反过来，如果在确认业务是否有调整上更加容易，那就可以优先排除业务上的问题。

流程角度：

在流程上去寻找问题也是一种很常见且有效的思路。比如说开头我举的例子中，我在回到流程上看的时候，发现事故页面本身的情况是正常的，但是之前一个页面的退出率从百分之几，增加到了百分之二十多。

显然，问题出现在了前一个页面上，不过为什么这个页面的退出率会突然增加呢？这个时候可以分析该页面（后称问题页）在流程上的作用，具体流程如下：

经过分析，问题页在流程中主要是让新用户完成一个动作后进入事故页，而用户也必须完成这个动作才能进入事故页。

因此上一个问题也可以转化为：为什么用户没有在问题页去完成需要进行的动作，反而直接退出。

用户角度：

这一步其实就可以对用户进行分类分析。

在问题页的用户从新老属性来看，都属于新用户，也就是说只有新用户才能进入到问题页，在问题页完成操作之后，就直接进入事故页。之后再回到这个产品的时候，也不会再进入到问题页，而是直接到事故页。

因此，该问题主要是发生在新用户上，那么相比于之前的新用户，昨天的新用户为什么不愿意完成操作呢？

为了解决这个问题，可以对用户分类进行进一步拆解：昨天的新用户和昨天之前的新用户有什么区别？

其实乍一听，这个问题很奇怪啊，都是新用户，哪有什么区别？