浅谈B2B客户画像:让业务侧人员读懂和会用数据

于勇毅 营销云笔记 2017-04-06 09:09:35

编者按: 营销云笔记特约作者于勇毅老师今天为大家解析B2B客户画像,如何让业务人员读懂和会用数据。

某客户:“我们收集和整合了很多客户数据,包括历史采购,社交媒体,营销反馈…我们为了处理和运营这些数据投入的资源越来越多,到底收集和运营数据的边界在哪里?”

笔者:“直到这些数据建立的客户画像能支撑您的业务应用场景为止”

什么是客户画像?

客户画像在B2C被称为“Persona”,B2B被称为“Customer Profiling”,以前也被称为“360度客户视图”。作为广告主有很多渠道收集到各种客户数据,大致包括:

内部系统中留存,以历史采购和PII数据为主的“传统CRM数据”(Traditional CRM Data)

通过外部调研和营销收集的客户反馈数据(Response Data)

社交媒体,电商等平台的API接口提供的第二方数据(2nd Party Data)

营销技术收集的,描述客户行为的“数字数据”(Digital Data)

通过爬虫技术收集的开放数据(Open Data)

在收集了大量数据后,再通过客户识别(同人技术)打通数据源,以客户为中心建立各种标签体系,帮助广告主能更深度的了解客户。

客户画像有什么用?

根据以上的定义,似乎客户画像和普通数据的差别只是不同数据源的打通,在实际应用的时候,手上只有历史采购数据同样可以做客户细分,只收集到客户电子邮件地址一个字段同样可以eDM营销,那为什么要花精力去建客户画像呢?

1.客户洞察

这是客户画像存在的最大意义,如同本文标题所列,为了让业务侧(决策层,营销人员,销售人员,产品经理等)读懂和会使用客户数据,将对数据的应用上升到“洞察”的层面。

如图所示,技术和业务侧人员对于数据的理解往往南辕北辙,之间的沟通也大多是鸡同鸭讲。技术侧人员往往会热衷于

更多的数据源

更快的数据处理速度

更好的数据完备度

更便捷的数据抽取和应用

而对于业务侧的人员来说,天生没有数据解读能力,需要把复杂的技术侧数据语言对于客户的描述,通过数据挖掘等手段简化成业务侧能理解的客户标签(洞察)。

微信截图_20170406091515.png

比如,如表所列的两条客户数据,业务侧人员需要判断哪个客户更有价值,如果只从前面几个字段,业务侧人员是很难做出判断,但是如果通过数据挖掘,最后数据分析人员给出单一的指标“客户价值”,在实际使用的时候,业务侧人员可以简单的要求“这次营销只针对A和B级别客户”,而不用去搞懂背后的复杂逻辑。

微信截图_20170406091525.png

2. 统一口径

对于B2B客户的描述往往会由于口径的不同而造成误解,比如行业的划分,就有GB(中国国标代码),SIC(美国政府标准),IDC(某IT咨询公司自编码)等。

例如“中国银行“毫无疑问是“金融业”的客户,但是互联网金融的客户呢?现在没有一套标准会对这一新出现的事物进行编码,有的广告主把互联网金融客户归类到“金融业”,有的划分到“互联网行业”甚至“服务业”。当广告主的决策层决定营销重点是“金融业”的时候,其实存在着是否包含互联网金融这一细分领域的重大歧义

在客户画像的建立过程中,有一个核心步骤是制定各种标准,保证在广告主内部各部门对于同一客户描述有着同样的理解。

3. 通过客户画像完成对于行业理解的传承

对比B2C的客户采购决策链,B2B更加复杂而且个性化,没有一个专家敢说自己了解每个细分行业的所有客户特征。客户画像的建立是一个长期的积累过程,在业务侧不断发生人员变动的时候,每一代人员对于行业的理解都会在客户画像中体现。

例如医疗行业的“X康公司”,直接隶属于某省国资委,负责该省除了三甲医院以外的所有医疗系统的设备采购。这种非常个性化的行业理解,很难直接从数据层面得到,需要业务侧的专家输入后在客户画像中体现。

B2B客户画像的三个组成部分

微信截图_20170406091533.png

1. 企业画像

这是大部分B2B广告主谈及客户画像所指的部分,并且有最多的数据收集源。技术侧的原始数据包括:

基础信息:客户的名称,地址,联系电话等

行业属性:各种行业代码标准的所在行业

地域属性:所在省份,城市,城市级别等

历史收入:需要整合订单数据,了解客户在过去购买过的产品金额,产品类型,时间等

现有设备使用情况:包括客户采购的自家设备,以及可能安装的竞争对手设备

商机:已经获知的,并且销售人员跟进的客户未来采购意向

和内部销售组织的从属关系:现在负责这个客户的销售团队名称,销售人员等

企业规模(Firmographic):客户的规模,包括员工人数,年销售额,PC台数,纳税额等

名单制标签:是否是中央国资委下属企业,是否外企500强等各种名单企业

收集完以上信息后进行简化,最终业务侧需要的标签包括

客户购买潜力(Buying Power):综合客户的规模,行业,所处地域,是否名单企业等综合因素后,通过数据挖掘给出定量的客户采购预算数值,再结合历史收入,可以预计客户份额。业务侧人员在筛选的客户数据的时候,可以将目标客户描述为”2017年预算超过100,并且2016年我们产品的份额低于30%的客户。

微信截图_20170406091541.png

建设阶段:大型客户的重点项目采购往往会分为数期,并且延续数年,最有代表性的是政府主导的“十二金工程“(参阅百度百科)。通过历史采购的产品类型,就能推导这些项目的阶段,并且预测下一阶段可能采购的产品类型

客户细分:综合客户历史采购金额,购买潜力,所在行业等各个维度,给同一类客户贴上同一细分标签,例如以下“金银铜客户”的常规细分方法:

微信截图_20170406091552.png

2. 决策链画像:

这是B2B客户画像中最重要的部分,也是最难建立的。通常大型企业以及政教医疗客户的采购决策链收到大量自身不可控的因素影响,包括:

政府红头文件(限定品牌)

集团上级机构的统一采购(集采和分采)

客户内部部门间的分权(需求方,财务方,实施方,审批方等)

各种背景的代理商和厂商的影响

从数据角度能收集到描绘采购决策链影响因素的数据包括

客户树结构:对于大型集团型客户的上下级公司结构,以及有决策权的节点

微信截图_20170406091602.png

部门职能:在大型客户内部,一次采购会牵涉到需求方(实际使用产品的部门),采购部,审批部门等多种角色,通过客户的官网可以很容易获取客户的内部部门结构,再结合调研能知道对采购有影响力的核心部门

受影响渠道:受限于招标相关法律,政教医疗和大型国企的采购结果会在网上进行公示,通过爬虫对这些数据进行收集,可以很清晰的了解到对于客户采购决策有影响力的代理商和品牌(这个使用爬虫进行渠道影响力分析的内容,将在之后另文描述)

在获取以上数据后,对于业务侧的人来说,最终产出的客户标签只有两个:

客户是否有采购决策权,只要Yes或者No

渠道地图:针对具体客户销售不同产品,需要通过的代理商名字,下图是简单示意:

微信截图_20170406091610.png

3. 联系人画像:

虽然B2B的营销主体是客户(Account),但是在营销落地的时候仍然需要面对具体的负责人(Contact),常规用于营销的数据包括:

基础信息:联系人姓名,性别等

职位:所在部门,对接之前决策链画像中的部门职能,了解这个联系人在采购中是否有影响力

在线行为:通过营销技术,了解到联系人在线的行为,这是利用B2C技术进行B2B营销的模式。

联系方式:现在B2B的营销大多还是以传统的电子邮件,电话等信息,收集客户的电子邮件地址,电话号码的重要性是远大于各种数字ID的(例如Cookie,微信ID等)

营销接触和反馈:历史上对于这个联系人进行过的营销类型,客户的各种反馈动作(是否点击了电子邮件,是否接听了电话等)

最终产生的业务侧标签包括

客户兴趣图谱:同一个联系人在不同时间节点会不同的产品有兴趣,通过整合联系人过去的营销接触和反馈数据,能够了解到此人现在在浏览的内容,帮助营销找到正确产品

职位标签:同一个职能在不同行业和客户有着不同的称谓,例如IT部门的负责人,在银行可能叫科技处处长,在政府叫信息中心主任,在企业可能叫CIO…广告主要抽取目标联系人,需要把五花八门的联系人职位称谓进行标准化。下图是国内各个行业的核心部门以及不同联系人的称谓的对照表。

微信截图_20170406091618.png

建立B2B客户画像的步骤

1. 想清楚客户画像的应用场景:由于客户数据的收集和运营是无限的,先要做好最终应用的顶层设计才能有效控制投入资源

2. 想清楚应用场景需要的客户画像精度:把所有客户标签都做到精准是很难的,这就需要在资源投入和精度间找到好的平衡点

3. 想清楚支撑客户画像的数据源:包括内部数据源的整合和外部的采购和对接,数据源的拼合和运营需要大量资源,建立客户画像的数据需要控制在“正好够用”的层面

4. 数据清洗和对接:在收集大量数据后,还需要进行数据标准化,同人等大量底层数据处理工作,这是最耗费时间成本的

5. 客户标签体系的定义:标准化业务侧人员最终使用的客户标签定义 

6. 客户标签所需的模型建立:模型的建立除了数据挖掘的模式,在采购决策链画像建立过程中,还需要大量的外部调研。常规的数据挖掘模型包括

客户潜力模型(Buying Power Model):通过客户的规模,来预测客户的购买潜

客户兴趣图谱(Interest code):根据客户过去的营销接触,反馈和在线行为,预测客户当前可能有兴趣的产品

7. 应用及调试:客户画像要做到精准不是一日之功,需要长期经历业务侧人员的反馈,寻找新的应用场景,寻找新的数据源,新的模型这个闭环


长按二维码关注我们