嵌入式分析：在业务应用程序中添加仪表板

您的客户不想在您的应用程序和单独的分析工具之间切换。他们希望在他们已经使用的产品中看到他们的数据——可视化、交互式和可操作的。这就是嵌入式分析的承诺：分析功能无缝集成到您的应用程序中，因此用户永远不会离开工作流程。

对于 SaaS 公司来说，嵌入式分析是一个差异化因素，可以减少流失（看到价值的用户会停留更长时间）、实现溢价（分析功能证明更高的层级是合理的）并创造粘性（当用户围绕您的仪表板构建工作流程时，转换成本会增加）。

对于基于 Odoo 或自定义平台构建的内部业务应用程序，嵌入式分析消除了操作系统和 BI 工具之间的上下文切换，使基于数据的决策成为自然工作流程的一部分。

要点

• 嵌入式分析使数据洞察成为产品体验的一部分而不是单独的工具，从而将用户参与度提高了 2 到 3 倍，并减少了用户流失
• 三种嵌入方法（iframe、JavaScript SDK、无头 API）在增加开发成本的同时提供了越来越多的定制
• 行级安全性和多租户对于 SaaS 产品来说是不可协商的 --- 每个客户必须只能看到自己的数据，并在查询级别得到保证
• 性能优化（缓存、延迟加载、预聚合）可防止嵌入式仪表板降低应用程序的用户体验

---

为什么要嵌入分析？

商业案例

对于 SaaS 产品：

• 62% 的 SaaS 买家表示分析功能影响他们的购买决策 (Logi Analytics)
• 与嵌入式仪表板交互的用户保留率提高了 2.5 倍
• 分析功能证明较高级别的 20-30% 溢价是合理的
• 嵌入式仪表板会产生转换成本——自定义报告和保存的视图很难迁移

对于内部应用程序：

• 消除操作工具和 BI 工具之间的上下文切换
• 将见解用于决策（仓库经理在与库存列表相同的屏幕上查看库存分析）
• 减少对单独 BI 工具许可证的需求
• 确保所有用户访问相同的受管理的最新数据

何时不嵌入

嵌入式分析并不总是正确的选择：

• 早期产品： 如果您的产品仍在寻找产品市场契合度，那么构建嵌入式分析还为时过早。使用独立的 BI 工具，直到您知道用户实际需要什么分析。
• 强大的分析师： 一些用户需要专用分析工具的全部功能（自定义 SQL、复杂连接、R/Python 集成）。嵌入式分析通常提供完整 BI 功能的子集。
• 低数据量： 如果每个客户的记录少于 100 条，应用程序中的简单表格和摘要卡可能就足够了，无需正式的分析层。

---

嵌入方法

方法 1：Iframe 嵌入

最简单的方法。您的 BI 工具为每个仪表板生成一个 URL，您的应用程序将其呈现在 iframe 中。

它是如何工作的：

1. 为嵌入式仪表板生成签名 URL 或身份验证令牌。
2. 在您的应用程序中渲染一个指向该 URL 的 <iframe>。
3. BI工具处理所有渲染、交互和数据查询。

优点：

• 最快实施（数小时，而不是数周）
• 提供完整的 BI 工具功能
• BI工具添加功能时自动更新

缺点：

• 有限的视觉定制（仪表板看起来像 BI 工具，而不是您的应用程序）
• 跨源限制可能会使身份验证复杂化
• 性能取决于 BI 工具的渲染速度
• 用户可以将 iframe 转至完整的 BI 工具

最适合： 内部应用程序、MVP 和快速原型设计。

方法 2：JavaScript SDK

许多分析平台提供 JavaScript SDK，将图表和仪表板呈现为应用程序中的本机组件。

它是如何工作的： 1.安装SDK（npm包或脚本标签）。 2. 使用身份验证凭据进行初始化。 3. 将单个图表或完整仪表板渲染为 React/Vue/Angular 组件。 4. 将应用程序的 CSS 主题应用到组件。

优点：

• 原生外观和感觉（与您的应用程序的设计系统相匹配）
• 对布局和交互性的精细控制
• 更好的身份验证集成（传递现有会话令牌）
• 单独的图表嵌入（不仅仅是完整的仪表板）

缺点：

• 比 iframe 需要更多的开发工作
• 与SDK的功能和更新周期相关
• 更大的包大小（SDK 添加到应用程序的 JavaScript 有效负载）

最适合： 需要品牌集成分析的 SaaS 产品。

方法 3：无头/基于 API

使用分析平台的查询 API 构建您自己的可视化层。您可以使用自己的图表库（Recharts、Chart.js、D3.js）发送查询、接收数据并呈现图表。

它是如何工作的：

1. 针对分析平台的数据模型或直接针对仓库定义查询。
2. 通过 REST/GraphQL API 执行查询。 3.接收JSON数据。
3. 使用您自己的前端图表组件进行渲染。

优点：

• 完整的设计控制（像素完美匹配您的应用程序）
• 最小的捆绑影响（无需加载 SDK）
• 交互性和用户体验的最大灵活性
• 可以直接使用相同的数据仓库

缺点：

• 最高的开发工作量（构建和维护您自己的可视化层）
• 必须自己实现缓存、加载状态、错误处理
• 最终用户无需拖放仪表板构建器

最适合： 以分析为核心功能且完整的设计控制至关重要的产品。

---

嵌入式分析工具比较

对于大多数中型市场公司来说，Metabase 的嵌入式产品提供了功能和简单性的最佳平衡。对于需要完全设计控制的产品，Cube.js 作为无头语义层与自定义 React 图表（使用 Recharts 或类似图表）相结合，提供了最大的灵活性。

---

行级安全性

行级安全性 (RLS) 确保每个用户或租户只能看到他们有权访问的数据。这是多租户应用程序中嵌入式分析最关键的要求。

实施方法

基于 JWT（元数据库）： 您的应用程序生成包含用户身份和权限的 JWT 令牌。 Metabase 使用这些声明来自动过滤数据。

JWT payload:
{
  "user_id": 42,
  "organization_id": "org_abc",
  "role": "manager",
  "department": "sales"
}

配置数据库应用过滤器：WHERE organization_id = 'org_abc' AND department = 'sales'。

查询级别（Cube.js）： 安全过滤器在数据模型中定义并自动应用于每个查询。

数据库级（PostgreSQL RLS）： PostgreSQL内置行级安全策略，在数据库引擎层面过滤数据，提供最强保障。在执行查询之前通过 SET app.current_org_id = 'org_abc' 设置当前用户上下文。

多租户模式

**共享数据库，过滤查询：**所有租户的数据都在同一个表中。查询按 organization_id 过滤。对于成千上万的小租户来说，管理最简单、效率最高。

共享数据库，单独的模式： 每个租户都有自己的 PostgreSQL 模式。比行级过滤具有更多隔离性，但更难大规模管理。

独立的数据库： 每个租户都有自己的数据库。最大程度的隔离，但操作复杂且昂贵。为具有严格数据驻留要求的企业客户保留。

对于大多数 SaaS 应用程序，具有行级过滤的共享数据库是正确的选择。确保每个查询（无一例外）均按租户标识符进行过滤。单个未经过滤的查询就是数据泄露。

---

性能优化

嵌入式仪表板的加载速度必须与应用程序的其余部分一样快。用户可以容忍全页仪表板 2-3 秒的加载时间，但期望单个图表和 KPI 的亚秒级渲染。

缓存策略

查询结果缓存： 将常见查询的结果缓存在Redis或Memcached中。当底层数据发生变化时失效。大多数 BI 工具支持内置查询缓存。

预聚合： 对于高流量仪表板，预计算聚合（每日收入、每小时订单计数）并将其存储在物化视图中。这将查询执行时间从几秒减少到几毫秒。

客户端缓存： 在浏览器中缓存最近获取的数据。当用户离开并返回时，立即显示缓存的数据，同时在后台刷新。

延迟加载

不要同时加载所有仪表板小部件。首先加载可见的小部件（在首屏上），并在用户滚动时延迟加载在首屏下的小部件。这极大地提高了感知性能。

小部件优先级

根据用户行为确定加载顺序的优先级：

1. KPI 卡： 首先加载（数据小，影响最大）
2. 主图表： 加载第二图表（用户关注的主要可视化）
3. 辅助图表： 加载第三个图表（支持上下文）
4. 明细表： 最后加载（大数据，通常在首屏下方）

绩效预算

---

实施指南

第 1 阶段：基础（第 1-2 周）

1. 选择您的嵌入方法（用于 MVP 的 iframe，用于生产的 SDK）。
2. 设置分析平台（Metabase 或 Cube.js）。
3. 连接到您的数据仓库 或直接连接到您的应用程序数据库。
4. 使用 JWT 声明或数据库级 RLS 实现行级安全性。
5. 构建一个包含三到五个小部件的嵌入式仪表板。

第 2 阶段：整合（第 3-4 周）

1. 设置嵌入式组件的样式以匹配您的应用程序的设计系统。
2. 实施 SSO，以便用户不需要单独的分析凭据。
3. 在应用程序页面和嵌入式仪表板之间添加导航。
4. 设置查询缓存和预聚合以提高性能。
5. 与多个租户进行测试以验证数据隔离。

第 3 阶段：用户体验（第 5-6 周）

1. 添加响应应用程序上下文的交互式过滤器（例如，在应用程序中选择客户会过滤嵌入式仪表板）。
2. 实现延迟加载和小部件优先级。
3. 构建导出功能（PDF、CSV、定期电子邮件报告）。
4. 为受监管边界内的高级用户添加自助探索。
5. 衡量参与度：使用哪些仪表板、由谁使用以及使用频率。

第 4 阶段：高级（第 2-3 个月）

1. 添加预测分析 小部件（流失风险评分、需求预测）。
2. 实施警报（当用户的 KPI 超过阈值时通知用户）。
3. 为特定领域的可视化构建自定义图表类型。
4. 允许用户创建和保存自己的仪表板视图。
5. 衡量对保留率、参与度和追加销售转化的影响。

---

常见问题

嵌入分析会减慢我们的应用程序速度吗？

如果不仔细执行，它可能会发生。 Iframe 嵌入将 BI 工具的加载时间添加到应用程序的加载时间之上。 SDK 嵌入增加了包大小。基于 API 的嵌入会增加 API 调用延迟。缓解策略（缓存、延迟加载、预聚合、静态资产的 CDN 交付）可将影响降至最低。完整仪表板的目标是不到 3 秒，单个 KPI 卡的目标是不到 500 毫秒。

我们如何处理想要自定义仪表板的用户？

提供分层方法：为大多数用户提供带有交互式过滤器的固定仪表板，为高级用户提供可配置的小部件布局，为分析师提供全面的自助服务探索。大多数嵌入式分析平台都支持某种程度的最终用户定制。将每个用户的自定义保存在应用程序的数据库中，而不是 BI 工具中，以便它们在会话中持续存在并遵循用户的帐户。

我们可以从现有的元数据库或超集实例中嵌入分析吗？

是的。 Metabase 的嵌入功能（Pro 层）通过 JWT 生成具有行级安全性的签名 iframe URL。 Superset 支持 iframe 嵌入，并通过嵌入式仪表板功能进行身份验证。两者都需要配置 CORS 标头和身份验证端点。对于新的实施，评估嵌入式分析是否应使用与内部分析相同的实例或专用实例来实现隔离和性能。

移动设备呢？嵌入式仪表板可以在移动应用程序上使用吗？

iframe 嵌入适用于移动 WebView，但体验通常很差（图表小、交互困难）。 SDK 和 API 方法使您可以完全控制移动渲染。对于移动设备，优先考虑 KPI 卡和简单的趋势图，而不是复杂的可视化。考虑构建一个专用的移动分析视图，以移动优化的布局显示最重要的指标，而不是试图缩小桌面仪表板。

---

下一步是什么

嵌入式分析将您的应用程序从人们使用的工具转变为人们依赖的平台。它是分析堆栈中的最后一层，从 ETL 管道 开始，通过 数据仓库 提供数据，并支持 自助服务探索 和 预测洞察。所有这些都支持更广泛的 BI 策略，推动整个组织基于数据的决策。

ECOSIRE 为 SaaS 产品和内部业务应用程序构建嵌入式分析解决方案。我们的 OpenClaw AI 平台 提供无头分析层，我们的 Odoo 咨询 团队将仪表板集成到您的 ERP 工作流程中。无论您是向面向客户的产品还是内部运营工具添加分析，我们都会处理从数据仓库到渲染仪表板的完整堆栈。

联系我们 将分析嵌入到您的应用程序中。

---

由 ECOSIRE 发布 --- 通过 Odoo ERP、Shopify 电子商务 和 OpenClaw AI 等人工智能驱动的解决方案帮助企业扩展规模。