Metabase学习教程：系统管理-3

保持条理化

当用户、问题和仪表盘的数量不可避免地增加时，如何保持分析的组织性。

如果您想保持竞争力，您需要让组织中的人员访问他们需要的数据，以便做出更好的决策。然而，这种数据自主化的代价是不可避免的大量分析——这会使你很难知道哪些分析值得信任。

重要的是要明白这个问题是没有办法解决的。总有一定程度的分析熵需要驯服，但是有了合适的工具和流程，你就可以控制不可避免的混乱。

自主化分析的问题

这些问题的核心集中在定义上：我们如何准确地定义业务逻辑，如收入、终身价值、客户流失等等？我们所说的“定义”，通常指的是任何对组织来说重要的可量化概念。不仅仅是什么是X，但我们怎么办计算X？这些是你衡量你的组织的术语，你对它们的定义越具体（一致），越好。

以下是我们需要防范的定义问题：

人们在哪里找到具体的定义？

一旦你开始对数据进行切片，从不同的角度来审视你的组织，定义就会层出不穷：收入、流失率、预期寿命价值等等。如果我们想了解客户流失的原因，我们应该参考哪些定义？哪个新的我们需要定义吗？以及（字面上）在Metabase中，我在哪里可以找到这些官方定义？

相互冲突的定义

我们所说的冲突是指：我们谈论的是同一件事吗？以收入为例。对于销售团队来说，收入可能意味着预订，但会计人员意味着已确认的应计收入，而营销团队则在谈论终身收入。

重新定义，或者哪一个是规范定义？

如果我们为同一个概念找到多个定义呢？我们怎么知道该信任谁？他们都不符合标准吗？即使多个小组同意我们应该跟踪每周的预订情况，但是这些预订的统计方式可能会因查询而异：一个查询可能是准确的，另一个查询可能是不准确和不受约束的，这是由一个分析员创建的，他不知道用于计算预订的官方查询已经存在；或者忘记忽略测试数据，或者没有考虑折扣，或者只是创建了一个新的查询以不同的方式对预订进行切片。

更改定义

对月收入的计算可能会发生变化，因为一些收入流被抹去，而其他的收入流则会增加。如果我们有不同的部门在多个问题,模型，和仪表板，我们应该如何管理对定义的更改？

控制混乱的策略

找到问题后，让我们谈谈如何减轻这些问题。我们将把这个讨论分为两类：特征Metabase提供过程我们建议你收藏。

特征

以下是Metabase附带的一些工具，可以帮助您保持井然有序。你可能已经知道问题、仪表盘和收藏，但它们值得在这里逐项列出，以全面了解工具箱。

模型

模型让你把那些经常使用的概念编成一个新问题的起点，这些问题可以一次又一次地被引用。通过查询生成器生成的问题和SQL问题可以转换为模型，它们将在搜索结果中显示得更高，以鼓励在整个组织中使用它们。您也可以自定义模型元数据，允许您指定列类型，以便可以钻取即使是在SQL问题上。

例如，你可以写一个问题，把“活跃用户”的信息汇总起来计算（但是你把一个人定义为“活跃的”），然后把这个问题转换成一个模型，这样当人们有关于活跃用户的问题时，他们知道该去哪里。

数据参考和说明

Metabase为您提供了一些位置，用于包含对特定项进行上下文化的有用文本，无论该项是数据库、表、模型还是问题，仪表板,指标或者别的什么。你不必描述一切，但是，您包含的描述越多，人们就越少花时间来弄清楚“这是正确的数据吗？”他们的分析也就越好。用数据记录异常尤其重要（例如，一个表是否包含测试数据或员工帐户或分析师应注意的其他异常）。

图1。您可以在数据引用部分中为表包含有用的上下文。

对于“官方”数据库、仪表板、模型和问题，您应该要求所有者维护其文档。别对你的头衔偷懒；你可以多说几句话。将“客户订单”与“官方：7天平均每日订单-北美”进行比较。

有关Metabase中引用工具的更多信息，请查看使用Metabase的数据浏览器探索数据.

事件和时间表

事件允许团队捕获上下文，并在人们查看其数据时使其可用。例如，您可以添加一个事件来标记销售的开始，或电子邮件活动，或新版本。这样，人们就可以看到这些事件对数据的影响（如果有的话）。你也可以回避所有这些关于4月份数字为什么会上升或下降的问题。

您可以将这些事件组织成与集合相关联的时间线，这样团队就可以将事件分组到一致的时间线中。不同的时间线可以将影响您业务的不同事件集合起来：月球周期、气象现象、神秘仪式等等。

细分市场和指标

管理员可以定义称为部分可以在Metabase的GUI中使用查询生成器。例如，您可以通过段正式定义什么是“活动用户”。“活动用户”将出现在筛选器提要栏，因此任何人都可以按活动用户筛选查询，以查看这些特定用户购买的产品类型、商品在购物车中的放置时间等等。

图2。在撰写简单（和自定义）问题时，用户可以选择片段作为预设筛选器。在本例中，用户可以从管理员创建的新产品、最高评级和高利润细分市场中进行选择。

同样，指标编制计算。例如，管理员可以为“平均订单总额”设置一个官方指标，以便每个人都知道（并且可以使用）该指标的官方计算结果，该指标包括税收，但忽略了应用的折扣。

分段和指标都是版本化的。要了解更多信息，请查看分段和指标.

SQL代码段

SQL代码段是基于GUI的段和度量的SQL对应物。您可以使用它们来捕获和复制一点大小的SQL代码。这些片段可以捕捉到片段、指标，非常复杂加入，或您可能希望在许多查询中重用的任何其他SQL位。

图3。使用SQL片段捕获和共享重要的SQL代码。

使用分段、度量和SQL片段的想法是对定义进行编码，并随着时间的推移使定义更易于更改。更新代码段时，使用该代码段的每个问题都会以一致的方式从更新的定义中获益。要了解更多信息，请查看SQL代码片段：重用和共享SQL代码.

收藏

集合对问题、模型和仪表板（以及其他集合）进行分组。此外，您可以将最重要的项固定到集合的顶部，尤其是根集合我们的分析，以便那些固定的仪表板显示在主页上。要了解更多信息，请查看使用集合权限.

官方收藏

此功能仅在商业版可用（包括自托管和Metabase云）。

这个官方收藏此功能允许您将特定集合指定为重要集合。当管理员将某个收藏标记为正式收藏时，它将获得一个徽章，并将出现在搜索结果的顶部附近，从而方便用户查找。

问题审核

此功能仅在商业版可用（包括自托管和Metabase云）。

管理员可以验证问题和模型表明他们已经看过并批准了。这些经过验证的项目在其名称旁边有一个复选标记，因此用户可以很容易地识别他们的管理员认为值得信任的问题。

如果您想了解更多关于验证功能的信息，请查看我们在建立信任.

过程

知道工具能做什么是成功的一半；另一半是知道何时以及如何使用它们。

为每个部门创建集合

对于每个部门，创建一个集合，并使其仅由一小群人进行编辑。这个小组应该管理这个集合，并且只对他们审查过的问题、模型和仪表板进行定位，用有用的描述装饰，并积极维护。

SQL代码段文件夹

此功能仅在商业版可用（包括自托管和Metabase云）。

SQL代码段文件夹允许您按部门组织文件夹，为这些文件夹分配所有者，并利用文件夹权限。

采用命名约定

在仪表板、集合、模型和问题中设置一个标准的命名约定，以便很明显哪些项是正式的。你如何定义这一惯例比制定一个惯例更不重要。有疑问时：即使是一个简单的前缀，如“Certified”或“Official”（如“Official:每1000个用户打开的电子邮件”）都可以帮助人们筛选搜索结果，并知道哪些项目已经过审查。

指定实验和正在进行的工作的集合

为人们创建存放正在进行的作品的指定位置（有时称为scratch或playond collections）。人们可以而且应该使用个人收藏对于实验来说，同样重要的是要有一个公共场所，人们可以在那里与其他人分享他们的工作，以获得他们正在进行的分析的反馈。

任何人都可以复制官方的问题和仪表板，但你应该鼓励人们将这些项目保存到他们的个人收藏中，或者保存到指定用于实验的集合中。如果这些区域中的某个仪表板启动，则可以将其重新定位到相关的“官方”集合中。你可以设置权限在这些官方的集合上，这样每个人都可以查看它们，但是只有少数人可以编辑它们——确保该集合中的所有内容都是正确的并得到积极维护。

对何时归档项目有策略

对于这些昙花一现的物品，设定明确的期望，让人们在什么时候应该把它们归档，这样这些游乐场就不会堆满了杂物。如果您正在管理部门的收藏，并且只锁定经过审核的项目，那么杂乱无章的问题就不那么大了，但是保持草稿收藏相对新鲜将改善搜索结果。

不要强调归档，因为你可以随时恢复项目。

还有什么方法可以控制混乱？

如果您有任何建议要分享，或对Metabase进行更改或改进的想法，请告诉我们我们的论坛.