分析的推与拉

如何培养一种利用数据指导决策的文化。

许多刚开始分析之旅的公司不确定如何创建和培养数据驱动的文化。无论您是否将 Metabase 纳入您的数据技术栈,我们都将讨论如何培养一种利用数据指导决策的文化。

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

  • 向人们“推送”重要数据。
  • 或让人们自主选择“拉取”哪些数据以及何时拉取。

要最大限度地利用组织收集的数据,您需要同时采取这两种方式。

拉取数据

对于团队内部的决策,我们应该允许负责这些决策的团队拉取与这些决策相关的信息。考虑以下示例:

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

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

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

在这种情况下,我们公司需要设置什么,以便客户成功团队能够以数据驱动的方式做出和评估这一决策?

首先,客户成功团队需要一种方法来拉取特定时间段内新客户的列表。这听起来很明显,但除非我们在产品开发期间预料到这种报告需求,否则我们需要要么要求分析师每周初给我们新客户列表,要么在产品管理工具中可用的报告集中添加一份新报告。现在,我们英勇的团队可以在需要时拉取如下所示的账户列表:

A list of accounts.

接下来,我们需要选择 10% 的样本用于我们高接触的入职实验。我们应该抵制选择前 10 个或以其他方式偏袒样本的诱惑,并且我们应该使其能够(理想情况下是无摩擦地)获取一个不对新账户位置、大小或其他关键属性进行加权的样本。如果可行,分析师或统计学人士的帮助在这里将非常有价值,他们可以生成此抽样过程并为客户成功团队填充表格。此时,我们应该能够拉取一个更像这样的表格:

An enriched table of customers.

现在我们有了一份可以进行入职的客户列表。让我们快进几个月,看看客户成功团队需要什么来了解这个决策的结果。

首先,让我们看看整体计划的效果如何。为此,我们需要定义什么是流失,然后计算积极入职样本中的流失率。对于流失的定义,我们假设最简单的情况,即用户账户有一个明确的“已取消订阅”状态。我们只需要提出一个问题,按状态和入职类型统计账户数量即可。

Results of an experiment: Status by Onboarding.

在一个理想的世界里,我们的流失率会直线下降到0%,但实验很少能达到这种效果。大多数情况下,像这样的实验结果会是“嗯……有点用。”通常,入职在某些情况下效果很好,而在另一些情况下则不然(例如,在下面的例子中,你会看到积极入职对金融行业的账户效果非常好,但对教育行业的账户则完全无效)。往下看,你会发现30%的教育账户在积极入职后流失了,而金融账户只有1%流失。

Cancellations by industry.

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

Response to onboarding: Status by Timezone.

通过深入研究这些账户,我们勇敢的团队成员注意到,核心问题在于90%的教育账户位于西海岸,而75%的金融账户位于纽约市(与公司处于同一时区)。由于将入职会议安排得太早(太平洋标准时间上午6点至9点),我们迫使可怜的学校管理员在咖啡还没来得及提神的情况下参加了入职会议。他们很快就明白了睡懒觉的好处,并将所有西海岸的入职会议都安排在下午晚些时候进行。总体流失率直线下降;这个决定(以及后续的修改)挽救了局面。

让我们在这里暂停一下,回顾一下公司中拉取信息的好处是什么。首先,我们将数据整理成一种能为客户成功团队提供有意义信息的格式。实际上,这意味着我们在设计信息底层结构时考虑到了分析的使用场景。我们可能不得不牺牲一些事务性要求,以使这些数据适合分析,或者为了便于分析而转换我们的操作数据。虽然让每个团队都理解底层架构或学习 SQL 很诱人,但如果我们将数据组织成适合电子表格显示的方式,效果会好得多。

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

推送数据

让我们回到组织结构图的另一端,谈谈如何在公司内部推动数据。

推送数据的目标是确保团队或公司中的每个人都了解一组核心数字或数据点。虽然我们在此使用“推送”一词,但我们并非特指传递信息的媒介。我们的意思是,公司需要通过确定一组核心指标来补充去中心化的“拉取”系统(每个人都可以查找他们想要的任何数据),这些指标定义了他们将如何衡量业务。

一般来说,少即是多:我们尝试向人们推送的独立数据点越少,人们消化它们的可能性就越大——关于什么才是真正重要的困惑也越少。

在许多公司,这套由中心决定的信息被称为关键绩效指标(KPI)、核心指标或其他听起来很官方的名称。这些指标表示业务应该根据其进行管理的成果。这些指标与期望的业务成果越紧密,效果就越好。理想情况下,我们应该制定这些数字,使其可管理,这意味着所有获得这些数字的人都可以采取行动(或启动行动)来改变这些数字。此外,通常还有一套指标(内部或外部)代表公司所处的环境。尽管这些不是公司可以控制的,但它们确实指导着整体行为,并且是推送的首选。例如,一家金融公司每天早上会收到其他时区隔夜活动的快速摘要,以便为他们的一天做准备。

这里,良好核心指标的关键之一是抵制用让我们感觉良好的指标来代替那些让我们了解我们实际表现的指标的诱惑。虽然很容易陷入成功公司一路顺风顺水的神话中,但我们越早意识到业务的某个方面不起作用,我们就能越快地纠正它。

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

何时推送数据

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

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

如何推送数据

有三种主要方式可以在组织内推送信息。最传统但仍然有效的方法是站在人们面前,从演示文稿中读出数字。全体会议、销售启动会、分析师电话会议:这些都是我们可以以低带宽但重磅的方式提供少量信息的场合。

虽然它们并非严格意义上的“推送”,但仪表板是收集指标的另一个地方。它们通常是了解前一天、前一周或其他时间段发生的事情的好工具。虽然仪表板可能会被滥用,并且需要一定程度的维护,但它们提供了一个获取当前数字的关键场所。

Dashboard of Very Important Business.

最后,推送的主要方式就是字面意义上的:将信息推送到人们的收件箱、频道等。一封每个人早上第一件事就能查看的电子邮件,或者仅仅是每周一发送的电子邮件,对于将最重要的数字呈现在人们面前非常有用。我们必须确保这些数字是重要的:创建一封没人打开的电子邮件很容易,但这会完全失去这项工作的目的。

Example of a nightly email.

在这里,比其他任何地方都更重要的是要记住数据推送的黄金法则:只推送以某种方式改变行为的数据。注意力是一种稀缺资源,尤其是在推送渠道中,我们应该专注于向有能力改变数字的人提供触发点,促使他们采取行动。

整合一切

既然我们已经单独讨论了这两种将数据交到队友手中的方式,那么现在我们来谈谈它们是如何协同工作的。

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

这有帮助吗?

感谢您的反馈!
分析师每周技巧
获取可行的见解
关于 AI 和数据的资讯,直接发送到您的收件箱
© . This site is unofficial and not affiliated with Metabase, Inc.