嵌入式悲伤的五个阶段
所以您想把数据呈现在客户面前……但代价是什么？
当您考虑将数据呈现在客户面前时，您可能正在想象定制图表、彩色指标以及大量的留白。
尽管仪表盘能够为客户提供自助式分析，但它们很少是最佳工具。
本文将向您展示为什么从嵌入式仪表盘（或任何预定义的数据视图）开始往往会导致可维护性和可伸缩性问题。
如果您已经被说服，请查看可以采取的嵌入方法，以避免给自己带来麻烦。
示例用例
假设您运营一个电子商务平台。您的分析师构建了一个仪表盘，您的团队可以在其中查看每个商家的成功情况，基于诸如每个客户的访问量、随时间变化的交易量以及平均客户评分等数据。
您计划将仪表盘嵌入到一个面向商家的应用程序中，以便您的商家可以利用这些指标和可视化来理解和发展他们的业务。
阶段1：否认
人们每天都在使用您的仪表盘，所以您非常有信心它已经达到了高质量外部分析的标准。
阅读了提供客户分析的策略之后，您决定结合单点登录 (SSO)、数据沙盒和白标签，将现有仪表盘直接嵌入到面向商家的应用程序中。
阶段2：愤怒
在推出第一个迭代版本几周后，您发现您的商家非常喜欢使用这个仪表盘，以至于您的数据仓库无法完全满足他们的热情。
您的商家开始对仪表盘的加载时间感到沮丧。您决定将仪表盘的数据源复制到更快的数据仓库，并且调整实例数量以备不时之需。
阶段3：讨价还价
针对您的仪表盘的功能请求开始不断涌入——似乎您的商家越是使用数据，他们就会对筛选器、透视和自定义计算提出越多问题。
您的一些商家希望使用自己的收入计算方式。另一些则对折线图与柱状图有强烈看法。而一小部分（但声音很大）的商家甚至根本不关心图表——他们只想要一种获取去匿名化客户数据的方式，以便运行个性化营销活动。
阶段4：抑郁
您意识到数据库中的表格需要一些高深的 SQL 魔法才能支持商家要求的最新仪表盘功能。
您的团队没有时间重构 schema（他们正忙于维护现有视图），所以您开始编写自定义 SQL 脚本来满足最重要商家的需求。您的数据仓库因此变得杂乱无章，充斥着任意表格。
尽管您的产品团队尽力追踪更多数据和更多数据查看方式的需求，但您曾经成功的内部仪表盘似乎已经变异成了一个由数百个图块组成的怪物。
当您最终有时间查看商家仪表盘的使用情况统计数据时，您痛心地发现您的商家对这些图块只看了一次，甚至根本没看过。
阶段5：接受
您很高兴地回想起，整个场景都是假设的。当您反思这次模拟的创伤时，您开始明白
- 人们通过以不同方式查看数据来获得答案。
- 仪表盘请求（我能否获得数据的特定视图？）实际上是自助式数据请求（我能否获得我需要的所有视图来回答我的问题？）。
- 您不应该为了响应仪表盘请求而创建或更新您的表格。
思维转变：从嵌入式仪表盘到嵌入式数据模型
开始嵌入的最佳方式是将数据模型视为最终产品（数据模型指的是数据仓库中字段、表格和关系的设计）。
如果您的数据模型易于非工程师查找、理解、修改和验证，您将赋予他们使用数据的信心和自主权，以最适合他们的方式（并从处理临时仪表盘请求中解脱出来）。
当然，您仍然希望避免创建全新的临时数据模型请求。现在您有了一些时间，非常值得投入精力构建不仅从工程角度，而且从产品设计角度都优化的数据模型。
延伸阅读
了解更多数据建模策略、设计和实施
下一篇：分析的推拉效应
如何培养利用数据指导决策的文化。