哀伤嵌入的五阶段
你想要将数据放在你的客户面前...但代价是什么？
当你考虑在将数据放在你的客户面前时，你可能想象着定制的图表，彩色编码的指标和充足的空白。
尽管仪表盘能够向客户提供自助式分析，但它们很少是完成这项工作的最佳工具。
本文将向您展示，为什么从嵌入仪表盘（或任何预定义的数据视图）开始，往往会引起可维护性和可扩展性问题。
如果您已经确信这一点，请查看您可以选择的嵌入方法，以避免给自己带来麻烦。
示例用例
假设您运营一个电子商务平台。您的分析师已经建立了一个仪表盘，您的团队能够根据每个客户的访问次数、随时间推移的交易量以及平均客户评分等数据来查看每个商家的成功情况。
您计划将仪表盘嵌入到面向商家的应用程序中，以便您的商家可以利用这些指标和可视化效果来理解和增长他们的业务。
阶段 1：否认
人们每天都在使用您的仪表盘，因此您很有信心它已经达到了高质量外部分析的标准。
在阅读了提供客户分析的战略之后，您决定结合单点登录（SSO）、数据沙盒和白标品牌化，直接将现有仪表盘嵌入到面向商家的应用程序中。
阶段 2：愤怒
推出第一版后的几周，您发现您的商家非常喜欢使用仪表盘，以至于您的数据仓库无法满足他们的热情。
您的商家开始对仪表盘加载时间感到沮丧。您决定将仪表盘的数据源复制到一个更快的数据仓库，并且为了稳妥起见，您调整了实例数量。
阶段 3：讨价还价
对仪表盘的功能请求开始不断涌现——似乎您的商家在处理数据时提出的问题越多，他们对过滤器、旋转和自定义计算的需求就越大。
一些商家想要使用自己的收入计算方式。其他人强烈主张使用折线图而不是柱状图。一小部分（但声音很大）的商家甚至根本不喜欢图表——他们只想有一种方法来获取去匿名化的客户数据，以便运行个性化的营销活动。
阶段 4：抑郁
您意识到数据库中的表需要一些真正的SQL魔法才能支持您的商家提出的最新仪表盘功能。
您的团队缺乏时间来重构模式（他们正忙于维护现有视图），因此您开始编写定制的SQL脚本来满足最重要的商家的需求。您的数据仓库变得混乱，充满了任意表。
尽管您的产品团队尽力跟踪更多数据请求以及更多查看数据的方式，但您的曾经成功的内部仪表盘似乎已经变成了一个由一百个标签组成的怪物。
当您终于有时间查看您的商家仪表板的用户统计信息时，您心如刀割地发现，您的商家甚至从未查看过那些标签。
阶段 5：接受
您很高兴地记得，这个场景完全是假设的。在反思您的模拟创伤时，您开始理解到
- 人们通过以不同的方式查看数据来得出答案。
- 仪表板请求（我能获取特定的数据视图吗？）实际上是获取自助数据的请求（我能获取多少视图才能回答我的问题？）。
- 您不需要根据仪表板请求创建或更新您的表格。
思维方式的转变：从嵌入式仪表板到嵌入式数据模型
开始嵌入的最佳方式是将您的数据模型视为最终产品（并且我们所说的数据模型，是指存在于您的数据仓库中的字段、表格和关系的设计）。
如果您的数据模型对非工程师来说很容易查找、理解、修改和验证，您将给予他们自信和自主权，以他们最理解的方式使用数据（并从处理即席仪表板请求中节省时间）。
当然，您仍然希望避免创建一个新的即席数据模型请求类别。现在您已经节省了一些时间，构建既从工程角度又从产品设计角度优化的数据模型是非常值得的。
进一步阅读
了解更多关于数据建模策略、设计和实施的信息
下一节：分析学的推拉作用
如何培养一个使用数据来指导其决策的文化。