说明：本文是《Python数据分析与数据化运营》中的“3.5 如何解决运营数据源的冲突问题”。 -----------------------------下面是正文内容--------------------------
多运营数据源冲突指的是来自于多个或同一个系统、环境、平台和工具中，相同业务逻辑的数据其结果不同。根据冲突的差异特征，可分为以下几种类型：
- 数据类型冲突。同一数据对象的数据格式不同，例如会员注册时间这一字段其存储格式有日期、时间戳两种。
- 数据结构冲突。对于同一个数据主体的描述结构有冲突，典型代表是关联主键ID值有不同的逻辑结构，导致后期多源数据匹配和关联尤其复杂。
- 记录粒度不同。对于订单记录的粒度可以存在以订单ID为基础的一条数据，此时多个商品同时存在商品项目列中；也可以使用每条数据以订单ID+商品ID为唯一记录的形式，一个订单可以按商品明细拆分为多条记录。
- 数据值域的定义不同。以订单来看，销售系统中可能包括提交订单、审核中、已审核通过、审核不通过四种；而库存系统中对于订单状态可能包括提交订单、审核通过、商品分拣、商品包装、商品出库、商品配送、配送成功。这些状态还仅仅是正常状态下的正向订单，即从商家发货到客户手中；几乎每个企业也都存在负向订单，通常产生于退换货的场景下，此时从会员发货到商家手中，这类的订单状态会更多。
- 数据值不同。数据值的不同是数据冲突最重要也是最关键的问题所在，也是本节讨论的核心。上述其他的问题大多是格式或定义上的问题，不同的数据源通过ETL过程大多可以解决。但数据值不同的问题却难以判断到底哪份数据是正确的。
这些情况在企业内部运营系统较多、数据源系统复杂时经常出现。需要注意的是，数据的冲突不仅来自于多个不同的系统和工具，有时候也来自于相同（或类似）的系统和工具。
3.5.1 为什么会出现多数据源的冲突
不同（或相同）系统、环境、平台和工具的数据冲突问题需要具体问题具体分析，现以3个实际数据冲突场景为例做详细说明：
场景一内部工具与第三方工具数据冲突
示例：为什么自己的网站统计分析工具跟代理商或广告媒体提供的广告数据有出入，某些时候差异特别大？
对于网站分析工具和广告媒体及代理商的数据差异是难以避免的，有以下几个关键影响因素：
- q 对比指标不同：广告媒体或代理商提供的指标一般是广告浏览量或广告点击量，而网站分析工具的指标则包括访问量、进入次数、页面浏览量等，不同的指标计算逻辑不同，虽然都可以统称为“流量”，但需要具体区分指标。
- 测量的时机不同：即使广告媒体或代理商和网站分析工具都是以计数的逻辑进行测量，前者统计的是在用户点击及点击之前的数据，而后者统计的是点击之后的数据。不同的测量时机会导致数据的不一致。
- 网络丢包的问题：即使前者采用点击量进行统计，后者采用到达量统计，理论上点击一次就会到达一次，但实际上，网络可能存在丢包的问题，所以二者不会完全相等。这一点无法避免。
- 去重机制的问题：很多广告媒体对点击都有去重机制，主要用来屏蔽垃圾点击、恶意点击或蜘蛛点击等作弊流量，而网站分析工具不会主动去重。
- 用户中途退出的问题：在很多时候，尤其是用户不小心点击了广告之后，用户的第一反应是立即关掉广告和对应跳转的页面，此时在广告媒体端会统计到数据，但网站分析工具一般无法统计到数据。
- 页面跟踪加载问题：即使用户中途没有退出，在加载页面时，可能会由于用户没有等到网站分析工具的页面跟踪代码加载完成（大多数跟踪代码在页面底部），用户就已经关掉页面，此时网站分析工具仍然无法测量到该数据。
- 动机导致的数据夸大：大多数广告媒体是相对客观的，但不排除部分广告媒体存在恶意报量、夸大效果的问题，这点以展示类广告（例如门户、banner、弹窗等）为最。而网站分析工具则客观的统计数据，真实记录每一次数据。
- 其他因素：例如网站分析工具没有正确实施广告跟踪或进行后台配置、在站外其他广告页面也出现相同广告参数的URL引用等。
综合来看，大多数情况下站外广告媒体或代理商的数据会高于网站分析工具提供的数据。如果按照正常统计逻辑，站外广告媒体或代理商会提供广告曝光量和点击量2个指标（当然也可以基于这两个指标额外提供了一个CTR，点击通过率- 简称点击率），网站分析工具则可以通过统计进入次数来跟点击量做比对，二者的比值通常称为“到达率”，即用户点击广告之后到达网站的比例。
场景二内部同一个业务主体的同一类数据工具的数据测量冲突
示例：为什么网站上不同的监测跟踪代码对同一个指标的监测数据不一致？例如跳出率。
通常，这种场景中由同一个指标产生的数据冲突会受多种因素影响：
- 指标定义不同。很多时候不同的系统对于同一个指标的定义不同，例如某些网站分析工具对于跳出率的定义是 跳出/进入，而不是通用的跳出/访问。
- 采集逻辑不同。某些情况下，受限于底层代码实施的差异性，同一个指标的采集到的指标会直接受到影响。例如A系统在所有页面都有代码部署，而B系统缺少了帮助中心、活动页等导致采集到的数据缺失。即使都是相同的页面覆盖，不同的采集逻辑、触发机制、异常处理等采集端的逻辑定义都会影响数据采集本身。
- 系统过滤规则不同。复杂的系统都允许用户自定义过滤器，用于过滤或筛选出特定的数据到账户中。例如，白名单、黑名单、IP地址、域名规则等。后端的规律规则不同，必然导致数据值的差异。
- 更新时间不同。不同的系统其数据更新周期可能不同。例如某些工具可以在1小时内完成所有数据的全量更新，而其他工具可能需要1~2个小时才能完成。
- 监测位置不同。位置对于监测数据的影响主要体现在代码触发时机。通常，放在页面顶部的监测代码将比放在底部的监测代码监测到的数据多，这是由于页面默认的加载是自上而下的，处于页面底部的代码会由于页面没有加载完成就关闭或离开页面，而导致无法统计到数据的情况，但此时页面顶部的跟踪代码已经统计到该数据。
场景三内部同一个业务主体的不同数据工具的数据测量冲突
示例：为什么销售系统跟会员管理系统统计的订单数据不一致？
对于二者均为企业内部的订单统计数据的差异问题而言，通常冲突因素由以下几个方面产生：
- 订单来源差异：两个工具对于通常意义下的销售数据来源都有覆盖，例如网站、移动端、线下门店；而对于某些订单来源可能只有特定系统才进行统计，例如坐席订单产生于呼叫中心，可能不走销售系统；大客户团购可能属于销售系统管理，也反映不到会员管理系统；企业分公司之间的商品分拨以及订单转移属于内部流转，也不走会员管理系统等。
- 特殊商品订单跟踪：通常对于实物订单的跟踪比较常见，但某些商品的订单跟踪却有单独的流程和体系，例如虚拟货币、游戏、充值等，这些数据可能无法完整的反馈到所有系统中。
- 订单状态差异：对于销售系统和会员管理系统而言，二者的订单状态往往不同。销售系统对于订单流转的划分更为详细，基于不同的订单状态查询到的结果可能不一样。
- 数据同步问题：销售系统需要与外部第三方平台（例如支付系统）集成时，不同的内部子系统的数据同步可能无法及时同步，基于不同步的数据得到的结果会有差异。
- 内部系统拆单问题：当企业运营模式复杂时，尤其涉及到自营、联营店铺等多种订单形式，通常在1个客户订单下，会分拆为多个子订单，不同的子订单会对应各自店铺不同的订单。对于销售系统而言，这些信息会与库存系统连接而获得完整信息；而会员管理系统可能无法获得后续拆单信息。当基于主订单和子订单分别（以及混合）查询时的得到的结果往往不同。
3.5.2 如何应对多数据源的冲突问题
数据冲突的具体应对没有统一标准，具体取决于后期应用场景和需求，总体上讲应对方法分为三种：
消除冲突并形成一份唯一数据
如果是做全局性的汇总统计，那么需要通过一定方法消除冲突以便呈报一份数据；如果同时呈报多份数据往往会让管理者莫衷一是，而且会对数据工作的价值产生怀疑。
例如：企业级（非部门或中心级别）的数据日报，每天都要看销售报表，来自销售、会员、物流、呼叫中心、仓储等体系的数据一般都会呈现有关销售额的指标，此时需要整合并统一口径形成唯一的销售额数据。
不消除冲突也不作任何处理
如果数据用于数据建模，通常使用的是细粒度的数据而非整体汇总数据，冲突数据记录往往占比很小，因此可以忽略冲突。具体使用哪些数据都不会对后续建模结果造成显著性影响。
不消除冲突但是使用全部冲突数据
如果在做基于整体的流程性统计分析时，会用到不同业务流程的不同数据，此时不同的指标之间会具有较好的漏斗转化效应，基于此可以做全流程的漏斗转化分析。此时的漏斗是一个非封闭性的环节。例如广告曝光→用户到达网站→加入购物车→订单提交→形成有效订单→订单配送→订单签收。
提示 即使不消除数据冲突，我们也一定要谨慎对待这种情况，绝不能听之任之，更不能对数据冲突视而不见。对于冲突的数据而言，通常需要关注以下两方面：
- 一是差异性：对相同实体在相同逻辑下的数据冲突（差异）应该在5%以内，如果条件不具备的可以放宽到10%。尤其对于数据准确度要求较高的订单、支付等更要谨慎分析、严格把关，过大的差异说明在跟踪、采集、同步、计算和统计逻辑上一定有问题。
- 二是稳定性：由于各种主客观原因，数据冲突（差异）无法完全消除的情况，需要确保多源数据的差异性相对稳定，不能出现数据差异时高时低甚至相反分布的状态。否则可能意味着其中至少一份数据出现严重问题，这也是数据校验的基本原则之一。