一 背景
越来越多的公司正在建设数据仓库或数据湖，并开始集中他们的数据或者已经完成了数据集中项目，并正在努力使整个组织的数据服务自助化。这种方法有很多好处:
•更灵活的分析和解释数据。
•构建用户的完整画像。
•数据堆栈变得更加模块化。
当组织的数据越来越复杂时，灵活性是关键。我们希望将业务逻辑应用到数据中，例如构建自定义属性模型、仪表板和报告，以反映业务中最重要的指标，而不是基于供应商的行业的僵化模型。模块化为组织提供了选择和控制的能力，更主要是限制了供应商的锁定，组织可以为堆栈的每一层选择更好的工具，而不是依赖于一个供应商进行收集、存储和可视化数据。同时也带来了新的挑战:大量原始的、事件级的数据来自于大量的来源，这也就是数据建模的作用所在。
二 什么是数据建模
数据建模是使用业务逻辑聚合事件级数据以生成便于查询的“建模”数据的过程。当我们进行数据建模时，通常会聚合事件级数据。虽然每一行事件级数据代表一个单独的事件，但每一行建模数据代表一个更高阶的实体，例如工作流或会话，它本身由一系列事件组成。数据建模包括清理数据，例如删除测试记录或由IP地址识别的内部流量。它还包括创建关于数据结构及其关系的元数据，允许工具使用上下文对数据进行操作。
数据建模使用业务逻辑为原始的事件级数据增加了意义。我们可能会查看数据，并决定记录的页面浏览是新回合的第一页，或购买漏斗的第一步。我们可以从记录的cookie ID推断出实际用户是谁。我们可能会在使用相同cookie ID记录的其他数据点的上下文中查看数据点，并推断用户的意图(例如，她正在搜索特定的产品)或推断某些东西，更普遍的用户信息(例如，她对红裤子感兴趣)。这些推论是基于对业务和产品的理解。这种理解是一种不断发展的东西;因此，当我们更改业务逻辑时，也会更改数据模型。
我们通常以SQL作业的形式编写数据模型，在数据仓库中运行。这些作业难以编写和维护的原因有很多，但一个大问题是聚合事件级数据很困难。这是因为:
•通常更想了解由多种不同事件类型组成的用户行为过程，这些不同事件类型收集了不同的字段。这些不能直接进行聚合。
•通常会对事件的顺序感兴趣。只知道用户执行了A、B和C通常是不够的，我们关心她是先执行了A然后执行了B然后执行了C，还是先执行了A然后执行了C，还是先执行了C然后执行了B。SQL函数通常不擅长识别不同的序列，也不擅长让分析人员对不同的序列进行聚合。
三 为什么数据建模很重要
一旦开始将所有数据放入数据仓库，数据模型如果实现正确的话，将是你最好的朋友！
数据建模是将组织中的事件级数据自助化应用的一个重要步骤。数据建模的要点是生成一个数据集，使不同的数据消费者(例如，市场分析师)能够使用基本的SQL技能轻松地使用它。通常，建模数据将使用一个或多个商业智能工具跨业务进行自助化服务。
限制对原始事件级数据的访问，并将数据模型整合到上游，这意味着可以在整个组织中实现和维护业务逻辑。它还使数据访问更加大众化，查询原始数据的阈值(例如，必须连接多个表)比查询建模数据的阈值要高得多。成功的数据团队使用他们喜欢的工具，预先授权营销、产品团队和其他团队，为与他们的项目和用例相关的报告提供服务。
三 原始数据和建模数据的概念
当谈到数据管理的最佳实践时，原始事件流应该是不可变的，而建模数据是可变的。总是有可能一些新数据或业务逻辑的更新会改变我们理解过去发生的特定事件的方式，因此我们可以对数据模型进行更新以反映这一点。
这与作为数据建模过程输入的事件流形成了鲜明的对比:事件流是已发生事件的不可变记录。当我们记录新事件时，不可变记录会随着时间增长，但是已经记录的事件不会改变，因为每个事件捕获的不同数据点不处于争用状态。这可能是我们解释它们的方式，而这只会影响建模数据，而不是原始数据。
因此，有两个不同的数据集，它们都代表“已经发生的事情”。原始数据是对业务中发生的所有事情的一种没有主见的描述。这是一个全面的记录，应该针对可审核性和完整性进行优化，而不是针对特定的查询模式。另一方面，建模的数据提供了易于使用的表，这些表汇总了关键的分析单元，便于查询。
四 决定你的业务逻辑
数据建模很大一部分是将业务逻辑应用于未绑定的数据。因此，在开始建模之前，需要对业务逻辑达成一致，并将其集中起来。如何定义转换?是想以最常见的方式(30分钟不活动)定义会话，还是有另一种方式来定义更适用于业务模型的会话?
集中此工作需要避免任何混乱，特别是当多个团队参与建模工作时。以下是一些需要考虑的关键参数:
•会话
•时间
•转换
•流量来源分类
这似乎需要更多的前期工作。毕竟，依赖逻辑和建模分析供应商(如谷歌analytics和Adobe)更简单，但失去了自己拥有和开发逻辑所获得的所有灵活性。对于大多数零售商和电子商务公司来说，谷歌和Adobe的数据模型将适合他们的用例。这些巨头已经为零售商建立了自己的平台和逻辑——转换和目标跟踪、漏斗分析等都是针对传统电子商务客户旅程进行优化的。也就是说，许多企业都在努力让谷歌和Adobe为他们服务，例如，如果你是一个拥有两个截然不同的买家和卖家群体的双面市场，或者是一个希望了解留存率的(手机)订阅业务。假设你是一个招聘市场，求职者和招聘人员在你的平台上互动(两个不同的用户群体，行为不同)。当一个求职者在找工作时，在网站上搜索一次可能会得到五份求职申请。这意味着传统的渠道或转化率将变得毫无意义。
五 数据建模的例子
有许多方法可以对数据进行建模，以使其更容易查询和使用，最终，建模的方式将取决于您的业务逻辑和分析用例。如果为了在BI工具中进行可视化而对数据进行建模，则需要遵循BI工具所需的逻辑，或者在BI工具本身中进行建模。在下面的小节中，将概述几个不同的数据建模示例的基础知识。
从微事件(如视频视图)建模宏事件，“宏事件”由微事件组成。创建宏事件或汇总表使通过简单的分组和聚合函数询问和回答有关事件流的问题变得容易得多。
例如，如果我们是一家视频媒体公司，可能想了解单个用户如何与单个视频内容项进行交互。
在上面的示例中，我们建模了一个事件流，该事件流描述了用户与特定视频之间的所有微交互，并将其放入汇总表中，汇总表记录了每个用户观看的每个视频的一行数据。注意汇总表包括:
•查看器信息(特别是用户ID)。这意味着可以很容易地比较不同用户类型之间的消费模式。
•视频信息(主要是视频ID)。这意味着可以很容易地比较不同视频类型的消费模式。
•用户视频交互汇总信息，即用户是否完成视频，用户是否分享视频?通过上面的汇总表，可以很容易地进行比较，例如根据用户类型和视频类型查看数据或用户粘性。
(1)建模工作流(例如，注册漏斗)
通常，我们感兴趣的是理解事件的顺序，这些事件表示用户与特定工作流交互的方式或朝着既定目标工作的方式。下面是一个用户与旅游网站交互的例子:
我们的汇总表将事件级别的数据汇总到一个单独的工作流级别，其中每个工作流表示从用户执行搜索开始的旅程，并在用户:
1.购买的一个搜索结果,或
2.执行另一个搜索，或
3.完全退出。
我们的汇总数据表包含了很多有趣的数据，包括:
•关于执行的初始搜索的数据。这是将从工作流中的早期事件中获取的数据。
•关于用户交互的实际结果的数据:哪些结果被选择了，它们在结果中的排名是什么。
•用户选择并继续购买的结果(如果有)。这些数据将从工作流中稍后的事件中获取。
再次，注意建模数据应该如何易于使用。我们可以很容易地比较不同目的地的搜索数量，比较不同目的地的转化率，并探索排名较高的结果是否更有可能被选择并购买，并看看这在用户类型、位置和其他关键数据点上的变化。
(2)建模会话
构建会话表是将事件级数据聚合为更小的数据集的一种方法。会话表示用户活动的连续流。在web中，当一段30分钟的时间过去且没有发生任何事件时，通常会将会话定义为结束。
我们不喜欢将会话作为唯一的分析单元(一些分析供应商仍然在一切方面都遵循会话)。例如，如果你是一个招聘平台，你可能想要查看从用户第一次搜索工作到他们申请工作的时间段，简单的聚合会话并不能告诉你你的平台有多有效。在某些情况下，查看会话显然是有意义的，例如，如果你是一份报纸，了解用户在给定会话中阅读了多少文章可能是很有趣的。
典型的聚合将包括以下数据:
•用户是如何获得的(来源)
•会话开始的地方(例如“登陆页面”)
•会话持续了多长时间
•会话的“价值”是什么(例如，是否发生了转换/事务?广告收入是多少?)
•用户在会话中试图完成什么?
使用我们的会话表，我们可以回答诸如哪些会话包含转换、会话长度如何随时间变化以及何种类型的会话会影响转换或导致用户流失等问题。
(3)建模用户
一个非常有用的表是用户表——随时间聚合用户的事件历史记录。这样的表可以与来自CRM系统的数据连接在一起(例如，如果客户服务代理在使用您的产品时遇到问题，可以向他们提供帮助)。
一个典型的用户表将包括以下数据:
•创建用户帐户
•用户活动
•交易数据(如交易数量LTV)
根据整个用户历史，我们可以根据用户获取时间或最初获取方式将用户划分为不同的群组，将用户划分为不同的行为部分，并根据他们迄今为止的行为计算个人用户的实际和预期终身价值。
六、通过数据建模实现数据自助服务
最成功的数据团队会建立数据基础设施和平台，使组织中的数据访问民主化。如果没有它，数据团队将经常需要花费时间用报告和特别分析来支持其他团队(例如营销或产品)。
特别是当正在着手一个数据集中项目时，我们希望确保团队被授权，并对他们所使用的工具和数据感到舒适。例如，如果您的营销部门已经习惯于使用谷歌Analytics，那么您就不能使用基于sql的可视化工具来代替它。
根据经验，最成功的数据团队，无论大小，在数据集中项目之后立即进行全面的数据建模(包括所有相关数据源)和强大的可视化工具时就会成功。市场营销人员会接受你的解决方案，当他们被授权为自己服务，并看到他们突然拥有的机会;例如，构建自定义模型，考虑更多来源，如广告印象、应用安装、取消/退货等。
通过可靠的数据建模和基本的SQL培训，数据团队授权其他团队自助服务，可以将他们的时间集中在构建数据驱动的应用程序或产品上，而不是编写微不足道的SQL查询来支持产品分析师的每周报告。
