一、前言

最近几天在了解公司的一个业务，在看前同事做的一个面板的时候，看到一组数据，有点纳闷（根据相关逻辑替换数据后的结果如下）。总流失率竟然比添加流失率还高！虽然只高了一点点，但是看着还是很奇怪，难道不是同一条路径下的？

相关统计数据如下：

二、探索数据“奥秘”

补充一个业务逻辑：新客进来之后会有一个分配企业号和添加企业号的过程，对应的会有分配的人数和添加人数，现在就是统计一下各个环节的流失率。
流程：获客->分配->添加

首先看一下统计逻辑是否有问题：

注：分配流失率和分配占比相加为1。

从统计的算法上看，将正常的数据相除，然后用1减去正常的数据，那就是流失部分，似乎没问题！
那为什么会少了呢？添加流失率还要乘以一个分配占比，这层漏斗也不是百分百，乘积肯定要比添加流失率小，但实际得到的总流失率却“逆势上涨”了。

接下来我把1合并到分数中去，再观察，发现漏洞显现出来了：

不知道你发现了没，如果没有我换个方式展示再看看：
先来算下通过拆分逻辑统计的总流失率：

再看看原来统计的总流失率：

分子在计算的过程中已经变了，原本是获客人数-添加人数得到的未添加人数，到后来变成了分配人数-添加人数，所以得出来的结果，就是总的流失率比局部的还要大。

怎么避免这样的问题发生呢？多算一步即可，把未添加人数算出来，如下：

之后直接采用未添加人数，避免出现以上逻辑漏洞。

最后得到的流失率应该如下图：

三、小结

从事数据工作这么久以来，接触过一些同事做好些需求都是在做逻辑正确的事，根据逻辑正确的逻辑取出相关数据，然后就直接丢给需求方，然后需求方一看数据，漏洞百出，返工！（当然，更多时候可能是“信以为真”，直接使用，因为需求方可能也对这个数据没有概念。后来换一个人取相同的数据，就会发现，对不上了……）

逻辑正确的事做起来是相当轻松的，但是生产中的数据可能会有各种各样意想不到的“惊喜”干扰着正确的逻辑，所以需要做适当的数据清洗。验证数据是一件比较耗时间的活，需要你基于数据的一些维度验证数据是否有问题，有时候还要对业务有较多的了解。不过，验证数据也不是很难做到，沟通需求的时候，一般会了解到需求方的目标等，取完数据后，可以把自己当做是需求方，我拿这个数据要看什么什么，反复多看几遍，很多不符合逻辑的bug基本都可以揪出来。

作为数据工作人员，我奉承数据准确是一个基本原则，虽然常有时候费尽千辛万苦才把数据取出来，但是如果最后没有对数据准确性做验证，导致数据不可靠，那也是白搭！