我们的朋友Benn Stancil最近写了一篇关于模板的好文章--他对可共享的、预建的仪表盘和报告的说法。帮你自己一个忙，读读它。

其基本思想是，共享的、可重复使用的数据分析多年来一直是一个梦想，而且还没有实现:

尽管我们的数据是一样的，我们的公司也是一样的，但没有一种一键式的方法来旋转出一整套的仪表盘。

模板似乎是不可避免的：可重用代码的概念是软件开发人员几十年来一直依赖的东西。它是所有软件构建的基本方式。数据界从一开始就从软件界借鉴了最佳实践，从Git的版本控制到测试的暂存环境。但我们仍然不能使用他们最强大的技术。

每次分析师转换工作时，他们必须从头开始重建相同的指标。即使他们以前做过（很多次），数据也是如此不同，以至于SQL需要完全重写。软件工程师只会调用一个像monthly_recurring_revenue(data) 的函数，然后继续他们的生活。

在这一点上，建立一个数据仓库并从头开始填充它，简直比把一个单一的指标投入生产更容易。

我们在Narrator的生产中使用模板已经有三年了--我们将介绍为什么它们还不普遍，以及它们如何被更广泛地使用。

为什么我们没有可重复使用的仪表盘或分析？

模板的问题是，它们需要一些一致性。分析师之所以要在一家新公司重建月度经常性收入指标，是因为数据的结构不同，即使不是这样（也许都是专门使用Shopify），企业对收入的解释可能也略有不同。

Benn指出，模板依赖于这两个核心假设:

每个人的数据大多是相同的
每个人的业务问题都是一样的

显然，我们并不生活在这个世界上。但是，即使源数据可能有很大的不同，他们从根本上使用类似的概念。

一个模板的数据模型

即使没有人的源数据是相同的，我们也没有理由不从他们那里建立一致的数据模型。Benn在他的文章中提出了这种方法

一个更好的方法--类似于Narrator采取的方法--可能是反过来：要求意义，并告诉人们提供一个与之匹配的表格。

换句话说，在 "订单 "表的样子上取得一致。要使用一个模板，首先要把你的源数据（Stripe或Shopify或其他什么）转换成这种格式，然后配置和应用模板。

这里的见解相当重要：即使公司的数据千差万别，一些高层次的概念如'订单'或'发票'几乎适合每个人的业务。正如我们之前所说，即使业务源数据可能相当独特，但其背后的业务概念却相当普遍。

例如，以Salesforce为例。他们定义了一个线索、账户、机会和联系人的概念模型。没有两个企业以相同的方式管理他们的销售团队，但他们中的绝大多数都将他们的流程与这个框架相一致。

拥有完全不同数据的公司在分析数据时，仍然会从机会经历阶段的角度考虑。具体的业务问题可能有所不同，但基本概念是相同的。

如果我们能在一个共同的数据模型上达成一致，那么我们就可以建立模板。

一个通用的数据模型

对标准化的概念进行建模，如 "机会"，或 "发送的电子邮件"，似乎是一个很有前途的方法。唯一的问题是，有太多的概念了，而且我们无论如何都无法在这些概念上达成一致。为Stripe和Shopify制作模板，然后就此打住，这更容易。

我们需要的是一种通用的方式来模拟任何商业概念。换句话说，我们要找的是:

一个有已知列的固定表格结构→这样模板就可以建立在它上面了
可以灵活地表示任何东西→适用于任何人的数据

在Narrator，我们把它称为活动模式。

活动模式

活动模式是一个用于数据建模的开放规范。我们的首席执行官艾哈迈德在WeWork首次提出了它，我们围绕它建立了Narrator的业务。

它是一个11列的表格，代表一个客户在一段时间内进行的活动 :

活动模式表

根据我们的经验，所有用于分析的数据都可以用这种方式表达。这也是一种相当自然的思考方式

一个客户在一段时间内进行的活动代表了客户与企业的互动方式。

这些活动可以是与企业相关的任何东西。例如，Uber可能已经*"预订了一次乘车"。Netflix可能有"评价一个视频"*。关键是没有人必须同意这些活动。只是数据模型。

那么，这与模板有什么关系呢？让我们编一个例子，看看它是如何工作的。

假设我把所有的数据都放在一张表里（叫做 activity_stream），并以活动模式为模型。我已经建立了两个活动：viewed_marketing_page 和inbound_sales_call 。

我决定计算每个月访问营销页面的唯一人数

SELECT 
    month,
    COUNT (DISTINCT customer) 
FROM ( 
    SELECT
        customer,
        date_trunc('month', ts) as month 
    FROM activity_stream a
    WHERE a.activity = 'viewed_marketing_page'
)
GROUP BY month
ORDER BY month DESC

这是很直接的。现在想象一下，我想计算给我们打电话的人的独特数量。这是同样的查询--我只需要把inbound_sales_call 。viewed_marketing_page

这个查询非常接近于一个模板--我们可以在完全不改变其结构的情况下切换活动。由它建立的模板也许可以写成带有一个参数的函数。

monthly_unique_customers(activity_name)

重点是，一个可预测的表结构打开了大量的可能性。

实践中的模板

这个玩具的例子很巧妙，但它在实践中是否有效呢？我们认为是的。在Narrator，我们在过去的三年里一直在生产中使用模板。

我们的模板是全面深入的分析，而不是功能，但总体方法是一样的。在我们为客户A建立一个分析后，我们将为客户B配置，然后是客户C，以此类推。

模板化分析的编写比较复杂，但好处多于成本。就像开放源码软件一样，我们可以随着时间的推移对它们进行迭代和改版。每当我们再次拿起一个分析，我们就会使它变得更好，而不是从头开始重写它以适应一套全新的数据模型。

活动模式除了支持模板化之外，还有大量的建模优势。我将在未来的文章中更深入地讨论它，但完整的规范是公开的，可以使用。

模板会成为主流吗？

这很难说。他们对我们有用，但我们会是第一个承认接受一个全新的建模方法是一个很高的标准。也就是说，这绝对是可以做到的。而且我们显然是有偏见的。

如果有人知道其他的模板实现，我很想听听他们的意见。或者你对活动模式的任何反馈或想法。

如何使用模板进行可共享的数据分析