嵌入悲伤的五个阶段
所以您想将数据呈现给您的客户……但代价是什么？
当您考虑将数据呈现给您的客户时，您可能会想象定制的图表、带有颜色编码的指标以及大量的空白。
虽然仪表板能够为您的客户提供自助分析，但它们通常不是最佳选择。
本文将向您展示为什么从嵌入式仪表板（或您的数据的任何预定义视图）开始往往会导致可维护性和可伸缩性方面的问题。
如果您已经确信，请查看您可以采取的嵌入方法，以避免给自己带来麻烦。
示例用例
假设您经营一个电子商务平台。您的分析师构建了一个仪表板，您的团队可以在其中查看每位商家的成功情况，包括每位客户的访问量、交易量随时间的变化以及客户平均评分等数据。
您计划将此仪表板嵌入到面向商家的应用程序中，以便您的商家可以利用这些指标和可视化来了解和发展他们的业务。
阶段 1：否认
人们每天都在使用您的仪表板，因此您对自己认为它已经达到了高质量外部分析标准非常有信心。
阅读了提供客户分析的策略后，您决定结合使用单点登录 (SSO)、行和列安全以及白标签，将现有仪表板直接嵌入到面向商家的应用程序中。
阶段 2：愤怒
首次发布几周后，您发现您的商家非常喜欢使用仪表板，以至于您的数据仓库无法满足他们的热情。
您的商家开始对加载仪表板所需的时间感到沮丧。您决定将仪表板的数据源复制到一个更快速的数据仓库，并为了保险起见调整实例数量。
阶段 3：讨价还价
您的仪表板开始收到功能请求——似乎您的商家越是接触数据，他们就对筛选器、数据透视表和自定义计算有越多问题。
一些商家希望使用自己的收入计算。其他人则对折线图与条形图有强烈意见。一小部分（但非常活跃）的商家甚至不关心图表——他们只是想要一种方法来获取去匿名化的客户数据，以运行个性化活动。
阶段 4：沮丧
您意识到，为了支持您的商家最近提出的仪表板添加需求，您的数据库中的表需要一些复杂的 SQL 技术。
您的团队没有时间重构架构（他们忙于维护现有视图），因此您开始编写自定义 SQL 脚本来满足您最重要的商家的需求。您的数据仓库变得充斥着任意表。
尽管您的产品团队尽最大努力跟踪对更多数据以及更多查看数据方式的需求，但您曾经成功的内部仪表板似乎已经变成了由一百个图块组成的怪物。
当您终于有时间查看商家仪表板的使用统计数据时，您悲伤地发现您的商家只查看过那些图块一次，甚至根本没看过。
阶段 5：接受
您很高兴地想起，整个场景都是假设性的。当您回顾模拟的创伤时，您会意识到：
- 人们通过以不同的方式查看数据来找到答案。
- 仪表板请求（我能获得特定数据视图吗？）实际上是对自助服务数据（我能获得足够多的视图来回答我的问题吗？）的请求。
- 您不应该根据仪表板请求来创建或更新您的表。
一种心态转变：从嵌入式仪表板到嵌入式数据模型
开始嵌入的最佳方式是将您的数据模型视为最终产品（数据模型意味着生活在您的数据仓库中的字段、表和关系的结构）。
如果您的数据模型易于非工程师查找、理解、修改和验证，您将赋予他们信心和自主权，让他们以最适合他们的方式使用数据（并从管理临时仪表板请求中解放您的时间）。
当然，您仍然需要避免创建一类全新的临时数据模型请求。花点时间（现在您已经找回了一些时间）来构建不仅在工程角度优化，而且在产品设计角度也优化的数据模型，这是非常值得的。
延伸阅读
详细了解数据建模策略、设计和实现