在工作中我们都会遇到各种各样的数据变化，比如：A活动页面的某礼品按钮点击怎么突然下降了30%？B入口的点击怎么上升了50W？总的来说，不管数据是提升还是下降，我们都需要明白造成该现象的原因以便于后续工作的开展。

本文将从以下三个方面来阐述数据分析的要点：

发现问题、处理问题、规避问题。

1、发现问题

1.1、数据埋点

首先，以A活动页面为例，用户看到客户端入口（活动入口曝光，a1）——用户点击入口（活动入口点击，a2）——用户等待载入页面（页面跳转，a3）——展现A活动页面（页面到达，a4）——用户看到礼品按钮（按钮曝光，a5）——用户点击礼品按钮（按钮点击，a6），你看，短短的用户从入口进入页面到点击按钮，就可以拆分出6个最基本的数据节点，在这些关键节点上统计数据就是我们经常所说的数据埋点。

其次，要明确每个埋点代表的含义，比如点击数，是否仅在用户点击触发该按钮时发出？用户连续点击是全部计入还是仅算一次？根据业务特性，来确定每个数据的含义也是必不可少的。

1.2、数据监控

只有定时监控数据，才能及时发现数据的异常。这里可以选择自动报警或者人工监控。前者可以通过以往出现问题的情况设置一条基线值，一旦数据越过基线值则自动报警；而后者需要人工监控每个数据节点，一般通过定时查询或自动生成数据列表发送邮件来完成。

2、处理问题

2.1、定位数据节点

发现数据波动之后，不要着急去找是哪里出了问题，首先应该判断这个波动是否在正常范围内，然后才是哪个数据节点的问题。

如何判断这个波动在正常值范围内呢？不能单看某一个值去判断是否发生变化，比如今天我发现A活动页面的礼品按钮点击比昨天下降了30%，我们就可以认为是数据异常吗？不是的。首先我们要根据时间同比去验证（为什么是时间同比？因为单从时间维度来划分，就可以分为工作日、周末以及节假日，用户由于自身属性不同如学生、白领、个体户等在每个时间段的表现都是不一样的，所以用周一和周日的数据来比较，本身就没有可比性），比如该点击是周均值，那么就要和上周周均值进行比较，如果是日均值，那么就要和上周同期日均值比较，如果相同，那么表示数据正常，如果不相同，则开始检查上游数据。

何谓上游数据，以1.1为例，a5对于a6来说就是上游数据，a6对于a5来说就是下游数据。因为通常情况下（转化率=a6/a5不变的前提下），下游数据本身就会因为上游数据变化而变化（所以很多人也会直接用转化率来监控相关数据，而不是看单一变量）。如果a4减少，那么a5及a6通常都会减少。这个时候，如果我们发现是上游数据下降导致下游数据减少，那么仅需要针对上游数据进行检查就可以了。

因为转化率=a6/a5，若转化率不变，a6下降，那么a5一定下降相同幅度，我们需要再往前找到a4来观察；若转化率变化，a6下降，那么a5就可能提升或者下降，这个时候，我们来到2.2。

2.2、定位问题原因

主要有两类问题可能导致该情况出现：技术问题、运营问题。

技术问题主要包含了是否日志丢失或硬盘已满、如果是预处理数据是否处理完毕、服务端返回是否正常、客户端获取后展示是否正常，是否程序出现BUG等。

运营问题主要包含了页面结构是否发生调整、文案是否更新、引导用户的方式是否发生变更等。

2.3、排期处理问题

发现问题之后是立即修复还是排期处理？“你有病吗？我们都发现了问题了，难道不立即修复，还等什么？”我想很多人都会问这句话，但是在实际工作中，我们需要根据问题的重要性（问题引发的后果）来安排优先级。一般来说，数据异常本身不会对用户造成影响——除非是客户端BUG导致用户使用出现问题或者影响到一定程度的收入。如果是客户端展示或者服务端问题，前者需要通过发版来解决，那么修复期限就会拉长，视发版时间及覆盖速度而定；后者不需要发版，修复后可以立即覆盖，但需要考虑兼容老版问题。如果是运营方式导致，那么分分钟就能够搞定！

一般来说，由于技术引起的问题，需要考虑更多，而且修复时间较长；由于运营引起的问题，基本都可以马上修复。

3、规避问题

在每一次处理问题之后，最重要的就是制定流程，防止下一次出现相同的问题。

比方说，每次发版做好测试流程保证功能无误，引导方式变更最好能离线预估效果再上线，或者进行灰度测试；

在处理完每个问题之后，都应该能够用文档形式记录下来，比如问题原因、处理方式等等，作为以后复盘的资料有很大的用处，一定要做好整理问题的习惯。