数据：验证数据的方法
最近远离大江大河，没做电商、没做O2O、没做移动互联网，甚至离产品也有些距离。看似只做着平凡的数据工作，数据的量称不上大、数据的价值没有完全体现、对数据的分析和挖掘也没有深入。但一开始有想法写有关数据的事儿，脑子里还是跳出了很多话题，那些自认为有用或者有趣的话题就等我慢慢写吧，希望能够坚持下去。今天打算说的是个浅显的有关验证数据方法的方法论，真是浅显的，离科学方法差很远。
先说说背景，非技术同学，或者说大多数和数据打交道的同学都会面对该如何去判断数据是准确的这个问题。当拿到一份数据的时候，我们需要确认数据是正确的，但仅从数据本身来看，我们又很难去判断它是否是正确的。我们遇到的问题是，该如何对数据的正确性做出判断呢？老板或者其他的数据使用者一般情况下不需要面对这个问题，术业有专攻，更多的是做数据的同学需要面对。换句话说，我们必须保证产出的数据是正确的，因此在产出数据的时候，一定需要某种方法去验证数据的准确性。
这个问题是我开始做数据时面对的第一个问题，也是我面试的时候肯定会问的一个问题，无论是工程师还是非工程师都需要面对这个问题。这无关数据的合理性，数据是否和业务贴近、是否体现了业务的变化，等等都不是讨论的范畴。这也和数据的价值没有关系，最终对业务的帮助，最终对团队的帮助，等等也都不是讨论的范畴。这个话题只是如何验证数据是否准确，数据准确是一切后续工作的大前提，是保证这项工作存在价值的底线。一般而言，我期望得到下面这几个方面的回答：
1，原始数据确认
首先要做的当然是确认原始数据的准确，包括数据采集、入库、加工、清洗，这一系列的工作是否OK。
如果这里面哪个环节出了问题，后面的一切确认都白搭，这是最基础的保证。
话说我确实遇到过数据采集就出现了问题的情况，无论是页面补码的方式还是服务器日志的方式都有可能出现问题。
解决方法就是严谨的态度和专业的做法，原始数据不是不值得怀疑的。
2，算法确认
其次就是对算法做确认了，也就是对数据计算时的时间范围、业务范围、业务逻辑做确认。
需求是通过文字或语言传播的，这两种传播方式都会失真，也就是接收方理解的和提出方说的不一致，甚至提出方想的和说的也不一致。
这种情况在和工程师打交道的时候更容易出现，不是说工程师弱智，只是因为不同工种的思维方式不一致。
解决方法并不复杂，听的人同自己的理解再复述一遍即可，再加上具体事例的演示，就可以做好。
3，常识判断
尝试判断有点虚，毕竟我不是在说具体的案例，但是常识判断真的很有用。
一般情况下，数据出错，不会阴差阳错的看上去没问题，都会和常识相悖。
比如流量的突然升高或者降低，或者转化率的不正常变化，或者指标项根本就不符合逻辑。
解决方法就是多看多琢磨，平时多积累，对数据有感觉。
4，勾稽关系
先解释勾稽关系的定义，百度百科是这么定义的：
勾稽关系是会计在编制会计报表时常用的一个术语，它是指某个会计报表和另一个会计报表之间以及本会计报表项目的内在逻辑对应关系，如果不相等或不对应，这说明会计报表编制出现问题。
我们产出的数据一般是多个指标，或者多个维度，也包括不同时间范围。
不同数据之间一定会有一些逻辑关系，不一定是直接的，也可通过常识来增加逻辑关系，这就可以使用勾稽关系来验证。
这是会计学科里面的常用手段，在这里也同样适用。
5，横向对比
大意是拿这份数据和有关联的已知正确的数据做对比，本意也是勾稽的一种。
比如和其他业务线的数据做对比，比如拿流量数据和用户数据做对比，比如拿PC数据和APP数据做对比。
虽然有点粗糙，但原理是成立的，即在一个整体中，一个参数的变化一般会引起其他参数的变化。
解决方法是能够跳入跳出，不但可以从局部看数据，还可以从整体看数据。
6，业务判断
这是产品或者运营同学的强项，即用业务的进展情况来判断数据的准确性。
在使用前5个方法埋头分析数据的时候，偶尔会有顿悟，就是说数据的不确定性可以用业务的变化来解释。
比如昨日上线了新产品，昨日获得了新渠道，昨日运营策略有变化等等。
解决方法是加强对业务的了解，毕竟只是埋头做数据是不可能对业务有更大的帮助的。
