交付面向客户的分析的策略
比较不同数据共享方法在开发工作量、可定制性和安全性方面的差异。
目标：交付分析
首先，让我们确保我们有一个明确的目标：向客户交付分析。通过分析，我们指的是为您的客户提供正确的工具（例如，图表和仪表盘）和材料（相关数据），以了解他们的业务并做出更好的决策。
一些背景：许多公司来到 Metabase 并表示他们希望将分析嵌入到他们的应用程序中，并询问 Metabase 是否可以做到这一点。答案是肯定的！嵌入是实施面向客户的分析的最流行方式之一。但是，这不是为人们配备他们进行分析所需的工具和材料的唯一（或最佳）方法。
如果您想构建面向客户的报告或数据可视化（而不让人们选择自己处理数据），请查看将数据可视化发布到 Web。
高质量外部分析的标准
您实施面向客户的分析的方式将取决于客户的需求和您的开发资源，但从根本上讲，您需要交付一个解决方案，该解决方案：
- 使客户能够分析自己的数据。
- 将其分析限制为仅他们有权查看的数据。
- 提供出色的用户体验。
我们将介绍一系列实施策略，从低投入、高回报到高投入、惊人的可定制性。
总的来说，我们建议采用能够满足客户分析需求的最简单选项。一旦您从客户那里获得了一些采用和反馈，您就可以升级投入力度，以推动用户体验的提升。
使用 Metabase 交付面向客户的分析的策略
以下策略按投入力度从低到高 (1) 到 (4) 排序
1. Metabase 边车
我们将我们的第一个策略称为“边车”，因为 Metabase 与您的应用程序并排运行，而不是嵌入在其中。边车方法使用单点登录 (SSO) 为客户提供对其 Metabase 应用程序的直接访问权限，数据沙盒为每个人自定义数据访问权限，以及白标（品牌化）使 Metabase 感觉与您的其余产品具有凝聚力。
以下是该过程的预期结果：您启动一个 Metabase 实例，添加您的徽标和品牌颜色，并连接您的数据库。然后，您对数据进行沙盒处理，以便客户只能看到他们有权查看的内容，并使用 SSO 验证用户身份，以便您的应用程序和您的 Metabase 实例可以协调用户的权限。
设置好品牌化的 Metabase 边车后，您只需在您的应用程序中放置指向您的 Metabase 实例的链接，您的客户将拥有美观、符合品牌风格的仪表盘和图表，他们可以使用 Metabase 易于使用的查询构建器和钻取功能自行探索。您还可以设置自定义目标，将用户发送到其他仪表盘、问题，甚至自定义 URL。您的客户可以获得开箱即用的出色用户体验，并且可以在您为他们设置的任何库存仪表盘之上进行自己的分析——无需嵌入。
边车方法的优点是设置和部署速度快，而且（也许更重要的是）您不必预测您的客户会问哪些关于他们数据的问题。Metabase 配备了一个图形化查询构建器工具，以帮助人们自行查找、筛选和聚合数据。您仍然可以创建库存仪表盘来提供起点，或对数据进行编辑，但重点是您不必这样做。
此外，选择将 Metabase 应用程序作为边车添加到您的应用程序中可以降低项目风险。Metabase 实例是选项 2 和 3 的先决条件，并且如果在设置 Metabase 应用程序的过程中，您发现它不符合您的需求，您也不会浪费任何时间来弄清楚如何将 Metabase 集成到您的应用程序中。
| 优势 | 权衡 |
|---|---|
| - 满足高质量分析的所有三个要求。 - 设置快捷。 - 轻松交接。 - 为您的用户提供真正强大的分析原语。 - 降低流程风险。 |
- 您没有获得：大量的可定制性。您只是在使用 Metabase 的 UI 和功能。 |
2. Metabase 交互式嵌入
在投入力度上更进一步，交互式嵌入是我们客户中最流行的策略。这种类型的嵌入将整个 Metabase 应用程序放入您的应用程序中，让人们可以访问分析功能，例如操作菜单，用于向下钻取和查询构建器，用于自助服务数据访问。
交互式嵌入所需的投入精力可能差异很大，具体取决于您希望构建的体验的广泛程度。您可以为客户指定一组导航浏览的屏幕，并且可以将这些屏幕或仪表板链接在一起。如果您的屏幕集较小且简单明了，那么它可能不会比sidecar实现花费更多的工作。但是，由于您可以控制您的应用程序，因此您可以（通过更多努力）为您的客户创造可能更丰富的体验。
如果您只想为客户提供简单的报告和数据可视化（即，您不需要像向下钻取或查询这样的分析功能），您可以使用其他类型的嵌入，例如公共嵌入或静态嵌入。有关更多信息，请参阅在网络上发布数据可视化。
| 优势 | 权衡 |
|---|---|
| - 您可以通过设置 Metabase 屏幕、图表或仪表板之间的特定导航路径来自定义用户体验。 - 您的用户无需离开您的主应用程序即可查看这些 Metabase 屏幕。 |
- 这需要更多工作：您需要设计用于容纳嵌入式 Metabase 屏幕的页面。 - Metabase 提供了固定数量的外观设置，因此您的应用程序设计与嵌入式 Metabase 组件之间可能存在一些美学差异。 |
3. Fork Metabase 源代码
Metabase Pro 和 Enterprise 版本是源代码可用的，因此您可以查看代码或 fork 它并随意使用它。图表设计？网格系统与您的网格冲突？您将可以访问 CSS、绘图基元 - 完整源代码。
如果您真的想调整嵌入式 Metabase 应用程序的设计以创建无缝体验，您可以选择此路线。即使您从未使用过此路线，但知道您可以随时更改设计或添加功能来解决标准 Metabase 无法解决的分析挑战，这也很不错。
| 优势 | 权衡 |
|---|---|
| - 对用户体验进行精细控制，以实现与您的应用程序的无缝集成。 - 能够向仪表板、图表等添加功能。 - 完全控制 Metabase 及其图表的设计。 |
- 您必须维护一个 fork；随着新的 Metabase 版本发布，您需要将这些更改集成到您的 fork 中。 - 这需要大量工作。比从头开始构建自己的分析平台的工作量少很多，但明显多于交互式嵌入。 |
4. 构建您自己的分析平台
太多公司承担了构建自己的分析软件的工作，但原因通常不明朗。这些公司花费大量时间和金钱（数百万甚至数千万美元）来构建不如 Metabase 开箱即用的子标准工具，而他们本可以将这些资源应用于其核心业务和开发。
话虽如此，构建自己的分析平台也有合理的理由。在这种情况下，您可能已经有了第三方的分析解决方案，但它未能满足您的需求。您确切知道需要构建什么（以及为什么需要构建它），并且有工程资源来投入该项目。例如，您可能需要解决一个权限问题，Metabase（或其他产品）无法解决，而这不仅仅是添加功能和提交 pull request 那么简单。只需确保您打算通过编写自己的平台来解决的问题是任务关键型的，并且现有产品缺乏处理这些问题的特性。
| 优势 | 权衡 |
|---|---|
| - 完全控制体验，而无需维护 fork。 - 处理其他解决方案（如 Metabase）无法解决的用例。 |
- 最昂贵的选项，投资回报率不明朗。 |
哪个选项适合您的组织？
大多数公司选择交互式嵌入，因为他们想要额外的可定制性，以便为客户提供更精选的屏幕集。但是，正如我们上面讨论的那样，交互式嵌入并不是使用 Metabase 提供分析的唯一选择。它可能不是最佳的起点，特别是如果您是一家试图最大限度利用有限资源的初创公司。在这种情况下，请好好考虑 sidecar 方法 - 将 Metabase 设置为应用程序的 sidecar 是向客户交付价值的最快方法。您可以随时在迭代时过渡到嵌入式解决方案，但与此同时，您已经可以让您的客户能够做出数据驱动的决策，并且您将更好地了解他们需要的分析。
对于较大的公司，fork 源代码可能更有意义。 这是一项更大的投资，但与从头开始构建分析平台相比，您将能够交付更具成本效益的解决方案。
当然，如果您不想维护 fork，Metabase 接受 pull request！利用 Metabase 的内置功能集，提交 PR 来获取您完成分析产品所需的最后一点功能，您将以构建自己的平台所需成本的一小部分获得所需的自定义解决方案，同时为所有人改进 Metabase。
进一步阅读
下一步：在网络上发布数据可视化
与互联网上的好人们分享独立的图表和仪表板。