# 数据分析中会常犯哪些错误，如何解决？

先表明身份，本人从事互联网运营岗，定期需要对新媒体、网站等平台数据进行复盘，电脑操作系统 Win7 64bit，分析过程中不涉及编程及专业分析软件，直接上 Excel 2013 和 WPS。下面以网站数据（为保密，部分展示数据经过处理）分析为例，聊聊我在数据分析中的一些浅见。

▍数据获取

**01\. 数据来源平台的选取**

大多中小企业都是直接外挂的三方统计软件，如 GA、百度统计、CNZZ、[51la](https://www.zhihu.com/search?q=51la&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D) 等，虽然大多数统计平台在功能上相差无几，但是统计数据还是有微小的差别。我曾在百度统计和 CNZZ 两个平台的优劣选取上纠结过一段时间，后来索性两个平台都上，当双重保险。平时的分析中我比较习惯 **CNZZ**，但是如果你的网站上了**百度竞价**，那么百度统计是更好的选择。现在统计代码基本都是异步加载，不用太过担心速度问题，如果你还纠结，那就和我一样都上吧。

![](https://picx.zhimg.com/80/0b770a8f5fd070329662146c45521180_1440w.webp?source=1940ef5c align="left")

![](https://pic1.zhimg.com/80/1f6f6993c17474b8514fcff1299a3fb8_1440w.webp?source=1940ef5c align="left")

**02\. 本地保存「即时数据」**

[统计软件](https://www.zhihu.com/search?q=%E7%BB%9F%E8%AE%A1%E8%BD%AF%E4%BB%B6&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)后台都会保存大部分数据，如 CNZZ 的来路页面、[受访页面](https://www.zhihu.com/search?q=%E5%8F%97%E8%AE%BF%E9%A1%B5%E9%9D%A2&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)等，基本不受时间限制，随时可以下载的。但是要注意那些需要即时保存的数据栏目，如 CNZZ 后台的「访问明细」，该栏目**只保存最近 7 天的数据**，这就意味着如果你一不注意，放个长假回来，数据找不回来了。所以，类似的「即时数据」，一定要保存到本地。

![](https://picx.zhimg.com/80/77643e30636d99ad51b80d7e738c3509_1440w.webp?source=1940ef5c align="left")

**03\. 下载数据格式选「.xls」**

统计后台遇到报表需要下载时，基本都会出现下载格式选项，CNZZ 是.csv 和.xls，百度统计是.csv 和.pdf。pdf 数据自带图表；csv 为纯文本数据格式；xls 为 Excel 专用，便于数据分析。其中.csv 文件和.xls 下载下来后，数据的长相极其相似（这就有个坑，后文有避坑方法）。因为 csv 文件是纯文本数据，并不是数值，所以**不能进行数据上的求和，求平均值，只能计数！**如果你不小心用了.csv 文件，一定要先处理成数值，否则后期数据分析时会有无法正确统计的情况！

![](https://picx.zhimg.com/80/978646dc3aaa5063dc99792ee2888310_1440w.webp?source=1940ef5c align="left")

**04\. 多页数据采集及合并**

当你需要保存在线数据时，需要注意一个小细节，比如 CNZZ 的「访问明细」栏，右上角显示的下载按钮是「**下载本页报表**」，而其他栏目的下载按钮是「[**下载报表**](https://www.zhihu.com/search?q=%E4%B8%8B%E8%BD%BD%E6%8A%A5%E8%A1%A8&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)」，下载报表是不管当前显示多少页，系统默认下载所有页面数据，不会缺失。而下载本页报表就只下载当页显示的页面数据。我被坑过一次，分析数据时发现数据明显少了很多，一看原来只下了一页的数据，再想下载的时候，服务器数据已经过了 7 天，没了...

下载每页报表，会遇到的第一个问题是：当网站访问量大时，访问明细数据每一页都需要点击下载。我目前的解决办法是使用「[**火车头采集器**](https://www.zhihu.com/search?q=%E7%81%AB%E8%BD%A6%E5%A4%B4%E9%87%87%E9%9B%86%E5%99%A8&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)」，模拟人工点击，下载每页数据；第二个问题是：自动下载的数据每一张都有表头 / 尾，人工合并也会累死。可以使用 Excel VBA 功能，但我的办法是使用「**慧办公**」插件的合并多表功能（有次数限制，需购买）。

![](https://pica.zhimg.com/80/a4b9dae70cc3b7d69138f3a5d58a6657_1440w.webp?source=1940ef5c align="left")

这两大问题，有更好的解决办法，欢迎告知。

▍数据清理

**01\. 尽量不对源数据做修改**

我做数据分析有个原则，就是「坚决反对对源数据进行直接修改」。首先，专业的统计软件在设计统计后台的数据时，已经千挑万选，选出的数据能符合绝大多数用户的需求。当源数据不符合你的要求时，**千万别在源数据中插入行和列**，比如要插入日期列，请插入在数据表头或者尾。因为每次保存数据时，都是直接从下载好的表格中粘贴数据，在[源数据表](https://www.zhihu.com/search?q=%E6%BA%90%E6%95%B0%E6%8D%AE%E8%A1%A8&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)中多出任何一行或列都会**增加你的操作成本**。

我曾经为了数据看起来更直观，把下载好的源数据两列值进行位置对调，最后导致我每次粘贴数据时都要先调换列。特别是有一次做工作交接，我忘记提到这个细节，交接人员没注意位置和源数据不一样，导致分析出错。

也就是说，对源数据尽量减少人为干预，省心省力。

![](https://picx.zhimg.com/80/301b390854d1c6c16be90bee49ef0a48_1440w.webp?source=1940ef5c align="left")

**02\. 坑货 csv 要转化为数值**

在数据获取部分我提到了关于源数据是.csv 格式的问题，如果你知道这里有坑不进去是最好的，但是已经进去了，怎么办？我最开始下载源数据一直用[csv](https://www.zhihu.com/search?q=csv&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)，因为 csv 的文件小，下载速度快，最后数据分析时蒙 B 了。那么**已经保存为 csv 格式的数据怎样变成数值呢？答案是 Excel 的分列功能。**

1）Excel 打开源数据表，复制部分数据到.txt 文本中，观察源数据用的什么符号；

![](https://pica.zhimg.com/80/38ecbcd0e5274913085d8fbe5601f8df_1440w.webp?source=1940ef5c align="left")

2）选中某列数据，点击导航栏「数据」—「分列」；

3）下一步，如图中的数据分隔符是「Tab」+「"」，那么选择 Tab 和其他两项，继续下一步；

![](https://pic1.zhimg.com/80/3e7a471b4711ae1abac391009b34a4e8_1440w.webp?source=1940ef5c align="left")

4）选择目标区域（要复制在哪里），搞定。

![](https://pica.zhimg.com/80/4eee611523e35fc6a800f1f765e30713_1440w.webp?source=1940ef5c align="left")

▍如何制表

**01\. 报表是你思考结果的展示**

我发现在工作中，有的小组制表人和分析人不是同一个。这很可能导致成员在分析报表时变成了「看图分析」而不是真正的「看数据分析」。制表的基础是制表人必须清楚的知道源数据是从哪儿来的？怎么来的？是怎样从数据变成表格的？在变成表格的过程中有没有因为美观被隐藏掉某些内容等。

要记住报表是要把分析人的思路更简洁的展示给其他人。所以我推荐，[**制表人**](https://www.zhihu.com/search?q=%E5%88%B6%E8%A1%A8%E4%BA%BA&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)**就是分析人本人**。不要以浪费时间和[办公软件](https://www.zhihu.com/search?q=%E5%8A%9E%E5%85%AC%E8%BD%AF%E4%BB%B6&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)不熟悉为由拒绝，**熟练掌握办公软件，我觉得是运营人的基本素质**。

思路的展现逻辑一般是「总分总」，以网站分析说，我的框架是：流量趋势→来源渠道→渠道 1 明细→渠道 2 明细...→来路分析→受访分析→搜索词→外链。

![](https://pic1.zhimg.com/80/ea4982a17f1c92cb1b0d3f762f0c57a4_1440w.webp?source=1940ef5c align="left")

**02\. 制定表格规范**

在制表的过程中，不少同学表格做的很随意。展示图表乱用，用折线图表达百分比关系？数据对比用折线图？？**为数据选择最合适的图表类型**，比较数据间区别时，用条形图；表示不同项在总体的占比时，用饼状图；反映事物变化时，用折线图；观察不同项目长短板时，用雷达图...

还有其他诸如符号使用规范、配色规范等，不一一列举。总之，秉着「**方便他人**」的思路就对了。

**03\. 数据分析后一定要给出可执行建议**

不可否认很多人把数据做成表格只为了装逼，让别人看起来很牛。但是作为一个专业人员始终记得「报表只是你思考结果的展示」，最重要的是**你通过数据分析出来了哪些对今后工作有指导性的建议，其他人可以直接按照你的建议执行，就能取得良好效果。**

比如，观察数据发现「本周的 PV 大幅度降低」，没有指导意见的说法是「增加文章更新频率」。虽然这个说法没错，但真正具有指导意见的应该是先分析 PV 下降的具体原因，找到原因后针对解决，而不是说「增加文章更新频率」这样一个大方向。

把报表做的漂亮是一种能力，但是美观始终流于表面。只有真正有指导性的建议才能长久的打动人。

这一步很难，可是做到了，你就绝不只是个专员。

**04.**[**透视表**](https://www.zhihu.com/search?q=%E9%80%8F%E8%A7%86%E8%A1%A8&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)**，降维打击**

早前我使用 Excel 做分析的时候，基本上是直接用基本的筛选、公式（sumif、countif、sumproduct）、条件格式之类，虽然操作逐渐变得熟练，速度越来越快。可是想象一下，当你需要对比源数据中两天某一项数据的区别时，可能需要先加入三列辅助列，然后使用[countif函数](https://www.zhihu.com/search?q=countif%E5%87%BD%E6%95%B0&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)对两列进行计数，第三列使用减法再加上颜色的条件格式。如何对比两个月的数据呢？用 sumproduct，多塞几个条件？？

**我推荐越早学习透视表功能越好**，使用的 Excel 的「[数据透视表](https://www.zhihu.com/search?q=%E6%95%B0%E6%8D%AE%E9%80%8F%E8%A7%86%E8%A1%A8&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)」功能后，洪荒之力暴涨，「对比功能」「创建组」功能，分析起来简直不要更爽！哪里需要繁琐的公式？一开始别觉得很麻烦，你只要记住**「‘列’丢对比项；‘行’丢分析项；‘值’丢数据结果项」**。不懂的多试几次，自然就熟了。花几个小时，可以省掉你用 Excel 基本功能时 80% 的时间。

另外，对于 Excel 的学习，基本功也别落下，对数据的基本函数和条件格式，用好了也能飞。

![](https://pic1.zhimg.com/80/08cc72ea8224f055d1a4783321c9cd39_1440w.webp?source=1940ef5c align="left")

▍分析要素

**01\. 日记：当天有特殊情况记录在趋势表中**

作为网站运营者，每天上班的第一件事就应该是粗略过一遍昨天的统计数据。在每天的过程中要密切关注不同小组有没有做可能大幅度影响网站流量的工作。比如 EDM、活动运营开展了一次线上活动、内容运营抓取了某个栏目的文章、技术人员对某个栏目改版等。这里存在沟通问题，本部门作为各平台负责人一定要事先强调**事先通知**的重要性。虽然事后可以通过数据反推，但是可能导致思考过于发散。

把每天收集到可能影响到网站数据的情况「批注」在趋势表中，等到周报时进行数据对比，会方便很多。

![](https://pic1.zhimg.com/80/d54c97bfbbbc19038108bb1dd6fb76f1_1440w.webp?source=1940ef5c align="left")

**02\. 峰值：高峰、低峰都不能放松**

在面对图表分析时，峰值最为明显。但是很多人**只分析不好的低峰而忽略高峰，对高峰擅自代入。**

面对峰值时，首先要缩小粒度。如观察 8 月 8 日出现低峰，那么再看是在 8 月 8 日当天哪几个小时数值降低，再分别筛选出这几个小时的来访及受访数据，逐一分析，找到根源。**低峰找出原因，今后避免；高峰，也找出原因，今后重现，验证你找到的原因。**

![](https://pica.zhimg.com/80/b4793c73b0959f55a3f4726ffd83e93d_1440w.webp?source=1940ef5c align="left")

**03\. 对比：约束变量，同轴对比**

在上文中提到了「制定表格规范」，其中对比规范的核心就是要同轴。比如数据对比坐标轴不能瞎变，这周记录的是星期一到星期天，对比的是本周和上周；下周记录的变成了星期三到星期五，对比的是上半月和下半月。坐标轴一定要按照表格类型来，周报告就以周报告为轴，对比的也是本周 7 天和上周 7 天的数据。有特殊情况需要在周报告中显示更长的时间段时，也请固定该时间。频繁更换坐标轴或者完全乱来，不仅会影响报告的可读性，也可能会导致分析人分析出错。

![](https://pica.zhimg.com/80/7bacee5a86534b713447807a9fd15439_1440w.webp?source=1940ef5c align="left")

**04\. 经验：记住周期性现象，这是你的宝藏**

什么叫周期性现象，比如「每逢节假日流量下降」、「每逢周末流量下降」、「每周三 9 点 PV 暴增」等等，多次重复并反映在数据波动上的情况。

针对平台运营，记住所有周期现象，这就是你今后工作比别人更专业的经验来源，不需要企业花费大量试错，节约的人力物力就是你的价值。

但要注意的是，周期性现象也是有「周期」的。互联网时代知识日新月异，不要守旧，经验也可能骗人。

**05\. 反常：事出反常必有妖**

什么叫反常现象，比如大多网站在中午 12-14 点间，流量都会因为网民需要休息显著降低，且 PC 流量降低，移动流量骤升。但是如果某一天，或者某一周的 12-14 点流量全体暴增呢？

反常现象就是在周期性现象的异变，**当多次出现反常现象时，你找到原因后就要开始重新审视周期性现象是否产生了变化**，是否是政策变化；是否是环境风向变化；是否是平台玩儿变化等。

▍理论误区

**01\. 猜测不代表结论**

进行数据分析时，先看日记中记录了哪些行为，再对比数据结果看记录该行为的同时是否产品数据波动，如果数据波动符合日记中的行为常识，那么就可以大胆**猜测**该项数据变化是由该次行为导致。

**接着你要做的就是通过数据验证它，而不是武断的认为数据波动就是这个行为产生的。**

举个例子，某次公司派同事去路演，路演 PPT 尾页留有微信公号的二维码。结果在数据分析时，发现当天微信新关注数量暴增。然后运营人员不经过验证就直接武断的把新增用户的效果归于路演，甚至得出了要多参加路演的指示。可是最后在数据分析时，发现当天新关注数的增长来源是「名片分享」而不是「扫描二维码」，后来一问才知道，是社群组的同事进行了一次小范围的社群名片互动。

始终要记住「猜测不代表结论」，**提出猜测后，要证实它**。当出现实在找不到根源的问题时，先暂时放弃，记录下你的猜测，找机会再验证它。

**02\. 深入分析，结论可能是假的**

刚才提到了「猜测不代表结论」，这里面存在连环套。因为数据分析工作面对着大量数据，时间一长，人难免会焦躁，特别是**老是找不到原因时，很容易得到假结论。**

举个例子，某次分析网站数据时，对比发现有一天网站的 PV 暴增许多，缩小粒度后发现数据增幅集中在当天 14-17 点，然后开始分析「受访页面」的访问次数，一排序，发现某个栏目 PV 暴增，一问部门同事才发现是因为内容运营开了爬虫，抓取了大量的信息流，提高了 PV 量。

这时候，如果不细想很容易得出「PV 暴增是由于内容组抓取大量内容导致」的表面结论。因为回到问题中，原现象是「14-17 点，PV 暴增」，现有的表面结论并没有按照小时粒度去分析，最终分析 14-17 点小时数据时，发现原来是因为这三个小时来了一位新访客，浏览了多篇资讯文章，然后把所有栏目都看了一遍。

所以最终 PV 暴增的原因应该是「新访客浏览整站」和「内容组开爬虫」共同作用引起的，而非单一项。在实际工作中，人们很容易只是看到了第一层表象就得出结论，时刻记住多深入分析，想想现有的结论是不是到最小粒度了，有没有可能是个陷阱？

▍结语＆题外话

**01\. 当你的某项工作长期不见起色，怀疑源头试试**

以数据分析来说，分析人员有时候会出现分析来分析去就是得不出结论的现象，导致这种现象的原因除了上文提到过的「csv 格式」等操作问题时，还有可能是数据源本身出现了错误。**别想着机器就一定正确**，如 CNZZ 后台统计「来源分类」时，四个来源渠道数量相加出现了不等于总和的情况。这里面有部分来源是后台统计不到的，所以没有计入。也会有下载数据表格时，后台出错下载一了张空表，合并时就出现大坑。

所以适当的怀疑源头，说不定会有意想不到的发现。

**02.**[**三方平台**](https://www.zhihu.com/search?q=%E4%B8%89%E6%96%B9%E5%B9%B3%E5%8F%B0&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A116047189%7D)**不可靠？那就自建**

刚才提到了统计后台出错的一些情况，当后台出错的次数很高，就降低了运营者对统计软件的信任度。一旦对源数据的正误产生了怀疑，工作起来绝不会顺心。

既然三方平台不可靠，有实力就让公司的技术人员自行搭建后台吧。在技术人员实力过硬的情况下，不仅可靠，而且可扩展性强，分析粒度也更细（如 CNZZ 不能统计用户行为路径），可以完全按照运营人的数据要求进行定制，后期为用户建模时，提供全面的数据支撑。

**03\. 数据不会说话，但你要负责**

在数据分析中，你会慢慢找到很多乐趣。第一次学会用 Excel 某个函数的得意、第一次知道透视表时的兴奋、第一次制作 PPT 被夸奖时的欣喜... 你发现了很多坑，也学了很多小技巧。会从小白变成大神，能轻易的使用某个小聪明的手段，掩盖掉真实数据的缺点。这些，数据永远不能开口说话，但是你要对自己负责。

**每一次不经思考的结论，都可以帮你忽悠到外行人，但终会被打脸。**

**04\. 乐于分享，永远好奇**

终于写到最后了，这几年来在数据上走过的路都变成了这些文字。**保持对知识的敬畏，一直是我的理念。**可能某一天你还在为自己的某个发现自鸣得意时，就发现不过是坐井观天。

希望能和朋友们共同学习，如你对上述观点和方法有不同的意见，欢迎大家一起探讨，见识更大的世界。
