到底什么是数据模型和数据建模

一直比较困惑于在移动互联网中的数据模型设计到底应该是怎么样的?原先在做移动项目的时候,往往有较成熟的eTom模型或者BOSS规范,从初始开始设计时就会从概念模型的角度出发。但现在往往被领导、产品经理、数据分析师所提的名词所困惑住,什么数据模型、数据建模、数据埋点、数据体系、指标体系,很多时候都在混用,但到底每个人心目中的数据模型或者建模又是指什么呢?很多时候这里还貌似没有开发的什么事?我就更迷糊了。

最近和产品、数据的同事有了进一步的交流,把自己的一点体会再理理。不同的角色对于数据的出发点和需求不同,而在一个系统的整体设计和实现中,数据的体现有不同层次,而数据也必然是和产品和业务相结合的。完整的业务模型应该包括数据模型和业务流程。而在数据体系上,从层次上我们可以划分为:指标体系 - 概念模型 - 逻辑模型 - 物理模型。(仓库的底层模型设计虽然不同,但也归结为此列)

在产品设计的角度上往往看到的比较多的是UI界面,大部分PRD中提供的都是一个手机页面再接着一个手机页面,比如:

下载 -》访问 -》注册 -》登录 -》游戏

这个是业务流程,做得比较细的产品经理会在流程上标注出核心的业务数据。这也就是我们现阶段通常所说的数据埋点了。

而从领导的角度来说,他更多看得是产品的成功与否如何来做衡量?这样往往一个产品设计开始就会先制定一些KPI指标,比如用户活跃度。如果指标是多维度的来做衡量的,这就是指标体系。(一个好的指标体系肯定不会是以单个指标来衡量的,比如谷歌衡量用户体验的指标体系提到的HEART)

但是我认为这些都还不是数据建模或者数据模型,数据模型通常是会从中抽象出来概念模型,再经过设计和开发人员逐步细化到逻辑和物理模型。基于业务流程的数据埋点往往会偏重于主流程,分支可能会被忽略,另外维度也很可能考虑不全;而基于指标体系的数据设计关注点也会偏于狭窄,并且指标只是计算的结果,而如何计算得到的才是关键。而要保证从产品设计到最终实现,数据指标定义和提取的一致性,模型的建立和一致的理解还是非常关键的。

我拿网上的一个Facebook设计主管谈如何利用数据做决策来简单分析一下之间的区别:

Julie讲述了自己的产品设计团队通过数据来分析用户是如何利用不同功能的,她以图片上传功能为例进行讲述。她的团队得出了以下几个数据:

  • 87%的用户在第一屏中的相册专辑名字提示框中选择类型
  • 57%的用户打开文件选择功能来选择他们想上传的图片
  • 52%的用户点击上传按钮
  • 48%的用户会等待上传进度完成

问题:少于50%的用户能够成功上传图片

解决方案:为了提高上传成功率,Facebook将Java/flash facebook文件选择功能改成浏览器原生文件选择功能,结果上传量提高11%。为了提高上传效率,在上传前不显示专辑创建功能。

问题:团队发现上传图片的用户中有85%仅仅上传一张图片。

解决方案:团队发现用户不知道使用shift来选择多个图片进行上传,所以加了一个提示,在上传开始前出现上传多张图片的提示。结果数据从85%降低到40%。

纯从这段话中去理解,按以前的习惯我会先列出其中所有的名词:

用户、图片、相册、专辑、第一屏、文件、文件选择功能、上传按钮、java/flash选择、浏览器原声文件选择、浏览器、上传按钮、上传进度、上传量、上传成功率、上传效率、shift选择方式、提示

可以看到短短的一段话中,包含的信息量非常大。(很诧异我们的设计在讲模型的时候几乎没啥,说来说去就是下载、访问、付费)

然后我们来做一些分析,这是一个相册的产品,提供了专辑的管理和图片上传等功能:

首先这里我们可以看到关注的指标上传效率,具体的量化指标是上传量、上传成功率,还可以看到一个隐含指标是单个用户的上传量(团队发现上传图片的用户中有85%仅仅上传一张图片),这是领导关心的(或者应该还是说产品设计团队关心的);

其次我们可以大致了解这个图片上传的业务流程是怎样的,并且把数值量化进去,以最开始添加图片的用户基数为100来计:

添加图片(100) -》创建专辑,选择专辑类型(87) -》选择文件(57) -》点击上传按钮(52) -》显示上传进度 -》等待进度完成(48)

整体的上传成功率为48%,也就是少于50%的用户能够成功上传图片。这是产品设计人员通常意义讲的数据埋点,在这个流程上面如果说做了数据埋点,记录了所有的操作,但却没有能体现Facebook所做的优化点“将Java/flash facebook文件选择功能改成浏览器原生文件选择功能”。另外即使单纯说上传成功率,这里的上传成功率是指所有用户的上传成功率还是所有用户所有上传记录的上传成功率呢?其实没有一个清晰的定义,这里涉及一个如何把一个用户的一次交互行为通过什么标示完成地连接在一起。我们的数据往往不同的行为由不同的系统或者不同的表来做记录,之间是断裂的,到了最后就演变成按用户能大致关联一下就ok了。

那么我们把以上的名词转化为数据模型应该是怎样的呢?画一个简单的概念模型:

facebook sample

这里没有去细画实体的标识和主要属性,但我们会发现在画概念模型的时候,我们会关注其他的一些信息:比如浏览器、操作系统、网络这些维度;我们会关注添加图片、创建相册、选择文件等这些接触记录是需要统一标识;另外我们可以在选择文件中标注选择方式,在点击上传按钮中增加上传类型。数据的记录不再是零散的,而且数据之间是有关系的。

在这个模型画出来之后,我们可以用模型来进行数据的演练,看上文中所涉及的数据或者指标都应该是如何从模型中得到的。比如上传成功率,我们就应该知道是从进度完成的上传记录除以发起“添加图片”的记录;而将Java/flash facebook文件选择功能改成浏览器原生文件选择功能,我们可以从点击上传按钮的记录中根据上传类型获取到。

这样的数据模型表达方式并不是要去替代原有的PRD中的产品流程,它是数据需求描述的补充,在具体的开发设计中又可以根据此概念模型逐步细化到逻辑模型和物理模型。当然貌似这些现在都还是理想。

最后我还是有一个疑问,这样的图该谁来画呢?产品设计人员、数据分析人员、开发设计人员,抑或是得有个数据架构设计人员的角色?以前给移动做项目的时候没有角色细分,也都做了,但现在貌似大家都是各司其职,而且也都没有这样的习惯,该怎么落下去实在是个难题。不过反正现在无地可落,我还是自己先慢慢琢磨着吧。

P.S 好久没有写长文了,新年给自己提点期望,是能静下心来写一两篇比较长的文章。