随着各行各业向数据化运营/精细化运营转变，数据产品越来越被大家所关注。作为B端产品的一个重要组成部分，数据慢慢成为产品设计和商业决策不可或缺的部分。尤其是诸如智慧城市、智能建筑等专业服务类的B端数据产品，也是为客户提供数据运营和决策支持的。这类数据产品本身的计算、决策越多 ，客户需要的思考就越少。所以作为这类数据产品的产品经理，要清楚的知道自家产品的数据特点，以便选择正确的设计策略。
这类数据产品面向的是少量企业级客户，核心诉求是高效满足他们的数据应用需求，使其核心业务形成商业闭环，带来更加高效的理性决策，所以如何做好“面向企业高层决策支持型&面向企业客户数据应用型”的数据设计是每一个B端产品经理都要面临的挑战。
数据层设计的核心是数据仓库，目的就是能够让客户方便地访问大量数据，允许他们查询自己想要的数据，分析其中有价值的信息。这就要求数据仓库的设计必须满意以下数据要求：
1．安全性
B端产品中含有机密和大量敏感的数据。为了能够使用这些数据，必须有适当的授权机制。这意味着只有被授权数据才能被特定用户访问。
如果增加安全特性则会影响到数据仓库的性能，因此必须提早考虑数据仓库的安全需求。当数据仓库已经建立完成并开始使用后，此时再应用安全特性会比较困难。在数据仓库的设计阶段，我们就应该进行如下事项：
数据仓库中的数据对于最终用户是只读的，任何人都不能修改其中的数据；
划分数据的安全等级，如公开的、机密、秘密、绝密等；
制定访问控制方案，决定哪些用户可以访问哪些数据；
设计授予、回收、变更用户访问权限的方法；
添加对数据访问的审计功能；
2．可访问性
能够快速准确地分析所需要的数据是辅助决策支持的关键。有了数据的支持，业务就可以根据市场和客户的情况做出及时地调整。这就要求用户能够有效地查找、理解和使用数据。
数据应该是随时可访问的。这里数据可访问性指的是用户访问和检索指定数据的能力。数据仓库的最终用户通常是业务人员、管理人员或者数据分析师。他们对组织内的相关业务非常熟悉，对数据的理解也很透彻，但是他们大都不是IT技术专家。这就要求我们在设计数据仓库的时候，将用户接口设计得尽量友好和简单，使得没有技术背景的用户同样可以轻易查询到他们需要的数据。
3．自动化
这里的自动化有狭义和广义两个层面的理解：
狭义的自动化指的是数据仓库相关作业的自动执行。比如ETL过程、报表生成、数据传输等处理，都可以周期性定时自动完成。
广义的数据仓库自动化指的是在保证数据质量和数据一致性的前提下，加速数据仓库系统开发周期的过程。
整个数据仓库生命周期的自动化，从对源系统分析到ETL，再到数据仓库的建立、测试和文档化，可以帮助加快产品化进程，降低开发和管理成本，提高数据质量。
4、准确性
想要数据仓库实施成功，业务用户必须信任其中的数据。这就意味着他们应该能知道数据从哪来，何时抽取，怎么转换的。更重要的是，他们需要访问原始数据来确定如何解决数据差异问题，并且知道这些能访问到的数据和他们日常提交的数据报表之间的转换逻辑。实际上ETL过程应该总是在数据仓库的某个地方（如ODS）保留一份原始数据的复制。
5、时效性
用户的时效性要求差异很大。有些用户需要数据精确到毫秒级，而有些用户只需要几分钟、几小时甚至几天前的数据就可以了。数据仓库是分析型系统，用于决策支持，所以实践中一般不需要很强的实时性，以一天作为时间粒度是比较常见的。
6、可溯性
数据仓库更多的价值体现在它能够辅助随时间变化的趋势分析，并帮助理解业务事件（如“华北区的小张，谈一单成一单，成交的这些客户有什么共同特征吗”）与经营绩效之间的关系。这就是需要每一项决策结果都能溯源到原始数据。
原始数据往往是一些未经加工的数据表格，看起来单调枯燥，但是这些数据却能很好的帮助我们挖掘出来符合业务问题需要的准确的表达方式，从这些数据中找到数据的变量、不同维度数据间的关系，这样我们就能逐步的找到数据的层次结构以及合适的图表化展示。
可溯性能通过这些源数据试图找到帮助业务团队、管理层所关心的那些问题的答案，这些洞察可以帮助于我们了解他的原始诉求和痛点，以便我们找到正确的解决方案。
7、可验证
其实，数据产品本身的业务逻辑和产品设计已经很复杂了，再加上又是面向千人千面的B端企业客户，让这种复杂性又难上加难，所以在设计、测试和验证时不能仅凭假数据就去模拟真实的使用情况。
客户用我们的数据产品去解决现实中的复杂问题，所以我们要深入了解每个数据所代表的含义,理解每个数据之间的关系，各种可能的展示情况以及极限情况。所以， 如果我们胡乱填写的假数据很可能无法反应真实的使用情况，从而将一些问题掩盖掉。相反，使用真实的业务数据，客户就会被带入到自己的实际使用场景中去，并想象当下的数据方案是否能够解决他们的问题。在此测试场景下暴露出来的问题才是客观真实的。
网友评论