本文为客户画像基础篇，对于已具备画像相关经验一年以上的，可选择直接跳过。

当谈起客户画像的时候，你在想些什么？什么是客户画像，什么是标签，什么是客户分群...TA们又各有什么不同，彼此间的关系是什么？对于此类基础性的内容，恐怕大家的理解就会不一致。在企业客户画像的建设过程中，IT团队、业务团队首先有必要对齐下这部分，不然接下来工作咋个开展。

本文从客户画像基础角度，结合业内贯常做法、本人的实际经验梳理，尝试着回答如下6个问题：

1、什么是客户画像？客户画像的由来，与传统ECIF有什么区别？

2、客户画像中的若干概念：统一ID、对象、标签、标签的类别等

3、客户画像的定位，价值都有哪些？

4、客户主数据，数据仓库，客户画像间有什么关系

5、客户画像实施方法有哪些，彼此间各有哪些优劣

6、客户画像，客户分层，客户分群之间的关系是什么，常见的客户分层模型有哪些？

1、什么是客户画像

画像这个词是在C端互联网公司火热掀起的，但并非在这之前根本就无此概念，只不过称呼不一样罢了。过去10来来，互联网公司主要做的是C端生意，所以称为用户画像。由于笔者现就职于TOB的企业里，除特别指出属于B2B2C中的用户外，其他出现用户的地方统一用客户，如客户画像，客户分群，客户id，客户属性等等。

在画像这个词之前，国内围绕客户数据做文章起步较早的行业，主要是银行、运营商、航空公司。那时候的词，也没这么洋气叫ECIF(Enterprise Customer Information Facility)，也就是企业级客户信息视图，传统却厚重。

在ECIF中，其核心功能主要包括：

1）客户单一视图，一方面确定客户ID的唯一识别，另一方面从各个系统中整合客户的各类信息，包括基本信息、账户信息、合同信息、服务信息等。

2）客户分层分群，在客户信息整合的基础上，利用数学统计和挖掘算法，对客户进行各种标识，从而达到客户分群目的。

3）数据分析端应用，主要经营分析和辅助决策分析，按照一定的业务分析模型和客户分群类别，分析客户规模、分布、对公司收入贡献、客户流失分析、复购分析等

4）前台业务端应用，如根据普通客户、普通VIP客户、黄金VIP客户的分群，给客户推荐差异化的产品服务包。如大家司空见惯的，某一个月流量使用过多，就会收到运营商推荐你购买“xx元xxG的优惠流量包”的增值服务包。这属于一个融合客户信息整合，将客户分群及业务策略，以自动化方式联合起来，业务端事件式营销方式的典型应用。

放在现今大数据客户画像语境下，过去ECIF系统中的核心功能仍毫无过时，基本也是在这四点上做文章。现今，所不同的是：

1）数据的内容更广泛了，过去主要为内部交易数据，现在除此外还涉及操作行为日志、外部第三方数据；

2）数据的实时性更强了，过去都是T+1，随技术发展为数据的在线化，实时化处理及应用提供了可能；

3）数据的算法更丰富了，算法的开发门槛也更低了；

4）数据与业务结合的更紧密了，画像的应用价值，从数据分析型应用的幕后，走向了前台业务应用的台前。

经过上面这些铺垫，该是下一个定义的时候了。所谓客户画像，一方面确定客户唯一标识，全面整合客户各类数据，另一方面结合业务需求和运营模式，对客户数据进行分析和挖掘，打标签，最终形成客户全景信息视图。

2、客户画像中的若干概念

恰巧前不久在整理一份材料，有专门梳理这部分内容。不废话，直接上图。

图一：客户画像若干概念

上图中，有几项关键部分需要再拿出来说一下：

1）画像的对象，客户画像只属于画像对象中的一种。实际过程中，企业基于精细化化运营考虑，常见的对象还有产品、用户、伙伴、供应商、员工。例如：将带有“性价比高”及“智能化”标签的冰箱推荐给“90后”及“三口之家”的用户，就属于产品画像与用户画像共同应用的业务场景。

2）标签类别，在网络上，有人将标签分为事实标签、模型标签、算法标签（或预测标签），其实与上述中属性标签、统计标签、规则标签、算法标签的分类方式并不出入。事实标签包括属性标签及统计标签，模型标签是规则标签的另一种说法。

3）对象标识，确定一个标识对象的标识符是所有画像工作的基础。这个工作远非一个ID这么简单，要确定出这样一个ID也是比较困难的，特别是当企业业务系统陈旧、也没有主数据管理的情况下，具体在后面的篇章中会有讲到。

另外，如果是一个多元化经营的企业，建设客户画像时理想的做法，当然是对所有多元化业务做统一数据和业务摸底，统一确定客户的唯一标识。可，往往实际过程中会面临，人员配置不够，企业管理上的诸多因素，只能在物理上建立一个又一个“以单一业务领域客户”为单位的“小客户画像”。这样，其实并没有真正意义上完成一个客户数据整合，大集中的目的。不过，从另外一个角度讲，理想终归要考虑现实，企业在不同成长阶段会有不同的诉求，当交叉销售，跨业务领域对客户协同服务变的至关重要时，这种全局性客户整合就会被再次提上日程。

3、客户画像的定位与价值

关于客户画像价值，在度娘中输入关键字搜索，呈现的条目数以千万计。整体上讲大同小异，更多的属于表述方式和侧重点的不同。下面以搜索出来，其中一篇神策关于画像价值内容，谈下笔者的理解。

图二：客户画像的价值

显而易见，完成客户各类标签建设后，所沉淀的标签一定流动到业务应用中去才能发挥价值，否则就是一堆躺死在数据仓库中僵尸标签，仅供程序员们自嗨而已。

关于画像价值释放，我认为主要为两类：

1、数据分析类：客户实施标签化封装后，从而可以实现客户的深入洞察与研究，同时能支持基于标签化的结果对业务经营结果数、经营过程数能更加丰富和深层的分析。上图中用户分析，数据分析就属于此类。举例来说：做用户研究的，可以基于各类标签了解用户的各种特征；基于用户的各种标签特征，进一步去分析各类用户对收入、对利润等深入分析

2、业务应用类：客户标签的建设核心目的根本不在分析，而在业务应用，关注点应在如广告系统，精准营销、个性化推荐、以及客户全生命周期的精细化运营这类系统或业务场景中的应用中去。上图中精细化运营和产品应用就属于此类。例子不举了，网上已经说的泛滥了。

4、客户主数据，数据仓库，客户画像间的关系

首先上一张图，企业关于数据管理，通用化的一个数据分类：

图三：数据的分类

基础数据：为业务数据化，将企业经营管理设计的业务过程数据化，数据沉淀在IT系统。其中，IT系统在构建过程中，关于主数据、参考数据、交易数据的标准化问题是IT系统设计时要首要考虑的。

分析数据：为数据业务化，将业务数据化沉淀的数据矿产，通过大数据，机器学习等技术，进行价值的提炼，形成企业的数据资产，再通过服务化的能力一来建立符合不同业务领域和不同角色的数据产品，二来赋能现有业务系统。分析数据一方面整合IT系统基础数据，另一方面基于业务和数据整合方法生成分析数据。所生成的分析数据，数据仓库体系与画像数据体系为其中重要的两环。

通过这一张图，我相信大家应能得出客户主数据与数据仓库，客户画像间的关系了。

那么，数据仓库与客户画像，这两者之间又有什么关系呢？我们接着看另一张图：

图四：数据架构体系层级

数澜科技出版的《数据中台 让数据用起来》中将数据中台建设的内容域分为四个部分：数据技术体系、数据资产体系、资产管理体系、数据服务体系。每一个部分展开讲，其实都可以单独写一本书，由于聚焦在客户画像故在这里不做深入展开。在当前业内对数据中台暂未形成统一认知标准的情况下，笔者对于数澜抽象出的四个分类的顶层框架还是非常认同的。

数据资产体系，属于数据中台的血肉，主要整合提纯数据，使数据成为一种资产。数据资产体系是有数据层次的，可进一步分为贴源镜像层、数据仓库层、标签层（或称画像层）、应用集市层。以下为各层次的划分原则及说明。

图五：数据架构体系层级

数据仓库层的主要目的，建立数据标准规范的存储底座，将整合的基础数据分主题、分层次，分事实表维度表等，将数据分文别类、有章有序摆放好。

客户画像层的主要目的，从数据仓库各主题域整合客户各类信息，通过统计学、业务规则、算法等手段完成完成客户的标签化。

所以说，数据仓库为客户画像的核心数据源，客户画像为了完成业务场景的闭环，往往也会有部分从业务应用端回流的数据，同样会进一步丰富仓库数据，再到客户画像丰富对标签的刻画。

数据仓库和客户画像，为数据资产体系中核心中的核心，共同构成了企业所有数据应用的数据底座。

因为企业数据团队部门设置不同，往往也会导致仓库与画像间关系的不同，也会有建设内容上的重叠与交叉。以下为数据体系建设中，企业中比较常见的三类组织架构模式。如果对于一个已经长了十几条业务BU的多元化企业来讲，做数据体系的人才三五个，要么是这个企业各BU业务分散、数据分散，做数据的人也分散在不同组织里，要么是这个企业做数据刚起步，要么是这个企业根本不注重数据，数据的文化与思维有待进一步提高。

图六：数据体系建设团队组织模式一

图七：数据体系建设团队组织模式二

图八：数据体系建设团队组织模式三

6、客户画像的两类实施方法与优劣比对

最近在朋友圈看到这样一句话：没有顶层设计，做什么都是错的；没有底层逻辑，做什么都是对的。

顶层设计是宏观洞察、战略规划；底层逻辑是微观执行、逻辑支点。

让我们看一下，没有顶层设计只有底层逻辑，走向成功的案例：

1）中国的改革开放在经济建设上所取得的成就，家庭联产承包责任制、国有企业改革、建立经济特区、不管黑猫白猫能抓的老鼠的就是好猫...没有哪一项是从顶层设计开始的，也无法用任何经济学的原理比较好的诠释中国崛起现象，全凭勤劳的中国人民对美好生活，对财富的渴望，渴求改变命运这样朴素的常识。

2）阿里巴巴总参谋长曾鸣说，阿里巴巴每一项业务都是自底向上试出来、淌出来的，从来都不是关在办公室里老板们战略规划出来的。

是否顶层设计陷入无用论，恐怕也不是。顶层设计应该是企业的内核，没有顶层设计，你期望一个企业能够以长期视角来进行商业模式设计、人才战略设计、品牌设计、营销与服务设计等等。没有顶层设计，也就不知道未来方向在哪里，初心在哪里？在阿里云栖大会上，阿里人常说，因为相信，所以看到。我认为，在阿里人相信的远方，至少会有一条不那么明朗，但又坚信会达到的顶层梦想。

扯的有点大，有点远了，拉回客户画像的实施方法上来。说到客户画像的实施方法，有必要先说下画像包括的内容域，不然下面话题没法展开聊。关于客户画像的内容域，在后面的篇章中会再详细展开说，本文先预热一下。

客户画像可以看做一个系统，这个系统核心功能主要包括三部分：

图九：客户画像总体架构

1）、数据层：数据层工作在画像建设中占比较大，也就是本文前面所说的“仓库层”和“标签层”建设。数据层设计的好与坏，一方面依赖数据建模人员的功底，另一方面也极度取决于业务上确定的标签类目。

2）、应用层：也称功能层，现在互联网时代又有了一个时髦名字“用户画像产品化”，注意此产品非彼产品，并非是“个性化推荐”类型产品。数据层完成标签体系的构建工作，那么根据标签赋能业务是接下来要考虑的。如何赋能业务，用户画像产品化的功能将会是一个有利工具，这个工具显而易见两块功能：

a、标签的可视、查询、审批、下架等，以及标签类目元数据，让用户了解画像中所有标签内容，包括分类、业务口径、使用情况等

b、客户群管理，根据数据层创建的标签，用户能够自定义选择、筛选创建某一类客户群（如：30天内，不活跃零售行业类客户），并可对这类客户群实施分析，以及通过“同步”或“异步”方式对接外部系统（如营销系统，服务系统等）。

3）、业务层：如何赋能业务，除了上面第2）点的用户画像产品化外，还就是业务层。

画像业务层的应用，一方面为基于整合的客户数据，打造的数据产品。

当然现在的数据产品范围更加泛化了，不仅仅只是查询，做事后决策，实际已经是嵌入业务的事前和事后，成为了核心业务系统的一部分。如个性化推荐系统、大数据风控系统、笔者现在工作中的客户成功经营系统也算。

另一方面为嵌入其它业务系统，如营销系统、信息管理系统、客服系统，为此类系统提供数据API服务。在大多数企业，这方面做的好不好，比较大程度上取决于“其它业务系统”团队给不给你运营位，能够与大数据形成友好合作关系。原则上讲，在标签类目创建过程中，客户画像团队首先就要从营销线、运营线、客服线对应的业务，包括IT系统人员中做需求搜集与调研。毕竟，大数据团队内打造的数据产品，我相信只会画像标签应用领域的一个子集。

做了画像核心三部分功能的预热铺垫，下面可以正式开始聊一下实施方法了。这一块我想要说的，神策在网络上有一篇文章有相关性，所以以下有部分内容我会直接引用该文章。

实施方法一：一开始就要建一个全面详实“大而全”的标签体系，甚至想遵照行业中已经成体系的最佳实践进行“复制”，一开始就带有各种“幻想式”需求。

这种实施方法，容易带来的问题有：

1）大而全的体系以及最佳实践本来就是一个“美好的假想”，与实际应用到业务到产生价值间，存在巨大的鸿沟

2）标签的生产、开发、应用流程长、甚至某标签还未开发出来，就要被淘汰了。

3）客户画像系统的建设，本身会横跨业务、IT系统等多方人员，从标签的生产、业务应用、场景闭环来讲能否跑起来，本身需要最小化功能验证。前提条件是，需求是真需求，

实施方法二：以终为始，“如何用”决定“如何设计”。以终为始即从企业最终的应用场景和应用策略出发，来倒推企业的标签体系设计。如何倒推，神策在那篇文章里给了 3 个思路，每个思路也配合了案例解读。篇幅关系，案例就不贴了。

1、从用户触点、流程中找场景

2、识别特征、偏好，寻找场景和标签

3、从关键环节和指标，推导场景所需标签

这两种实施方法，咋看也并无特别之处，好比软件工程中的瀑布式和敏捷式。神策在那篇文章中，表达了废弃方法一，拥抱方法二的观点。

方法一与方法二真只能选其一，不能各取所长互补其短吗？答案我觉得可以的。

笔者18年底入职现在公司，当时部门经理说，你客户画像经验丰富，你看看这块事情能做出点什么？来回沟通了几次，当时我一直都未get到经理要让我做的这个客户画像是什么。我结合上述数据层、应用层、业务层的核心体系，当时给出了一个方案。同时，在应用层和业务层是按如下方式构想的。

图十：客户画像产品化功能架构

图十一：客户画像产品化原型（部分功能）

当时，我对这个事情的做法是按照“实施方法一”来构想的。如果我全盘来cover这个事情，我提出需要招聘一个偏客户画像方面的产品经理，这个产品经理有标签类目，客户分群、数据产品构建的业务经验，这样能补充我业务上的短板。

也正这个时间点前后，部门另外一位做产品的刘同学比较牛掰，趟出了从客户风险预警的场景中找到了画像标签应用的口子。这不就是实施方法二，以终为始，“如何用”决定“如何设计”嘛。后来呢，这个客户画像的产品经理也一直未招到，画像实施方法上基本上按照方法二在进行，我也没有全局去负责此事，只是负责数据层这块内容。

站在现在来看，

1、风险预警始终只是标签应用的一个场景，标签类目和数据层在设计上始终应该有全局视角的设计。今年做风险预警2.0（移动端），对标签应用更细了，发现部分原有数据表的设计不具备公用性要改造。

2、标签应用的场景，要有更多领域的探索，这样才能不断把雪球滚大。

3、无论实施方法一，实施方法二，在应用层关于标签的可视管理，客户群管理应该是要具备的。从另外一个层面讲，当前我们公司针对精细化客户运营，在业务无论营销，还是服务领域没有相匹配的运营策略，如C端司空见惯为了促活的红包、优惠券、礼品的活动。在现在这个阶段上即使做出来，我估计也是会被当做一个工具，顶多会被冲当一个提数的载体罢了。风险预警这样一个场景应用无形中集成了在客户风险监控这个领域，客户群的管理和跟进功能，在这样的前提下，上述原有规划的客户画像产品化的内容就可做可不做。

7、客户画像，客户分层，客户分群间的关系，常见的客户分层模型有哪些

随着流量枯竭的焦虑，企业视角由以产品我中心，转变到以用户为中心，都在谈如何进行精细化用户运营，针对不同的用户分层有更精准，更有针对性的运营策略。那么客户分层、客户分群又是什么，与前面谈到的客户画像又有什么关系？

客户画像，前面已经讲了，包含两个部分，一是整合各类客户信息的单一视图，二是客户的标签化。标签的类别分为属性标签，统计标签，规则标签，算法标签。

客户分层，不同行业客户的分层可能是多样性的，在产品发展的不同阶段客户的分层也会有不同的变化。基本上客户分层是基于客户管理大方向上的划分，即你希望用户朝什么核心目标努力。如常见的RFM模型，通过衡量客户价值来进行客户分层，定义出一般价值客户，重要价值客户。

客户分群，客户分群可以理解说是客户分层的进一步精细划分，将客户分层中不同层次的用户切分为更细的粒度，与客户分层相辅相成。如，找出“重要价值客户”中“零售行业”、且“年营业规模大于2000W”的客户群体。

下面，看一下这三者间的关系。

客户分层的划分，进而的结果其实就是完成了客户画像一项标签的刻画，所以客户分层属于客户画像的一部分；

客户画像中属性标签，统计标签为通过整合了客户各类数据，基于统计学来定义的事实类标签，这类标签通常都比较简单。如：最近7日登录次数。事实类标签，本身来讲也属于客户分层的一种，即客户个性化特质分层。这类分层或标签，更多是站在数据和技术的角度进行定义，被业务直接使用的可能性不大，但是会是生成业务使用多的标签（规则标签和算法标签）的基础。如根据“最近7日登录次数”的事实标签，可以进一步生成“客户活跃度”的规则标签，“客户活跃度”被业务应用的广度就会大大增加。

客户分群，也就是客户画像中各类标签组合，生成一类又一类客户群体。

客户分层，一定是紧贴业务，以业务为主才能定的出来，在客户画像中分布在规则标签和算法标签中。之于业务来讲，客户分层才是画像中的重中之中。

搞清楚了三者的概念以及关系，下面我们来看常见的客户分层模型有哪些？

以下内容，基本为上学习了诸多网友们关于客户分层的文章后，我的学习整理。

1、客户个性化特质分层

2、客户身份分层

3、客户生命周期模型分层

4、客户价值模型分层

5、AARRR模型分层

6、客户活跃度模型分层

7、客户忠诚度模型分层

8、客户流失预警模型分层

9、客户偏好识别模型分层

10、其他，购物决策力模型，促销敏感性模型，易观发布的 ARGO 成长模型

以上10种分层方法，第1比较简单，就是上面我们谈到的事实标签，一般在说客户分层时基本不会谈到这一类的分层模型。

那如何判断自己的产品适合哪种分层呢？

一般来说除1、2外的分层方法基本上适合大多数产品，针对1、2的分层方法也有一定的判断标准。

1、是否需要用户个性化需求分层判断标准：依据业务标准化程度来判断

业务标准化程度低，则适合用户个性化需求分层

举例：

天气类APP，相对业务标准，用户进入后只需要查询最近天气情况，这类产品就不需要做用户个性化需求分层。

2、是否需要用户身份分层判断标准：产品内用户相互影响程度

如果产品内存在用户互相依赖，则这类产品一定要做好用户身份分层

举例：

抖音，用户之间依赖性就特别高，用户身份大致分为：政务号，签约号，网红，普通创作者，信息获取者，用户之间相互依赖，彼此诉求特征不一，不同身份间的用户运营策略不同。

确定了自己产品合适的分层方法后，分层怎么做？下面将最常用到的客户身份分层、生命周期模型分层、客户价值模型分层等几类展开看一看。

客户身份分层

用户身份分层常见的用户金字塔模型，不同的产品其金字塔不一样，也不是所有产品都适合金字塔模型分层。

用户金字塔模型的建立，自上而下，上层影响下层。主要为了让运营者对用户的构成有一个清晰的了解，并且在实际工作中，往往需要抓住的是金字塔顶端20%的用户；可以利用用户进行有效地管理用户；并且每个模块可以再进行拆解成小金字塔，作为管理工具，增加用户和用户之间的关系。

那基于自己的业务我们可以按照以下来进行梳理自己的用户金字塔模型

（1）、用户之间是否存在关系（不存在，则不适用于金字塔模型）

（2）、用户之间是否会因贡献、稀缺、专业度产生阶级分层（对应分层激励）

（3）、用户阶层见可否自然晋升（对应晋升激励）

针对产品的不同，存在着用户分层的双金字塔结构。如这样的产品，一个围绕着内容的生产，一个用户的服务，相辅相成构成了双金字塔结构。

在网络上也有人提出一种叫用户状态分层，个人觉得与用户身份分成具有极大的相似度。

客户生命周期模型分层

针对不用周期常规考虑动作

阶段A:引入期。发现和获取潜在客户，并通过有效渠道让用户了解到产品的核心价值，并尽可能便捷体验核心服务。

阶段B:成长期。通过刺激需求的产品组合或服务组合把客户培养成高价值客户。

阶段C:成熟期。培养客户的忠诚度。

阶段D:休眠期。建立高危客户预警机制，延长客户的生命周期。

阶段E:流失期。该阶段主要是赢回客

客户价值模型分层

RFM模型作为一个存在已久的用户价值模型，被广泛应用于传统、销售行业。

首先解释一下RFM模型的构成：

Recency：最近一次消费，即用户距离当前最后一次消费的时间。最近一次消费的时间距今越短，对我们来说更有价值，更可能有效地去触达他们。Frequency：消费频次，用户在一段时间内，在产品内的消费频次。Monetary：消费金额，即用户的价值贡献。

基于这三个维度，我们将每个维度划分为高、中、低三种情况，并构建出完整的用户价值象限。

通过上面的RFM模型，我们可以更加直观的把用户划分为8个不同层级。如果能够找出产品内用户隶属于以上8类中的哪一类，就可以针对性的制定运营策略。如对“重要保持客户”，不希望它流失，运营人员就需要专门针对这类型用户，设计召回用户运营策略，这也是RFM模型的核心价值。

RFM模型在不同行业的尝试，R/F/M可以有不同定义去尝试：

金融：投资金额、投资频率、最近一次投资时间；

直播：观看直播时长、最近一次观看时间、打赏金额；

内容：评论次数、评论字数、评论被点赞数；

网站：登录次数、登录时长、最近一次登录时间；

游戏：等级、游戏时长、游戏充值金额；

在划分完不同层级后，最困难的事情在于如何制定每个值的高、中、低评判标准。一般不借助算法，可以用统计学里的平均值法和分位数法，借助算法就要通过KMeans聚类算法等手段。

AARRR模型分层

客户忠诚度模型分层

用户分层的本质是分层逻辑，中心思想是根据单一/复合数据指标划分层级，一般不超过5层。过多分层就会变得复杂，不适合运营策略的执行。

以上针对常见的客户分层模型，只是给出了一个框架上的感性认识。对于每一个模型，从业务目标、北极星指标拆解、模型理解与实现、以及模型如何与业务策略、业务流程及角色闭环起来，包括闭环跑起来后数据结果分析，这每一步要吃透要下的功夫都不会少，留着后续的篇章再聊。学是为了用，理论加实际才会更加强化，这些模型哪些适合所在的企业，如何应用到实际工作中去，也是需要去考虑的。

当然更牛逼的是全线上能自动化完成。