深度案例 ToB 企业如何从 0 到 1 实现数据驱动？

企业服务行业深度案例 ToB 企业如何从 0 到 1 实现数据驱动 1 前言 企业服务的本质在于：了解客户的真实业务诉求，并为其提供优质的产品与服务，帮助其走出复杂商业环境中的发展困境。深谙此本质的企业，会从客户成功角度去重构整体业务。越来越多的企业面临着从“信息对称”到“数据驱动”的跨越。如果说“信息对称”是解决既有痛点，那么“数据驱动”则是挖掘并满足企业发展中的未知需求。 图1 企业发展阶段及自然增长模型 企业服务数据驱动的五大核心需求和三大挑战 围绕以用户为中心，企业服务数据分析的核心需求如下。 第一，如何以较低的成本获取高质量的客户？ 第二，如何快速判断线索跟进优先级，有效提升销售线索转化率？ 2 第三，如何诊断易流失客群和高价值客群，实现客户全生命周期支持与管理？ 第四，如何根据数据提供优质的客户服务，增强客户黏性，保障客户续约率？ 第五，对于 B2B2C 类型的客户，如何提供 B 端客户自有业务运营情况数据？ 图2 基于大数据的 ToB 客户行为洞察 在这个过程中，企业服务数据驱动面临着以下挑战。 3 首先，数据孤岛——前端行为数据和线下、CRM、ERP 等后端业务数据无法打通； 对于企业管理者而言，了解各个推广渠道，分别带来的流量和用户量是多少，每个渠道带来的用户的后续转化和留存情况如何，是最基本的诉求，但是我们最终关心的转化不仅仅只限于注册，我们希望了解到该批线索用户有没有转化为客户，有没有最终付费。遗憾的是，大部分企业的现状是，营销推广数据与企业 CRM 系统没有打通，所以就不能衡量每个渠道最终真正完成付费转化的有多少，从而不能筛选出最优质、ROI（投资回报率）最高的推广渠道，优化营销投入产出比。 其次，产品功能复杂，动辄上千个埋点，不知如何定义和管理数据模型； 企业服务相较电子商务、互联网金融等行业而言，由于产品功能复杂，涉及产品模块众多，经常会出现埋点无序混乱、数据采集缺失，而且这整个过程会涉及两个用户主体，一个主体是用户，一个主体是企业，那么如何设计数据模型更有利于分析就是一件令人比较头疼的事了。 最后，跨部门、多业务线数据完全独立，无法全局分析。 ToB 类产品一般会有多条业务线，涉及团队和业务线人员众多，如何将多条业务线整合统一在一个平台进行分析，满足不同团队不同人员按需提数，而不是给开发提出需求后，排队等排期，就显得很迫切了。客户的整体情况及健康度、渗透率等基础分析都依赖于多条业务线统一分析。 4 正文 案例：CRM 企业服务商从 0 到 1 的数据驱动实战 企业完整的数据驱动实践包括需求梳理、事件设计、数据接入、数据分析等阶段。以 A 公司——一家提供移动 CRM（Customer Relationship Management，客户关系管理）系统软件的企业服务商为例。A 公司坚持以客户为重，并一直有较强的数据驱动业绩增长意识——对客户获取、潜客线索管理和优化以及客户服务等业务流程进行持续优化，从而实现整体经营绩效的提升。下面将介绍，A 公司如何通过数据驱动增强客户黏性、提升客户满意度，从而保障客户续约率和提升 NPS（Net Promoter Score，净推荐值）。下面对 A 公司的需求梳理、事件设计、数据接入等流程进行详细介绍。 一、需求梳理阶段：“用户”与“企业”差异着眼点 A 公司希望通过数据分析了解客户和真实业务诉求，对客户行为的深度洞察，并为其提供优质的产品与服务，为实现获客渠道优化、销售线索转化率提升以及保障客户续约率，最终驱动企业业绩可持续增长。 通过以上分析，高效获取客户以及提高线索转化率、用户对于产品的使用情况等这些需求的着眼点是用户，而对客户整体情况以及健康度等的了解着眼点是企业。 1、针对用户的需求梳理，希望能够实现官网潜客用户行为精细化分析，针对产品进行精细化分析。 5 2、针对企业的需求梳理，A 公司业务线丰富，希望能够实现多条业务线的交叉分析，实现对企业的精细化运营。 二、事件设计阶段：科学埋点——属性扩充一个事件覆盖所有请求 根据企业的实际情况设计了以用户为主体、以企业为主体的两套不同的事件设计。 1、用户为主体的事件设计 针对官网潜客用户行为精细化分析，包括 WEB 浏览页面、WEB 元素点击、注册 & 登录等；针对产品精细化分析，包括 WEB 浏览页面、功能模块操作事件； 在 CRM 模块操作事件中，它会涉及 N 多功能点 N 多操作，那么如何设计数据模型才能高效分析呢？一个功能点一个操作设计一个事件吗？显然不行，这样会有 N 多事件。有没有可能设计一个事件就能包含 CRM 模块的所有功能点和所有操作呢？ 要做到这点，要先梳理 CRM 模块所有的模块、子模块和所有的操作类型，最终确定包含的属性有企业 ID 、模块名称、子模块名称、操作 ID 、业务类型等属性，这样就能通过这一个埋点事件，将用户在 CRM 模块所有行为都捕捉到。 2、以企业为主体的事件设计 A 公司一共有 5 条业务线，任何一个业务线的大多数操作请求都会触发一条后端业务请求，这个过程会涉及 3000 多个接口，在任何一个接口被调用，那么需 6 不需要设计 3000 多个埋点事件呢？实际上 A 公司完全可以设计一个事件通过属性的扩充去覆盖所有请求。 梳理所有的接口，如果接口设计的很规范的话，就能够按照一定的清洗规则对接口进行切分，最后将 3000 个接口数据清洗转化为一个埋点事件，它具有的属性有员工 ID、一级分类接口、二级分类接口、具体接口名、产品版本、Event_value 、FullAction 等。再结合丰富的用户属性，如企业 ID、企业名称、企业规模、企业分组、企业付费类别、企业一级行业、企业二级行业、注册时间、开通时间、代理商 ID、企业开通账号数、购买账号数、独立用户 ID 等。通过事件属性和用户属性的交叉分析，实现对企业的精细化运营。 三、数据接入阶段：前段+后端 A 公司因为要统计在线数据，任何一个接口被调用都要统计到，同时要保证发送的数据不重不漏，另外考虑到自己后台接口数据很规范，没有必要再耗费大量人力通过代码埋点的方式重新埋点，所以最终采用如下两种方式进行数据接入。 1、通过 LogAgent 这种后端数据实时导入的方式接入数据； 按照上述定义好的事件设计格式，通过 LogAgent 这种后端数据实时导入的方式导入神策系统后，A 公司可能发现了另外一个问题，这些数据都高度聚合，那么如何定位到具体的功能或功能模块呢？通过虚拟事件功能，业务人员自主定义自 7 己想看的功能。如只有完成了某些核心功能的企业才能算作活跃的企业，那么就可以按照下图进行配置活跃企业数这个指标。 图3 通过虚拟事件功能，业务人员可自主定义功能 2、业务模块操作行为数据前端采集或者将数据仓库中的数据导入系统中； 此种采集方式较上述调用后端接口事件而言，能采集到用户一些更细粒度的操作行为数据，同时这些操作纯属于前端操作行为，不会返回给后台接口的数据。 8 四、四大应用场景支持与管理客户全生命周期 以下是 A 公司的企业数据分析的应用实践。 场景一：一个埋点事件支撑 5 条业务线 21 个团队数据分析需求； 我们知道，企业服务类企业成功的关键是促使企业用户活跃，提高企业客户的留存，降低企业客户的流失，所以 A 公司需要对企业的健康度做一个比较全面的分析，及时发现健康度不佳的企业。 A 公司一直关注活跃的企业数和员工数有多少，以及每天的变化趋势；并进行企业质量的衡量，如平均一个企业中有多少个用户使用，在线的员工占企业开通员工的比例。 这个过程存在两个难点，如何定义企业在线和企业活跃。所谓在线即产品任何一个功能点被使用则可被看做在线，那么问题来了，既然是任何一个功能被使用，企业服务产品功能相对繁杂，那岂不是要埋上千个事件？通过事件分析模型将上千个事件整合为一个事件再配有详细的属性就可以解决了。每个业务线每个团队的人员只需要按照自己业务线的需求灵活配置出自己想看的企业指标数据就可以了。 场景二：快速判断线索跟进优先级，有效提升销售线索转化率； 来自营销渠道的线索量大，CRM 系统通常记录客户基本情况，如公司名称、跟进状态、联系方式及客户所在地等；销售团队往往通过电话第一时间去判断客户需求、购买意愿，至于每条销售线索的处理优先级、哪些需求紧急、客户赢单的可能性大小，较难进行快速和客观判断。因此，将判断销售线索情况的关键信息判断优先级，如 SaaS 公司产品 Demo 的注册、使用等行为数据，引入企业 CRM 系统，辅助销售进行快速判别。 9 图4 CRM 系统客户基本情况 采用后端 API 采集的方式，将神策分析中的用户行为数据集成到企业 CRM 系统，如图所示。将神策分析采集计算好的用户行为数据，传到 CRM 上来跟踪线索，主要集成以下两个字段： 一是，最近登录时间，即用户最近一次登录产品的时间； 二是，总查询次数，即潜在客户在产品 Demo 上核心功能的使用查询次数。 图5 后端 API 集成 Demo 试用行为数据至 CRM 系统 在神策分析中，通过虚拟事件定义核心功能使用次数，来计算“总查询次数”。对一款 SaaS 产品而言，其核心功能涉及的业务模块会很多，且每个业务模块下都有部分核心功能，任意一个核心功能的使用，都可以当作客户触达了产品的价值点，所以需要通过虚拟事件的方法，将分散的各个核心功能整合为一条事件，进行整体分析。 以神策分析自身的产品为例，神策分析非常关注用户在 Demo 上，“行为事件分析功能”、“漏斗分析功能”、“留存分析功能”、“回访分析功能”、“概览操作”等核心功能的使用情况，于是创建一条虚拟事件，如图所示。创建好后， 10 通过后端 API 采集的方式将该条事件的计算结果（总查询次数）传入 CRM ，从而辅助销售团队去查看产品试用情况、快速判断用户需求和销售切入点。 图6 “SA Demo 核心功能使用”事件分析 11 通过 CRM 和神策分析的结合，即可高效获取大量详细的销售线索相关关键信息，同时利用用户的行为，做到有的放矢，及时调整了销售跟进策略，对不同的客户排出优先级，提高整体销售效率和有效线索转化率。 1、优先联系总查询次数高的客户； 如果客户的核心功能使用次数或总查询次数从申请试用后，一直保持一个比较高的趋势的话，说明这个潜在客户转化的可能性比较高，销售团队会高优先级联系这批客户。 2、根据最近登录时间判断客户的使用动态； 优先选择最近登录时间比较靠前的客户，对于沉寂的客户，可以放低优先级，如果某个客户在沉寂一段时间后，某一天突然登录了，这时就可以及时跟进该客户，尽早掌握客户动态，确保最终的转化。 以神策数据的实际案例来看，销售人员拿到有价值的信息后，有针对性跟进，在策略实施一个月后，销售线索的有效线索转化率提高了 6%，间接提高了最终的赢单率。 场景三：提供优质的客户服务，增强客户黏性，保障客户续约率； 业务不会揭示问题，用户行为会揭示问题，哪些用户是高活跃用户，哪些是高风险用户，需要从客户活跃度的角度进行监控。 A 公司通过功能细分查看不同功能的活跃度，发现大部分保持高活跃的企业用户，主要使用的功能居然是考勤签到功能，而这个功能可能是销售人员迫于绩效压力，每天例行签到的，签完到就不使用产品了。从这可以看出定义产品活跃度的指标是不合适的，需要做出调整，只有做过核心功能的企业用户才算作活跃用户。完 12 成核心功能的企业数和员工数的变化趋势才是客户成功团队关心的第一关键指标。如果只是浏览或点击某个功能是没有用的，只有深入使用产品的核心功能，才能发现产品价值。 对于活跃度的定义更进一步，限定每个企业至少有 3 个员工在线，并且做了核心动作中至少一个才算作活跃企业。此时可以通过分布分析来看出企业活跃度分布。对活跃度低的企业，是一个重要的流失预警信号，需要重点跟进，加强培训。 场景四：对客户分层管理，构建企业画像，实现客户全生命周期的支持与管理； A