保持您的分析井然有序
随着用户、问题和仪表板数量的不可避免的增加，如何保持分析井井有条。
如果您想保持竞争力，就需要让组织中的人员访问他们所需的数据，以做出更好的决策。然而，数据民主化的代价是不可避免的分析洪流——这使得人们难以判断哪些分析是可信的。
重要的是要明白，这个问题没有灵丹妙药。总会有一定程度的分析熵需要驯服，但有了正确的工具和流程，您就能控制住不可避免的混乱。
分析民主化的问题
这些问题的核心在于定义：我们究竟如何定义诸如收入、客户生命周期价值、流失率等业务逻辑？而“定义”在此泛指对您的组织重要的任何可量化概念。不仅是“X 是什么”，更是我们“如何计算 X”？这些是您衡量组织的术语，您定义得越具体（和一致），效果就越好。
以下是我们需要警惕的一些定义问题
人们在哪里找到具体的定义？
一旦您开始从不同角度剖析数据以审视您的组织，定义就会激增：收入、流失率、预期客户生命周期价值等等。如果我们想了解客户流失的原因，我们应该参考哪些定义？我们需要定义哪些新定义？以及（字面意义上）我在 Metabase 中可以在哪里找到这些官方定义？
冲突的定义
冲突是指：我们是否在谈论同一件事？以收入为例。对于销售团队来说，收入可能意味着订单额，但会计部门指的是已确认的应计收入，而营销团队则谈论的是客户生命周期收入。
重新定义，或者哪个是规范定义？
如果同一概念我们找到了多个定义怎么办？我们怎么知道该相信哪个？它们都偏离目标了吗？即使多个团队同意我们应该追踪每周订单额，但这些订单额的统计方式可能因查询而异：一个查询可能是准确的，另一个可能是不准确且未经审查的，由一个不知道官方订单额计算查询已存在的分析师创建；或者忘记排除测试数据，或者未能考虑折扣，或者只是创建了一个新查询以不同的方式切分订单额。
不断变化的定义
月收入的计算可能会随着某些收入来源的终止和新收入来源的增加而改变。如果不同部门在多个问题、模型和仪表板中使用相同的定义，我们应该如何管理定义的更改？
驯服混乱的策略
确定了问题之后，我们来讨论如何缓解这些问题。我们将把讨论分为两类：Metabase 提供的功能，以及我们建议您采用的组织流程。
功能
以下是 Metabase 附带的一些工具，它们将帮助您保持井井有条。您可能已经了解问题、仪表板和集合，但在此将它们列出有助于全面了解工具包。
模型
模型允许您将这些常用概念编码为新问题的起点，这些问题可以轻松地反复引用。通过查询构建器构建的问题以及 SQL 问题都可以转换为模型，并且它们会在搜索结果中显示得更靠前，以鼓励在组织内使用。您还可以自定义模型元数据，允许您指定列类型，以便即使在 SQL 问题上也可以钻取。
例如，您可以编写一个问题，汇总并计算“活跃用户”的信息（无论您如何定义一个人为“活跃”），然后将该问题转换为模型，以便人们在有关于活跃用户的问题时知道去哪里查找。
数据参考和描述
Metabase 提供了您可以包含有用的文本的地方，用于上下文化特定项目，无论该项目是数据库、表、模型、问题、仪表板还是其他什么。您不必描述所有内容，但您包含的描述越多，人们花在弄清楚“这是否是正确的数据？”上的时间就越少，他们的分析就会越好。记录数据例外情况尤为重要（例如，表是否包含测试数据或员工账户，或者分析师应该注意的其他例外情况）。
对于“官方”数据库、仪表板、模型和问题，您应该要求所有者维护其文档。不要在标题上偷懒；多用几个词可以做很多事情。比较“客户订单”和“官方：北美地区滚动 7 天平均每日订单”。
有关 Metabase 中参考工具的更多信息，请查看使用 Metabase 的数据浏览器探索数据。
事件和时间线
事件允许团队捕获上下文，并在人们查看其数据时提供该上下文。因此，例如，您可以添加一个事件来标记销售、电子邮件营销活动或新版本的开始。这样，人们就可以看到这些事件对数据（如果有的话）产生了什么影响。您还可以避免关于四月或任何其他时间数字上涨或下跌的所有问题。
您可以将这些事件组织成时间线，这些时间线与集合相关联，因此团队可以将事件分组为连贯的时间线。不同的时间线可以分组不同的影响您业务的事件集：月相周期、气象现象、神秘仪式等等。
细分和指标
管理员可以定义官方过滤器（或过滤器集），称为细分，可在 Metabase 的查询构建器中使用。例如，您可以通过细分正式定义“活跃用户”是什么。“活跃用户”将出现在筛选器侧边栏中，因此任何人都可以通过活跃用户筛选其查询，以查看这些特定用户购买的产品类型、商品在购物车中停留的时间等。
同样，指标将计算编码。例如，管理员可以为“平均订单总额”设置一个官方指标，以便每个人都知道（并且可以使用）该指标的官方计算，该计算包括税费但不包括应用的折扣。
细分和指标都已版本化。要了解更多信息，请查看细分和指标。
代码片段
代码片段是基于 GUI 的细分和指标的 SQL 等效项。您可以使用它们捕获和复制小块 SQL 代码。这些代码片段可以捕获细分、指标、复杂的连接或您可能希望在许多查询中重用的任何其他 SQL 片段。
细分、指标和代码片段的目的是将定义编码，并使其易于随着时间的推移而修改。当您更新一个代码片段时，每个使用该代码片段的问题都将以一致的方式从更新后的定义中受益。要了解更多信息，请查看代码片段：重用和共享 SQL 代码。
集合
集合将问题、模型和仪表板（以及其他集合）分组。此外，您可以将最重要的项目固定到集合的顶部，尤其是根集合“我们的分析”，以便这些固定的仪表板显示在主页上。要了解更多信息，请查看使用集合权限。
官方集合
官方集合功能允许您将特定集合指定为重要。当管理员将集合标记为官方时，它会获得一个徽章并会出现在搜索结果的顶部附近，方便用户查找。
已验证的项目
管理员可以验证问题和模型，以表示他们已查看并批准了它们。这些已验证的项目通过其名称旁边的复选标记进行标识，因此用户可以轻松识别其管理员认为可信的问题。
如果您想了解有关验证功能的更多信息，请查看我们关于建立信任的文章。
流程
了解工具的功能只是成功的一半；另一半是知道何时以及如何使用它们。
为每个部门创建集合
为每个部门创建一个集合，并仅允许一小部分人编辑。该小组应管理该集合，并仅固定他们已审查、附有有用描述并积极维护的问题、模型和仪表板。
代码片段文件夹
代码片段文件夹允许您按部门组织文件夹，为这些文件夹分配所有者，并利用文件夹权限。
采用命名约定
为您的仪表板、集合、模型和问题设置统一的命名约定，以便明确哪些项目是官方的。如何定义该约定不如拥有约定本身重要。如有疑问：即使是简单的前缀，如“认证”或“官方”（例如，“官方：每 1000 用户的电子邮件打开数”）也可以帮助人们筛选搜索结果并知道哪些项目已通过审核。
指定用于实验和进行中的作品的集合
创建指定位置供人们存储进行中的作品（有时称为草稿或沙盒集合）。人们可以也应该使用个人集合进行实验，但拥有公共场所供人们与他人分享其进行中的分析以获取反馈也很重要。
任何人都可以复制官方问题和仪表板，但您应该鼓励人们将这些项目保存到他们的个人集合，或专门用于实验的集合。如果这些区域中的一个仪表板流行起来，您可以将其重新定位到相关的“官方”集合。您可以对这些官方集合设置权限，以便每个人都可以查看它们，但只有少数人可以编辑它们——确保该集合中的所有内容都是正确的并积极维护。
制定何时存档项目的策略
对于这些临时项目，设定清晰的期望，说明人们何时应该将其存档，以免这些沙盒堆满杂物。如果您正在管理部门的集合，并且只固定已审核的项目，那么杂物问题就会减少，但保持草稿集合相对新鲜将改善搜索结果。
而且不要为存档而紧张，因为您可以随时恢复项目。
其他驯服混乱的想法？
如果您有任何技巧可以分享，或者对 Metabase 的更改或改进有任何想法，请在我们的论坛上告诉我们。