数据分析产品设计中，有哪些坑需要注意（二）

作为刚转行成为产品经理的1年新人，笔者将分享在产品设计中踩过的那些坑，给入门的新人一些提醒。

上一篇《数据分析产品设计中，有哪些坑需要注意》，已经从需求分析到需求设计，再到开发及测试，对整个工作流程中的大坑有了一个大致的介绍。

本次主要是笔者从指导技术进行开发以及在平台上线的实际运行过程中发现的一些问题，进行反思，分析产品设计工作中应该注意的一些坑。

一、产品背景概述

笔者为某政府设计打造的数据分析产品，独立于他们的业务办理系统的（业务系统共有10+套，都是不同的厂家建设），不生产数据，只消费数据。

数据分析产品中所有的数据来源均来自于各个业务办理系统，对于这些数据，数据分析产品只做3件事情：业务数据关联展示、数据关联分析统计、数据关联分析风险识别。

以下将举3个例子来说明产品设计中应该遵循的设计原则。

二、事例 1、数据分析产品中的展示业务数据和业务系统中的业务数据不一致

现象

在产品上线使用之后，客户在验证业务数据的准确性的时候，发现数据产品中的业务关联展示数据，与实际的业务办理系统中的数据存在出入，数据相差幅度大约有30%～50%。

由于数据维度很多，这里仅举例其中一个数据维度即可。如A类性质的案件数量，在业务系统中有500件，但在数据产品中，展示出来的A类性质的案件数量仅有300件左右。

分析

根据问题现象，笔者主要从由表及里进行了分析:

1）从表象层数据查询维度进行分析，主要是梳理查询的过滤条件。

业务系统中的过滤条件是A、B、C三种，但是在数据产品中的过滤条件却是B、C、D。笔者从这个维度找到了原因之一，但不确信是否是根本原因。因此在此处需要做假设验证——如果过滤条件一致，即排除C和D的过滤条件的数据差异（可以大概估算），数据产品和业务系统中的数据差异数量。

笔者发现至少还相差了20%左右，因此笔者认为还有更深层次的原因。

2）从里层，即数据层，主要梳理源数据的情况。

根据业务系统的过滤条件，笔者找到开发直接在数据库进行过滤查询，对比分析数据情况。

从这个维度，笔者发现了两个原因：

是数据同步不全，缺失案件数量，同步到数据产品中的案件数量缺失了10%；

是建立的数据清洗规则存在问题，即建立的数据库表的字段不全，清洗的数据内容不全。

结论

由此得出的对产品设计的两点思考结论：

一是数据分析产品尽量要保证基础源数据的规则不变，如过滤条件等（也就是数据的统计规则以及查询习惯需要跟业务系统的数据统计规则和查询习惯保持一致）。

二是要分清楚数据分析产品的风险识别是风险识别，业务数据是业务数据，千万不要把风险识别的数据混合在业务数据中进行产品设计，这样开发在建立数据清洗规则的时候，有很大可能会存在问题。因此我们的第一原则就是保证业务系统中的数据，原汁原味清洗到数据分析产品中来。

2. 数据分析产品中的数据关联分析数据有问题

现象

某政府的业务办理涉及多个系统的衔接，链接起来就是一个完整的业务办理流。数据产品的开发过程涉及多家公司的数据对接，每家公司的数据规则都不同，所以做数据关联分析的困难可想而知。

目前上线的产品，只有弱关系关联展示，而客户希望展示强关系关联分析展示。

举例说明：

当前的业务办理分为A、B、C、D四个环节，每个环节的系统不一样。

当前上线的数据产品，在业务办理的流程关联展示的过程中，只是从宏观的层面分析A环节的A1、A2、A3….各类不同的业务流向的数据量大小，其中A2类和A3类是流向B环节的业务数据。

在B环节的的所有业务被清洗为B类业务，又展示B环节的B1、B2、B3…..各类不同的业务流向的数据量大小。这里是无法关联上某一起案件，在A环节流向B环节的业务流向的。而此需求也是客户的痛点。

分析

根据问题现象，笔者主要从数据结构和数据内容进行了分析。我们的核心诉求就是A类系统中的案件要和B类系统中的案件一一进行对应。因此围绕此核心诉求，通过定型分析和定量分析来确定强关联的方式。

由于没有唯一一个键值进行关联，因此需要从多个维度来确定一一关联的关系。笔者通过2个系统的数据内容进行对比分析，发现两个不同系统的数据字段不一定相同，但数据内容是一致的，得出A、B、C、D…几个字段内容都一致。