嵌入悲伤的五个阶段
所以您想向客户展示数据……但代价是什么？
当您考虑向客户展示数据时，您可能会想到定制图表、颜色编码指标和大量的空白区域。
尽管仪表板能够向客户提供自助式分析，但它们很少是完成这项工作的最佳工具。
本文将向您展示为什么从嵌入式仪表板（或任何预定义的数据视图）开始往往会导致可维护性和可扩展性问题。
如果您已经相信了，请查看您可以采取的嵌入方法，以避免给自己带来麻烦。
示例用例
假设您经营一个电子商务平台。您的分析师建立了一个仪表板，您的团队可以根据每个客户的访问量、随时间变化的交易量和平均客户评分等数据来查看每个商家的成功情况。
您计划将仪表板嵌入面向商家的应用程序中，以便您的商家可以利用这些指标和可视化来了解和发展他们的业务。
第一阶段：否认
人们每天都在使用您的仪表板，所以您非常有信心它已经达到了高质量外部分析的标准。
阅读提供客户分析的策略后，您决定结合单点登录（SSO）、行和列安全以及白标，将现有仪表板直接嵌入到面向商家的应用程序中。
第二阶段：愤怒
在推出第一个版本几周后，您发现您的商家非常喜欢使用仪表板，以至于您的数据仓库无法满足他们的热情。
您的商家开始对仪表板加载时间过长感到沮丧。您决定将仪表板的数据源复制到更快的数仓，并且您调整了实例数量以确保万无一失。
第三阶段：讨价还价
您的仪表板开始收到功能请求——看来，商家使用数据越多，他们就越想了解筛选器、数据透视和自定义计算。
有些商家想使用自己的收入计算方法。另一些人对折线图还是条形图有强烈意见。还有一小部分（但声音很大）派系根本不在乎图表——他们只想要一种获取去匿名化客户数据以运行个性化营销活动的方式。
第四阶段：沮丧
您意识到您的数据库中的表需要一些高超的 SQL 技巧才能支持您的商家一直要求的最新仪表板添加。
您的团队没有时间重构模式（他们正忙于维护现有视图），所以您开始编写自定义 SQL 脚本来满足最重要的商家的需求。您的数据仓库被任意表弄得一团糟。
尽管您的产品团队尽力跟踪对更多数据以及更多查看数据方式的需求，但您曾经成功的内部仪表板似乎已经变异成了一个百格的怪物。
当您最终有时间查看商家仪表板的使用统计数据时，您心碎地发现您的商家只看过那些磁贴一次，如果看过的话。
第五阶段：接受
您很高兴地记得整个场景都是假设的。当您反思模拟的创伤时，您开始明白：
- 人们通过以不同方式查看数据来得出答案。
- 仪表板请求（我能得到一个特定的数据视图吗？）实际上是自助服务数据请求（我能得到我需要的尽可能多的视图来回答我的问题吗？）。
- 您不应该为了响应仪表板请求而创建或更新您的表。
思维转变：从嵌入式仪表板到嵌入式数据模型
开始嵌入的最佳方式是将您的数据模型视为最终产品（数据模型指您的数据仓库中的字段、表和关系的设计）。
如果您的数据模型易于非工程师查找、理解、修改和验证，您将赋予他们信心和自主权，以最适合他们的方式使用数据（并从处理临时仪表板请求中收回您的时间）。
当然，您仍然需要避免创建全新的临时*数据模型*请求类别。现在您有时间了，花时间构建不仅从工程角度，而且从产品设计角度都经过优化数据模型是值得的。
延伸阅读
了解更多关于数据建模策略、设计和实施的信息