数据分析能够应用到各个领域和岗位，那么在SaaS产品中的应用会是如何？本文将探索SaaS产品在数据分析中的应用，并对其指标与标签的设计进行总结分析，一起来看看吧。

数据分析是业务开展过程中，收集记录各种行为产生的数据，对这些数据进行一定的加工、清洗、分析，然后形成数据报表，得出分析报告或结论。

数据分析在很多领域都可以使用。我们可以使用探索性数据分析在数据之中发现新的特征，也可以通过验证性数据分析来验证假设的真伪。

在SaaS领域，数据分析可以用在多个方面，比如测算SaaS公司的经营数据，评估健康度；分析用户的各种行为偏好，改进产品；分析公司投入产出比，用于评估业务方向；数据分析本身也可以成为SaaS产品的一部分，为SaaS产品的用户提供数据服务。

数据分析在SaaS发展的过程中至关重要，是不断修正产品发展方向的重要参考，也是评估公司业务健康度的重要依据。通过对公司积累下来的海量数据进行统计、分析、研究并形成数据分析报告，我们就可以得到较为完整、科学的客观情况反映，从而协助我们制定出理性、正确的决策和计划，以充分发挥数据分析促进管理、参与决策的重要作用。

使用数据对产品相关的指标进行分析，比如使用频次、使用率、响应效率。数据分析可以帮助产品经理了解产品使用情况，产品经理可以调研去做一些总结分析，帮助产品改进。

我们的产品指标，是根据具体的业务需要进行设置，仍然以发票产品线举例，我们关注了几个主要的产品指标，大家可以参考。

（1）开票时长

发票开具是一项实时性要求比较高的工作，而整个发票开具流程又比较长，为了统计平台的开票性能，我们会定期统计发票开具时长，在5S以内完成开票的数量占比来评估产品的性能指标。开票时长计算规则为从发起开票请求到发票开具成功的时间差。

（2）功能使用率

发票产品涉及到多种开票方式、多种收票方式、多种查询统计维度等，我们会对功能的 使用情况做汇总统计，区分核心功能，在结合需求调研，评估资源投入方向。功能使用率的统计规则为功能菜单的点击次数。

（3）开票方式统计

由于开票场景很多，我们需要知晓哪些场景更受欢迎，哪些场景使用较少。使用较多的场景要持续做更多的优化，比如扫码开票，我们支持了十几种分支逻辑处理，对场景的拓展尽可能做到极致。对于使用相对较少的开票方式，需要结合调研去做需求和产品分析，判断是产品设计有问题，还是需求本身就不够刚性，还是用户使用出了问题，对应的给出产品策略。开票方式的统计规则为开票成功的数据来源方式。

以上是几个产品指标的示例，每个产品都会有一些自身的特点和场景，我们需要去找到评估自身产品的指标。这些指标只是我们改进产品的一个参考，还需要结合调研来判断具体的情况，指标数据好比“体检报告”，而结合调研才能“知晓病因”，这样后续的产品迭代才能“对症下药”。

经营数据的指标分析，对于SaaS公司非常重要，经常会被企业或投资人提及。比较重要的有续费率、客单价、客户终身价值、获客成本等指标。

我们简单解释下这些指标。

（1）获客成本 Client Acquisition Cost（CAC）

每获取一个新的付费客户，需要付出的一次性成本，反应公司商务拓展能力和业务开展效率。

获客成本=所有市场与销售费用总和/新获取客户的数量

（2）客户留存成本 Client Retention Cost （CRC）

获得付费客户后，持续保留客户所需的成本。

客户留存成本=订阅客户开启付费状态后，售后团队或客户成功团队的费用支出，通常包括协调的交付人员费用及云存储费用等。

如果客户的留存与商务团队也有关系，需要将商务团队的费用也进行相应的计算。不同的公司对于岗位职责范围的要求不同，如果硬套公式可能会出现较大的计算偏差。

（3）月经常性收入 Monthly Recurring Revenue（MRR）

每个订阅客户的订阅年费分摊到每月并求和。

MRR=所有付费客户月订阅费用总额。

MRR是体现SaaS企业估值的最核心指标之一。

（4）年度经常性收入 Annual Recurring Revenue （ARR）

将订阅客户的经常性收入规范化为一年期的价值。通常情况下，ARR 只包括合同约定的固定订阅费，即不包括临时性或一次性服务的费用。

（5）签约额 Booking

指与客户签订合同，客户承诺将要支付的金额（有法律约束）。签约额本身仅仅表示与客户达成了合同关系，但客户不一定会付款，财务上也不代表收入。

当签约额中有一部分是非约束性时（例如合作备忘录或者框架协议），通常不会一开始就把它们记入签约额，而是在采购订单生成时才记入。

（6）总合同额 Total Contract Value （TCV）

具有约束效力合同的全部金额，包括多年合同的全部采购金额。

（7）单年合同额 Annual Contract Value （ACV）

单一年度的签约合同金额；如果为多年合同，用于估算时，可以直接按照ACV=TCV/合同年数计算。

（8）客户续费率 Client Renewal Rate

客户续约率=本期实际续费客户数/本期应续费客户数

（9）金额续费率 Dollar Renewal Rate

有两种算法：

MRR续费率（MRR Renewal Rate）= 本期实际续费客户MRR/本期应续费客户续费前MRR

合同额续费率（Bookings Renewal Rate）= 本期续费客户合同额/本期应续费客户续约前合同额

（10）客户流失率 Client Churn Rate

客户流失率=本期内流失客户数/上期末客户数=（上期末客户数-本期末客户数+本期内新增客户数）/上期末客户数

（11）金额流失率 Revenue Churn Rate

金额流失率 =（本期内流失RR+减值RR-增值RR）/上期末RR

RR（Recurring Revenue）为订阅收入

（12）客户留存率 Logo Retention rate

Logo留存率=（本期末客户数-本期内新增客户数）/上期末客户数=1-客户流失率

（13）金额净留存率 Net Dollar Retention （NDR）

NDR=上期订阅客户本期贡献MRR/上期订阅客户上期贡献MRR

（14）客户生命周期 Life Time

是指一个客户持续为公司创造收入的总时长。客户生命周期=1/客户流失率

（15）客户平均收入 Average Revenue Per Account （ARPA）

指的是一个时期内(通常为一个月或一年) 平均每个客户贡献的业务收入

ARPA=MRR/客户数

（16）客户生命周期价值 Life Time Value （LTV）

反应客户能持续贡献的收入金额，LTV=单用户月均MRR*客户生命周期的月数

统计这些SaaS指标的数据从哪里来，怎么处理，需要数据分析方法。

比如计算获客成本,首先需要统计该时间段内的新增用户数量，再计算该时间段内产生的商务费用，比如工资、差旅费、商务等各类开支，如果SaaS获客的跟进时间较长，还需要计算获取客户的周期，通过获客平均周期，来统计对应的商务支出时间段内的各项支出。

这里面有很多的实操细节，我们在做指标分析时，每个指标都要进行分析核对，指标可量化的定义、数据来源、数据颗粒度、周期匹配、数据范围等都需要一一处理。

在SaaS产品中，可以对客户进行画像，通过画像来找到同类型的客户，进行产品订阅推荐；也可以将画像中标记为可能流失的客户推给客户成功团队进行跟进，促进续费。用户画像是对数据分析的应用，用户画像的标签体系建立过程需要大量利用数据分析。

在C端产品中用户画像几乎是产品建设的标配，在企业级SaaS产品中，用户画像对于产品的订阅续费同样很重要，应该受到重视。

对于SaaS产品的用户进行画像，可能是多个主体，比如代理商、企业客户、个人用户等。以企业客户举例，我们对其描述时，又会分为多个主题，包括企业基本信息、企业经营信息、企业行为信息等，我们称之为标签，从这些信息中，通过数据计算、分析，定义规则，我们可以生成活跃度、价值度等复杂的标签。

下图是一个企业画像的示例。

数据分析的各种需求，最终需要转化为指标，指标是数据分析需求的基础表达方式。

指标是用来定义、评价和描述特定对象的一种标准或方式。比如：新增用户数、累计用户数、注销用户数等是衡量用户发展情况的指标，客单价、平均单客成本、平均毛利率等是用来评价企业经营状况的指标。

设计或定义具体指标时，要区分定义指标的类型，从不同的维度来区分，可有多种划分方法。

按照指标计算逻辑，可以将指标分为原子指标、复合指标、派生指标三种类型。这是一种比较常用的指标分类方法。其中：

• 原子指标：也叫基础指标，指表达业务实体原子量化属性的且不可再分的概念集合，如交易笔数、交易金额、交易用户数等。
• 复合指标：指建立在基础指标之上，通过一定运算规则形成的计算指标集合，如平均用户交易额、资产负债率等。
• 派生指标：指基础指标或复合指标与维度成员、统计属性、管理属性等相结合产生的指标，如交易金额的完成值、计划值，累计值、同比、环比、占比等。

另外根据描述对象的不同，分为用户类指标、事件类指标等；

• 按照指标的变化频率，分为静态指标和动态指标；
• 按维度划分，有用户类指标、收入类指标、行为类指标等；
• 按客户生命周期划分，分为获客指标、履约指标、注销指标等；
• 按照重要程度，分为主要指标和次要指标等；
• 按管理职能来分，分为观测指标、管控指标和挑战指标。

标签是对指标深度加工的结果，标签注重人物或实体对象的描述。标签是根据业务场景的需求，通过对目标对象运用抽象、归纳、推理等规则或算法得到的高度精练的特征标识，用于差异化管理与决策。

标签是指标进一步的发展形态，其分类有类似的地方，但也有所不同。

按照标签的变化性分为静态标签和动态标签；

按照标签的指代和评估指标的不同，可分为定性标签和定量标签；

按照标签体系分级分层的方式，可以分为一级标签、二级标签、三级标签等，每一个层级的标签相当于一个业务维度的切面；

按照复杂程度分为：基础标签、规则标签和模型标签。其中基础标签通常是基于事实数据的，与指标有较高的重合度，比如身高、体重、性别等；规则标签一般是有一些简单的规则来控制，符合某种规则时才生成相应的标签，比如高价值客户标签，当一些指标达到特定的条件，就可以将用户标记为高价值客户；模型标签一般需要通过某些机器学习算法来生成，也称作挖掘类标签。模型标签基于数据进行建模。模型与规则不同的是，规则的生成是业务专家根据业务经验，组合多个指标制定的，规则不具有预测能力。模型的生成是应用科学的算法对指标进行计算，同时模型具有预测能力。

SaaS产品在客户不同的阶段，制定的标签有所差别，比如获客阶段、留存阶段等。获客阶段：可以关注用户在门户网站的浏览行为，客户的一些基本信息获取，现有用户群体的匹配等。留存阶段：可以关注用户对产品的参与度，比如操作频次，需求、问题反馈情况，需求及问题满足情况，增购产品情况，转介绍情况等。

我们从特征、场景、生产过程、展现方式等几个方面进行比较。

指标是信息化时代的通用语言。指标注重对事物及事件的过程进行全面的、体系化的描述，指标的描述范围广泛，既包括过程也涵盖结果；指标在逻辑上更严谨，表现风格也比较严肃，一般采用数值型。

标签是大数据与人工智能时代的通用语言。标签比指标更有概括性、更凝练，是对指标深度加工的结果；标签注重对人或实体的描述，侧重对局部特征和结果的描述，注重与具体业务场景的结合，描述的范围相对较窄；标签更生活化、口语化和符号化。

指标的应用场景很多，涉及企业的战略、管理、运营和支撑等层面；具体包括战略目标、市场定位、业务监测、业绩考核、任务分解、数据分析、数据建模、BI应用等。

标签的应用场景比较适合于用户运营。比如：客户画像、新增获客、用户激活、存量客户维系、数据建模等。

指标最擅长的应用是监测、分析、评价和建模，标签最擅长的应用是标注、刻画、分类和特征提取。

由于对结果的标注也是一种标签，所以在自然语言处理和机器学习相关的算法应用场景下，标签对于监督式学习有重要价值，这是一般性的指标难以做到的；而指标在任务分配、绩效管理等领域的作用，也是标签无法做到的。

指标是拆解式思维，运用的是化整为零的策略，将事物分解开来进行多角度多维度的描述，得到很多的指标；标签则是合成性、聚合式思维，将多个分散的指标按照一定的规则或算法进行综合加工，得出概括性的结果。

一般情况下，先有指标再有标签；指标是业务管理导向的，需要提前规划；标签是应用导向的，跟随业务需求的而变化，根据业务可随时增加；

指标的生产通常先要解决数据质量问题，统一数据口径；而标签生产涉及数据质量的问题较少，因为数据质量的问题已经在指标生产阶段被解决了；指标通常存在多个口径、口径不一致的问题，而标签在这方面的问题则相对较少。

指标的表现形态相对简单，通常以格式化的直方图、趋势图、看板、饼图等图形来表示。

标签的表现形态相对复杂，一般以可视化的图表或大屏为主；比如我们在用户画像展示时通常以词云图的形式来表现其特征。

指标设计需要从全局角度考虑，指标不是孤立的，需要成体系的进行设计。指标体系是将零散单点的具有相互联系的指标系统化地组织起来的体系，通过全局解决单点的问题，由指标和维度组成的。

指标体系一般需要经过业务核心指标确定、业务关键行为流程、选择模型进行多维拆解、确定优先级进行系统性整合等几个步骤。

SaaS平台的核心指标一般为客户增长率、客户续费率、获客成本、客单价等几个指标。业务关键行为流程，对于我们来说主要是代理商新增及代理商获取客户，自然把指标拆解为代理商增长率、代理商贡献户数等指标，如果再往前置环节延伸，还会涉及到代理商拜访、代理商转化、代理商获客等类似于AARRR的获客模型的指标。选择模型进行多维拆解，可以从指标构成来拆解：分析单一指标的构成。比如单一指标为用户，而用户又可以拆解为新用户、老用户；按照城市细分，比如一线、二线、三线等，不同城市的用户数量情况。还可以从业务流程来拆解：按业务流程进行拆解分析，比如不同渠道的用户续费率。

这些指标拆解完后，我们需要梳理先后顺序、重要性，然后评估优先级。

指标体系的设计，需要注意几个方面：

一是要确立关键指标，或者叫北极星指标，可以是一个也可以是多个，关键指标的确定有助于后续对重点工作及优先级的梳理，SaaS平台的北极星指标可以设定为续费率或增长率，发展阶段和行业特性不同，关键指标设定有所区别。

二是减少重复工作，将各不同的业务或业务线数据需求梳理，对指标项进行拆解，粒度可以到不需要进行拆分即可复用的程度，称之为原子指标，对于各方提出的统计事项，尽可能复用原子指标，降低后续的数据处理工作量。

三是要明确统计维度，用于统一业务、产品、技术等各环节的指标统计口径，避免数据维度不统一导致无法比较。

我们以SaaS续费率为例，进行说明。在此我们先介绍几个概念。

业务过程：完成该业务操作后，统计的指标会发生数量的变动；如加盟商入驻，订单支付，合同签约，续费服务等。

指标标识字段：是对指标名称的词典定义，

维度：一般指事物现象的某种特征，从某种角度出发的度量统计，角度即为维度。一般维度可用作数据汇聚，数据钻取，数据切片等。例如统计不同月份的用户数量，那月度就是一种维度。维度一般可以是时间、地区、渠道等。

精确度：指标度量时的数字精度，特别在分析金额一类的指标时，需明确保留几位小数。

秘密级别：如按照L1,L2,L3,L4四个级别，L是Level的缩写，L1完全公开，L2内部公开，L3 相关产品业务方&部分中高管理层可看，L4 决策层可看等，保密级别可自行进行定义。

了解这些概念后，我们接下来完成一个指标设计实例。

（1）SaaS的续费率，是一个复合指标，可以表达为：

客户续费率=实际续费客户数/应续费客户数

实际续费客户数，是原子指标，指统计周期内，实际已续费的用户数量。

应续费客户数，是原子指标，指统计周期内，最后一个服务月份(或服务截止日期)落在统计周期内。

（2）指标确定后，还需补充统计维度，有了维度，数据才可以进行比较：

• 时间维度，年续费率，月续费率；
• 地区维度，按省份统计；
• 代理商维度，不同代理商客户的续费率；
• 行业维度，企业所属不同行业的续费率。

（3）为方便标记指标，可以对指标建立标识字典，有经验可提前建设字典表；没有经验可在指标分析的过程中，逐步建立，针对我们的业务实际情况，我们对客户续费率进行标识如下：

fp_customer_renew_rate

第一个词fp表达为发票产品线，第二个词customer表达为客户指标（其他如代理商指标），第三个renew表达为续费（其他如新增、流失等），第四个词rate标示为比率（其他如数量，金额等）。

a. 指标字典表

将以上信息进行汇总整理，就形成了一个简单的指标记录表。指标记录表可包含以下项目（为方便展示，这里列为竖表，实际工作中横表使用较多），参考表：

指标字典建立以后，后续需要处理相关的数据，并通过一些图表等来完成指标的展现。

同指标设计一样，设计标签时，我们也需要建立标签体系。

标签体系的建设，需要有业务场景驱动，一定要和业务联动，驱动业务增长、优化，才能真正实现标签体系的价值。

第一步：确定目标，对业务目标进行分析。

第二部：选定目标对象，根据需求确定标签所打的业务对象，一般为客户、用户、活动等。

第三步：根据标签的复杂程度进行标签层级设计，一般比较复杂的标签体系为三级，可适当增删层级。

第四步：进行详细的标签和标签值设计，包括标签定义、标签类型、适用范围、标签的生成逻辑、标签取值等： （2）标签设计实例

SaaS平台的外部用户类型有三类，一类是C端客户，是企业所触达的用户；一类是企业客户，是我们平台服务的主体；一类是代理商用户，是帮平台开拓企业客户的合伙伙伴。

企业客户是我们平台服务的主体，这里我以企业客户为主体进行举例。

（1）业务目标

SaaS产品的续费是经营管理的重点工作，客户活跃度是我们评估客户续费的一个重要因素。

（2）标签定义

客户活跃度体现在多个方面，可以通过企业客户下的整体用户行为进行判断。比如有多少用户使用，用户的开票频次等。我们将客户活跃度标签的定义如下表：

上表是一个简化的标签定义模型，用户的活跃度还包括开票场景等核心功能使用频次等方面，对于值的定义也可以是多个区间分别定义，比如用户量可以分为小于2人、大于等于2人小于5人、大于等于5人等多个区间值。

（1）标签完整定义

表10-2是我们对标签属性值的具体定义，建立标签体系，标签属性值是重要的但不够完整。该标签完整定义如下（在标签设计过程，可以使用Excel表进行记录）：

一级类目：企业

二级类目：行为属性

三级类目：统计行为

标签名称：客户活跃度

优先级：高

标签编号：qy_xw_tj_hyd

标签类型：统计类

属性值类型：枚举类

数据来源：用户表、发票表

计算逻辑：参见表10-2

属性值：高活跃度、中活跃度、低活跃度

权限归属：客户成功团队、管理团队

（2）数据获取

标签设计过程中，就需要指明数据来源，计算规则，一般来说标签数据来源为业务数据、用户基本数据、日志数据、调研数据、算法加工数据等等，本文示例的标签数据来源为用户基本数据（用户表），业务数据（发票数据表），来源相对清晰，规则简单。

本文由 @原始森林 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。