提供面向客户的分析的策略
比较不同数据共享方法的开发工作量、可定制性和安全性。
目标：提供自助分析
首先，我们要明确我们的目标：为客户提供自助分析。我们所说的分析是指为客户提供正确的工具（例如图表和仪表板）和材料（相关数据），以便他们理解自己的数据并做出更好的决策。而自助意味着让客户能够自行分析他们自己的数据——而不仅仅是预先构建的图表和仪表板。
一些背景：许多公司找到 Metabase，表示他们希望将分析嵌入到他们的应用程序中，并询问 Metabase 是否可以做到。答案是可以！嵌入是实现面向客户的分析最流行的方法之一。但是，它并不是为人们提供进行分析所需的工具和材料的唯一（或最佳）方法。
如果您想构建面向客户的报表或数据可视化（而不提供让人们自行探索数据的选项），请查看将数据可视化发布到 Web。
高质量外部分析的标准
您实现自助面向客户的分析的方式将取决于客户的需求和您的开发资源，但根本上您需要交付一个解决方案，该解决方案
- 使客户能够分析他们自己的数据。
- 限制他们只能分析他们有权查看的数据。
- 提供出色的用户体验。
我们将涵盖一系列实现策略，从低投入高回报到高投入高可定制性。
总的来说，我们推荐满足客户分析需求的、最简单的选项。一旦获得客户的采用和反馈，您就可以逐步增加投入，以提高用户体验。
使用 Metabase 提供面向客户的分析的策略
以下策略按投入量从低（1）到高（5）排序
- 独立的 Metabase，从您的应用程序链接（从这里开始）
- 嵌入交互式 Metabase 组件
- 使用 Metabase React SDK 定制您的分析
- Fork Metabase 源代码
- 构建您自己的分析平台
1. 独立的 Metabase，从您的应用程序链接
在此策略中，Metabase位于您的应用程序旁边；您不将其嵌入到您的应用程序中。您可以使用单点登录 (SSO) 设置您的 Metabase，为客户提供直接访问您 Metabase 的权限，使用行和列安全为每个人定制数据访问，并使用白标（品牌化），使 Metabase 感觉与您的产品其他部分保持一致。然后，您只需在您的应用程序中添加指向独立 Metabase 的链接。
该过程的预期结果是：您将部署一个 Metabase 实例，添加您的徽标和品牌颜色，并连接您的数据库。然后，您将实现行和列安全，以便客户只能看到他们被授权看到的内容，并通过 SSO 进行身份验证，以便您的应用程序和 Metabase 都可以协调权限。
设置好品牌化的独立 Metabase 后，您只需在应用程序中放入指向您 Metabase 的链接，您的客户就可以拥有精美的、符合品牌风格的仪表板和图表，他们可以通过 Metabase 易于使用的查询生成器和钻取功能自行探索。您还可以设置自定义目标，将用户引导至其他仪表板、问题，甚至是自定义 URL。您的客户可以开箱即用地获得出色的用户体验，并在您为他们设置的任何标准仪表板之上进行自己的分析——无需嵌入。
这种方法的优势在于设置和部署速度，以及（也许更重要的是）您不必预测客户将提出的数据问题。Metabase 配备了图形化查询生成器工具，可帮助人们自己查找、过滤和汇总数据。您仍然可以创建标准仪表板，以提供一个起点，或者对数据进行编辑性的处理，但关键是您不必这样做。
此外，选择将 Metabase 应用程序作为您应用程序的“伴侣”进行部署，可以降低项目风险。如果您发现 Metabase 不符合您的需求，您就不会在如何将其集成到您的应用程序中而浪费时间。
优点
- 设置快速。
- 为您的用户提供非常强大的分析原语。
权衡
- 您的客户需要离开您的应用程序才能查看图表和仪表板。
- 可定制性有限：您只能使用 Metabase 的 UI 和功能。
2. 嵌入交互式 Metabase 组件
嵌入式分析 JS 是我们客户中最流行的方法。这种类型的嵌入将 Metabase 图表和仪表板集成到您的应用程序中，并提供与独立 Metabase 中相同的交互性选项，使人们能够访问分析功能，例如钻取和用于自助数据访问的查询生成器。
通过嵌入式分析 JS，您可以自定义图表和仪表板的外观（颜色、字体等），并将您应用程序的身份验证与 Metabase SSO 集成，为客户提供无缝的应用内体验。
您在嵌入式分析 JS 上投入的精力会有很大差异，具体取决于您想要构建的体验的广泛程度。您可以指定一组屏幕供客户导航，并且可以将这些屏幕或仪表板链接在一起。如果您的屏幕集很小且简单，其工作量可能与伴侣式实现相差无几。但由于您控制着您的应用程序，因此（通过更多的投入）您可以为您的客户创建更丰富的体验。
优点
- 您的客户可以探索他们自己的数据。
- 您可以设置 Metabase 屏幕、图表或仪表板之间的特定导航路径来定制用户体验。
- 您可以自定义图表和仪表板的外观。
- 低代码选项：Metabase 会生成一个 HTML 代码片段，您可以将其复制粘贴到您的页面中。
权衡
- 工作量更大：您需要设计容纳嵌入式 Metabase 屏幕的页面。
3. 使用 Metabase React 组件定制您的分析
与嵌入式分析 JS 一样，使用嵌入式分析 SDK，您可以嵌入单个 Metabase 组件（例如独立的图表、仪表板、查询生成器等），管理每个组件的访问和交互，并获得高级定制以实现无缝样式。SDK 在此基础上为您提供了更多关于组件外观和行为的灵活性：例如，您可以自定义查询生成器的布局，或配置钻取菜单中的操作。
这里的投入与嵌入式分析 JS 相似；您可以投入更多精力来定制更多体验，但您不必这样做。一旦您在应用程序中设置了组件，它应该“就能正常工作”。
优点
- 您可以选择要嵌入哪些组件。
- 您可以完全控制您面向客户的分析的外观。
权衡
- 目前仅适用于 React 应用程序！
- 如果您真的想深度定制您的分析，可能需要更多的 Web 开发工作。
4. Fork Metabase 源代码
Metabase Pro 和 Enterprise 版本是开源可用的，因此您可以查看代码或 fork 它并随意使用它。图表设计？网格系统与您的网格冲突？您将可以访问 CSS、图形原语——完整的源代码。
如果您真的想精心设计您的嵌入式 Metabase 应用程序以创造无缝体验，您可能会选择此路线。即使您从未走这条路，知道有这条可用途径可以在您遇到 Metabase 无法解决的分析挑战时更改设计或添加功能，也是很有好处的。
优点
- 对用户体验进行细粒度控制，以实现与您的应用程序的无缝集成。
- 能够为仪表板、图表等添加功能。
- 完全控制 Metabase 及其图表的设计。
权衡
- 您必须维护一个 fork；随着新 Metabase 版本的发布，您将需要将这些更改集成到您的 fork 中。
- 工作量巨大。比从头开始构建分析平台的工作量要少很多，但比嵌入式分析 JS 或 SDK 要多得多。
5. 构建您自己的分析平台
许多公司承担了构建自己分析软件的工作，原因通常不明确。这些公司花费了大量的时间和金钱（数百万到数千万美元）来构建二流的工具，而 Metabase 开箱即用就可以超越它们，而他们可以将这些资源投入到他们的核心业务和开发中。
话虽如此，构建自己的分析平台也有正当理由。在这种情况下，您可能已经部署了第三方分析解决方案，但它未能满足您的需求。您确切地知道需要构建什么（以及为什么需要构建它），并且拥有承诺该项目的工程资源。例如，您可能有一个权限问题需要解决，而 Metabase（或其他产品）无法解决，这不仅仅是添加功能并提交拉取请求那么简单。只需确保您打算通过编写自己的平台来解决的问题是任务关键型的，并且现有产品缺乏处理这些问题的功能。
优点
- 完全控制体验，而无需维护 fork。
- 处理其他解决方案（如 Metabase）无法解决的用例。
权衡
- 成本最高的选项，投资回报模糊。
哪个选项适合您的组织？
大多数公司选择嵌入式分析 JS，因为它们想要额外的定制性来为客户提供更精心设计的屏幕集。但嵌入式分析 JS 并不是使用 Metabase 提供分析的唯一选项。对于初创公司来说，这可能不是一个好的开始，尤其是当您试图在资源有限的情况下最大化利用时。在这种情况下，请考虑使用独立的 Metabase——这是最快为客户提供价值的方式。您可以随时在迭代过程中过渡到嵌入式解决方案，但在此期间，您将已经为客户提供可以处理的数据，并且您将对他们所需的分析有更深入的了解。
对于较大的公司来说，fork 源代码可能更合适。这是一项更大的投资，但与从头开始构建分析平台相比，您将能够提供更具成本效益的解决方案。
当然，如果您不想维护一个 fork，Metabase 也接受拉取请求！利用 Metabase 内置的功能集，提交一个 PR 来获取您分析产品所需的最后一点功能，您将以不到构建自己平台成本的一小部分获得所需的定制解决方案，同时改善所有人的 Metabase。