数据处理中的准确性问题
作者：互联网
本文由神策数据联合创始人 & CTO 曹犟撰写，数据处理分为五大步骤：数据采集、数据传输（实时/批量）、数据建模/存储、数据统计/分析/挖掘、数据可视化/挖掘。曹犟结合神策数据服务于数百客户的实际案例，分条目解读了神策分析对于提高数据准确性做出的针对性技术解决方案。
所有与数据有关的应用，不论是基础的数据统计，更复杂的数据多维分析，还是个性化推荐、用户画像等更加深入的应用，对于数据准确性都是有较高的诉求的。数据的准确性，直接影响数据应用最终的呈现效果，也从而影响基于数据的商业决策和产品智能效果。
神策分析作为新一代的用户行为分析产品，很多客户使用我们来替代上一代的流量统计产品，或作为自有数据系统的补充和延伸。在这种情况下，客户对于数据准确性自然会有不同系统之间进行对比的要求，例如，对比神策分析与上一代流量统计产品在关键指标上的差异，对比神策分析与自有数据系统的数据细节差异等。
在协助客户进行这些数据对比的时候，我们也对数据处理过程中的准确性问题有了更加系统的认识，并且在整体的产品和系统设计上也做了很多相应的处理，在这里一并分享给大家，希望能够对大家有所启发。需要特别说明的是，数据伪造、窃取等问题，在数据采集中的安全与隐私（见官网博客）这篇文章里面已有讨论，本文暂时不做深入展开。
2 数据处理五个步骤对于大部分数据应用来说，数据处理都可以划分为如下五个步骤：
在这五个步骤中的每一步，都会面临数据准确性的问题，并且神策分析也相应地进行了针对性的处理和应对，下面结合我们之前的一些实际的应对案例，进行详细介绍。
2.1 采集环节的准确性问题与应对
数据采集这个环节，一般而言，会是准确性最常出问题的环节之一。我们在实际服务客户，进行数据校验和对比的过程中，也积累了相当多的经验，在这里共享给大家。
在这个环节，准确性问题会有两大类：
一类是与人有关的因素。例如，由于粗心或某种原因，在部分页面没有嵌入 SDK，遗漏了对某个关键操作的采集，或者在某个关键的代码埋点处采集错了某个重要的属性。整体上，一般软件开发过程中可能有的人为错误，在这里都有可能出现。
另一类则是与人无关的，纯粹技术性的因素，下面是一些非常典型的问题，与大家分享：
在 iOS、安卓 App 上进行客户端数据采集时，为了不影响用户体验，通常都是在客户端本地做好缓存、压缩、加密等，然后在网络良好的时候会尝试异步发送数据，这也决定了这些数据的时间只能以客户端时间为准，并且有可能事件发送时间与事件发生时间有较大间隔。除此之外，少部分用户的手机有可能连时间都不准确，这些都会造成最后采集的数据不准确。
在 iOS 和安卓 App 上进行新用户激活的判断时，常见的方案是在本地 ROM 上存储一个标记文件或者类似的方案，用于标记这个设备上是否是首次激活本 App。但是，一旦用户卸载然后重装这个 App，这个标记也会随之失效，从而导致首次激活判断错误。
在 H5/Web 界面上进行客户端采集数据时，都是以 JS SDK 的方式进行的，如果碰到部分异常流量无法触发 JS，则 JS SDK 是采集不到这些用户行为的，在这种情况下，如果和 Nginx 日志等进行对比，则数据也无法一致。
部分第三方统计分析工具由于技术限制，对于除预置属性以外的其余自定义属性有较多限制，例如自定义属性只能有有限个，自定义属性的取值也只能是有限个等，这样其实客观上导致了数据采集能力有限，没有办法采集到所需要的数据，从而影响数据的准确性。例如，某个漫画类的 App 想采集每一个漫画页面的阅读量，把漫画名称作为一个自定义属性，但是，在实际使用某免费的第三方流量统计工具时，却发现这个自定义属性最多只能有 10 万个取值，而漫画名称又远远不止 10 万个，从而导致采集的数据并不准确。
对于采集环节这些人为的或者非人为的数据异常的因素，基于我们以往处理这方面问题的经验，我们在产品和服务层面，提供了以下方案进行处理：
产品实现了多项目机制，专门为客户提供用于测试与沙盒的“测试项目”，来完成数据采集的开发和调试，并且在上线之后，可以将测试项目的元数据同步到正式项目。
为每一个数据采集 SDK 与数据采集工具，都提供了专门的 Debug 模式，与“测试项目”和“导入数据实施查看”功能相配合，在开发过程中，就可以直观地看到采集的数据，从而很方便地对数据采集的结果进行调试。
产品提供了独特的“埋点管理”功能，对于各种不同端的 SDK、采集工具部署的埋点，都进行实时的监控与管理，直观地看到数据采集的进度和数据异常。
对于客户端 SDK 采集的数据，在架构上做了最大的努力进行优化，保证对于之前就发生并且被采集到却由于网络原因最近才接收到的数据，也能够准确地按照行为发生的时间进行回溯，从而准确地接收数据，并最终准确地还原用户行为。而对于上一代的统计分析产品而言，由于它们本身的架构设计与统计口径，导致它们无法很好地回溯这些之前采集的数据，所以在进行对比时，会有数据差异。
对于客户端本身时间错误的问题，我们也一直在尝试在 SDK 中增加对采集的事件时间进行对时的功能。目前初步的思路是在每次成功的数据发送请求后，都根据服务端返回的准确时间，对采集的数据中的事件发生时间进行相应得修正。
对于卸载重装 App 导致首次激活判断错误的问题，我们建议客户采用不会随着卸载重装改变的设备 ID 或者用户注册 ID 作为用户标识，并且将这个判断逻辑移到服务端，从而解决了这个问题。
对于异常流量不会触发 JS 导致 JS SDK 无法抓取到数据的问题，我们应该意识到，这些连 JS 都不会触发的流量不会是正常用户的访问，对于这些数据，在绝大部分情况下，不采集反而是更好的一种方案。除此之外，对于部分反而会触发 JS 从而被采集到的 spider 等类型的机器流量，我们也根据 UserAgent 等特征做了相应的标识。
神策分析在数据采集能力上，支持最多上万个的自定义属性，每一个自定义属性都支持六种类型，并且在取值上没有任何限制，从而让使用者能够采集。
2.2 传输环节的准确性问题与应对
传输环节，一般主要是指通过客户端 SDK 等采集到数据，然后通过网络发送给数据平台。由于一般是走 HTTP 协议通过公网进行传输，所以肯定会面临网络异常等错误。
对于 JS SDK 而言，由于语言特性与网页本身的处理机制，目前并没有太好的方案来解决网络异常等。根据我们这么多年的处理经验，JS SDK 一般会由于网络原因带来 3% 到 5% 左右的数据丢失。
对于 iOS 和安卓 SDK，相比较 JS SDK，在网络异常时可以有更好的处理方案，例如，当由于某些数据没有成功时，依然缓存在本地，直至发送成功时才从本地把这些数据去掉。所以，一般而言，iOS 和安卓 SDK 的数据发送会有 99% 以上的完整性。但是，在某些恶劣的网络条件下，有时候依然会出现，数据已经成功发送了，但是本地得到的接口返回依然是错误，从而下次会重复发送这些数据，导致接收到的数据会重复。神策分析在接收端有相应的去重逻辑，解决由这种原因带来的数据重复问题。
当然，在神策分析产品发布之初，我们就提供了服务端数据采集的解决方案，让客户可以通过内网来传输数据。所以，我们一向推崇，如果同一个行为在客户端和后端都能够采集到，那么优先推荐在服务端采集，通过内网而不是公网传输，能够有效地规避传输中的网络异常问题，保证数据的准确性。当然，附带地，也一并解决了传输过程中的安全与隐私问题。
2.3 建模与存储环节的准确性问题与应对
建模与存储环节，主要碰到的问题大概有：
由于硬件或者软件问题，导致存储的数据丢失或者损坏，从而影响数据的准确性。
由于数据模型的限制，导致历史数据无法回溯，从而影响数据的准确性，这一点在大部分上一代流量统计工具中存在。
由于存储方案的限制，导致已经导入的数据无法修改或者删除，从而在数据有错误的时候也无法修正。
针对这些问题，神策分析采取了如下一些方案进行应对：
基于 HDFS 的分布式存储，每一份数据都会存储多份，因此，当硬盘损坏，机器故障时，依然会有完整的可访问的数据。
采用了更加灵活高效的数据模型，可以回溯过往的历史数据，保证数据的完整性。
提供了分事件、日期的数据删除和重导机制，用于修复数据，最大限度保证数据的准确性。
2.4 统计分析环节的准确性问题与应对
我们在协助客户进行数据对比时，经常也会在这个环节碰到一些准确性方面的问题，最常见的有：
查询或者计算过程的 bug，导致最终的统计和计算结果不准确。
不同的系统、工具，对于同一个指标，有不同的统计口径，即使采集的数据完全一致，最终的计算结果也可能有较大差异。
对于这些问题，我们是采用了如下一些方案：
神策分析对于任何一个分析模型，都积累了非常丰富的测试用例以及完全自动化的测试系统，尽可能保证神策系统本身的计算正确性。
对于自身的每一个指标的计算口径，我们都提供最为完善的说明与样例，同时，我们也会尽量弄清楚其它第三方统计系统的各个指标的计算口径，以便在协助客户进行数据对比时，能够准确地说明问题。
神策分析本身具有任意指标上的任意维度的下钻和筛选的分析能力，部分其它第三方分析工具在一些固定维度上也可以进行下钻，这也便于进一步找到数据差异的关键点。
与部分第三方统计系统不同，神策分析可以提供最细粒度的用户行为数据，从而可以从最原始的数据层面对数据进行核对和分析。
下面是几个我们协助客户进行数据对比时的真实案例：
某客户需要对比神策分析与某免费流量统计工具 U 的活跃用户数，由于神策分析在该客户的 X 版本才集成，所以就选择对比 X 版本上的活跃用户数，然而，在一开始，数据始终存在较大偏差。在经过仔细阅读工具 U 的文档后，我们发现，如果一个用户在今天从 App 版本 X-1 升级到版本 X，则他会算作版本 X-1 的活跃用户，而不算作版本 X 的触发用户，这主要是由于工具 U 的计算方案上的限制。而对于神策分析而言，如果一个用户在今天从 App 版本 X-1 升级到版本 X，则他会算作版本 X-1 的活跃用户，也会算作版本 X 的触发用户，并且在计算今天不分版本的整体的触发用户数时，也会对之进行去重。在与客户说明清除这些计算差异之后，很快得到了客户的认可。并且，随之客户 App 新版本升级完成之后，整体的数据差异也很快减少到了可以接受的程度。
某零售客户需要对比神策分析中的购买事件的总金额与他们自有数据库中订单表的总金额，选择了具体的某一天进行对比，发现总有极少的差异。在仔细核对了原始数据后，发现神策分析的购买事件的时间，是用户在 App 与网页上提交订单的时间，而客户自己的数据库中，则是以订单的最终更新时间为基准。因此，在计算某一天的购买总金额时，会出现微小的差异。
2.5 可视化与反馈环节的准确性问题与应对
在这个环节，一些常见的准确性问题包括：
可视化界面本身的 bug 导致的数据不准确。
可视化界面本身的展示限制，所导致的数据理解上的偏差。例如，在网页上展示分析结果时，如果展示的行数过多，可能直接导致浏览器崩溃等，为了避免这些问题，通常只能对数据做一些截断处理，这也会导致没有办法准确地看到数据的全貌。
针对这些问题，神策分析采取了如下一些应对方案：
实现了前端的自动化测试框架，自动完成前端的正确性测试，以避免由于程序 bug 导致的问题。
针对浏览器显示阶段的问题，提供了下载 CSV 文件和 API 获取全量分析结果等方案，使得使用者可以获取全量完整的数据。
简而言之，数据准确性是一切数据应用的前提，神策分析作为一款商业用户行为分析软件，自然也为此进行了很多的投入。结合我们在为数百家客户服务的过程，以及之前整个团队在百度从事大数据相关工作的经验，我们对于处理数据准确性问题已经积累了丰富的经验。一方面，我们会根据这些经验进一步优化和改进我们的产品，另一方面，我们也会将这些经验迁移到我们客户的实际使用场景，为我们客户的数据校对工作提供最为细致的服务。
你或许还想了解
深度案例 | Formax 集团如何构建高效金融客户分析体系？
神策数据与 IPIP.NET 强强联合，精准 IP 让用户行为分析更精确
标签：分析,问题,神策,准确性,采集,数据处理,数据,SDK 来源： https://blog.51cto.com/u_14438762/2903552