分析的推与拉

如何培养一个利用数据辅助决策的文化。

许多刚开始进行分析的公司不确定如何创建和培养数据驱动的文化。无论您的数据技术栈中是否包含 Metabase，我们都将讨论如何培养一个利用数据辅助决策的文化。

有两种主要方式将数据交到决策者手中

• 推送重要数据给人们。
• 或者让人们自己选择要拉取哪些数据（以及何时）。

为了最大限度地利用您的组织收集的数据，您需要两者兼顾。

拉取数据

对于团队本地化的决策，我们应该允许负责制定这些决策的团队拉取与这些决策相关的信息。请看这个例子：

• 背景： SaaS 产品的新账户目前正通过一系列描述产品功能的电子邮件进行入驻。然而，新账户在第一个月的流失率约为 15%。

• 决策： 为了降低流失率，客户成功团队决定主动为 10% 的新客户提供入驻服务，而不是在一周后发现账户不活跃时才联系他们。

• 成功标准： 一个月后流失率降低。

在这种情况下，我们公司需要如何设置，才能让客户成功团队以数据驱动的方式制定和评估这一决策？

首先，客户成功团队需要一种方式来拉取特定时间段内的新客户列表。这听起来显而易见，但除非我们在产品开发期间就预见了这种报告需求，否则我们需要要么请分析师在每周初为我们获取新客户列表，要么在产品管理工具中可用的报告集中添加一份新报告。现在，我们英勇的团队可以随时拉取如下所示的客户列表：

接下来，我们需要选择 10% 的样本用于我们的高接触式入驻实验。我们应该抵制选择前 10 个或以其他方式偏向样本的诱惑，并且应该确保能够（理想情况下是无摩擦地）获得一个不偏向于新账户的位置、规模或其他关键属性的样本。如果条件允许，分析师或统计学方面的人士在这里生成采样流程并为客户成功团队填充表格将非常有价值。此时，我们应该能够拉取一个更像这样的表格：

现在我们有了一份可以入驻的客户列表。让我们快进到几个月后，看看客户成功团队需要什么才能了解这项决策的效果。

首先，我们来看看整个计划的执行情况。为此，我们需要定义什么是流失，然后计算主动入驻样本中的流失率。对于流失的定义，我们将假设最简单的情况，即用户账户有明确的“已退订”状态。我们只需提出一个问题，按状态和入驻类型汇总账户数量即可。

在理想情况下，我们的流失率会降至 0%，但实验结果很少如此。大多数情况下，这类实验的结果会是“嗯……有点效果”。通常，入驻在某些情况下效果非常好，但在其他情况下则不然（例如，在下面的例子中，您会看到主动入驻对金融行业的账户效果非常好，但对教育行业的账户则完全没有效果）。看看下面，您会发现 30% 的教育账户在主动入驻后流失了，而金融账户的流失率只有 1%。

但我们不应止步于此。作为一家 SaaS 公司，净流失率是决定成败的关键指标，我们应该努力了解是什么让这个数字上升或下降。在我们完全数据驱动的组织中，客户成功团队本身就能够深入挖掘，将他们对我们账户的理解与 BI 工具的洞察力相结合，深入探究核心的潜在动态。

通过深入分析这些账户，我们勇敢的团队成员注意到核心问题是 90% 的教育账户位于西海岸，而 75% 的金融账户位于纽约市（与公司处于同一时区）。由于将入驻会议设置在早上过早（太平洋时间上午 6 点至 9 点），我们迫使那些可怜的学校管理员在喝咖啡之前就不得不参加一个入驻会议。他们很快就明白了多睡一会儿，并将所有西海岸的入驻安排在下午晚些时候的明智之处。总体流失率直线下降；这个决策（以及后续的修正）挽救了局面。

让我们在这里暂停一下，回顾一下在公司中拉取信息的良好支持是什么样的。首先，我们将数据整理成一种对客户成功团队有意义的格式。实际上，这意味着我们在设计信息底层结构时就考虑到了分析用例。我们可能不得不牺牲一些事务性要求来使这些数据适合分析，或者与事务性要求进行权衡，或者转换我们的运营数据以便于分析。虽然尝试让每个团队都理解底层模式或学习 SQL 很有吸引力，但如果我们以在电子表格中看起来不错的方式组织数据，我们会做得更好。

其次，允许拉取的目的是创建一种自下而上的、数据驱动的决策文化。如果我们能够设置好，让最接近决策的人能够根据自己的运营节奏提出和回答自己的问题，我们就能建立一个能够快速响应不断变化的业务需求的组织。这不仅比将问题推给专门的分析师团队更快，而且自助服务性质允许数据渗透到我们公司的每一个角落和缝隙——包括与客户、合作伙伴和供应商的互动。

推送数据

让我们回到组织结构的另一端，谈谈如何通过公司推送数据。

推送数据的目标是确保团队或公司中的每个人都了解一组核心数字或数据点。虽然我们在这里使用“推送”一词，但我们不一定是指传递信息的媒介。我们的意思是，公司需要通过确定一组核心指标来衡量其业务，以补充分散的“拉取”系统（每个人都可以查找他们想要的任何数据）。

通常情况下，少即是多：我们尝试向人们推送的独特数据点越少，人们消化这些数据的可能性就越大——关于什么才是真正重要的，混淆也会越少。

在许多公司中，这组集中确定的信息被称为关键绩效指标 (KPI)、核心指标或其他听起来很正式的名称。这些指标表明了业务应达到的成果。这些指标与预期业务成果的关联越紧密越好。理想情况下，我们应该制定这些数字，使其可管理，这意味着每个获得这些数字的人都可以采取行动（或启动行动）来改变这些数字。此外，通常还有一组指标（内部或外部）代表公司运营所处的环境。尽管公司无法控制这些指标，但它们确实指导了整体行为，并且是推送的绝佳选择。例如，一家金融公司每天早上都会收到其他时区的隔夜活动快速摘要，以便为当天的工作做准备。

这里良好核心指标的一个关键是抵制诱惑，不要用让我们感觉良好的指标取代那些能让我们了解自身表现的指标。虽然很容易沉溺于那些在通往伟大征途上从未遇到挫折的成功公司的神话，但我们越早意识到业务的某个方面出了问题，就能越快地纠正它。

举一个具体的例子，让我们回到我们假想的 SaaS 业务。通过总账户数量来衡量我们公司的整体成功是很诱人的，但——虽然看到几乎总在增长的大数字很令人高兴——这个总数使得我们很难完全理解用户群增长或缩小的速度。一个更好的数字是账户数量的变化，或者前一时间段内的百分比增长。在总账户数中会被掩盖的增长变化，突然变得清晰可见。

何时推送数据

将指标的推送频率与该指标所告知的决策节奏相匹配非常重要。如果我们通过需要一周时间计划和执行的行动来管理一个数字，那么每小时收到一次关于它的提示更有可能分散我们的注意力，或者导致我们手忙脚乱，而不是有助于高效决策。同时，考虑相关数字的自然周期也很有用。

如果我们谈论的是账户流失，客户成功团队采取的任何行动都不会在几天或几周内影响流失率。此外，流失具有自然的周期性：人们主要会在 30 天试用期结束时取消或未能续订。在这种情况下，每周甚至每月查看流失率是有意义的。如果确实需要对已终止的账户立即采取行动，那么我们不应该推送指标，而应该将该行动纳入终止工作流程中。

如何推送数据

有三种主要方式可以在组织中推送信息。最传统但仍有用的方式（因为它具有影响力）是面对面地向人们宣读数据。全体会议、销售启动会、分析师电话会议：所有这些都是我们可以以低带宽但重磅的方式传递少量信息的场合。

虽然它们不完全是“推送”，但仪表盘是收集指标的另一个地方。它们通常是了解前一天、一周或更长时间内发生的事情的好地方。虽然仪表盘可能被滥用，并且需要一定程度的维护，但它们提供了一个获取当前数字的关键位置。

最后，推送的固定做法就是字面意思：将信息推送到人们的收件箱、频道等。一封每个人早上第一件事就能查阅的电子邮件，或者只是周一的一封邮件，对于将最重要的数字呈现在人们面前非常有用。我们应该确保这些数字是重要的：很容易创建一封无人打开的电子邮件，这会彻底违背这项工作的目的。

在此处，比其他任何地方都更重要的是要记住推送数据的黄金法则：只推送以某种方式改变行为的数据。注意力是一种稀缺商品，尤其是在推送渠道中，我们应该专注于提供起点，促使那些有能力改变数字的人采取行动。

整合所有要素

既然我们已经分别讨论了它们，现在让我们来谈谈两种将数据交到队友手中的方式是如何协同工作的。

如果我们建立一个真正开放和可访问的方式，让每个人都能拉取他们做好工作所需的其余信息，那么推送数据将变得更有效。如果我们可以提供工具，让人们能够轻松地深入研究和剖析收件箱中的指标，我们就无需在电子邮件中塞满 KPI 的每一个可能的子指标。同样，对于有自然起始和结束的项目，如果我们可以让团队轻松拉取有用信息——并在项目期间将其推送给自己——团队就不需要外部帮助来跟踪其决策的进展情况。