为什么客户画像这么难?

大数据
当前大多企业的客户画像的打造都难言成功,真正让客户画像发挥出价值的,却往往是互联网企业,为什么? 这里笔者就来谈谈自己的理解。

[[182443]]

客户画像即客户信息标签化,***地抽象出一个客户的信息全貌,可以看作企业应用大数据的根基。

每个行业每个企业都在提自己的客户画像,因为打造出了客户画像,一定意义上代表理解了客户的需求,从而可以在市场上占尽优势。

客户画像应是每个搞数据的人追求的核心的东西,笔者也如此,世上最难的事,莫过于懂人自己吧,而客户画像却要把人的特征用数据标签的形式表达出来。

当前大多企业的客户画像的打造都难言成功,真正让客户画像发挥出价值的,却往往是互联网企业,为什么? 这里笔者就来谈谈自己的理解。

数据的广度和深度决定了客户画像的潜力。

客户画像涉及人的数字化描述,也就互联网、云计算及大数据时代的到来,才让人类有了大规模采集数据的可能,以互联网公司为代表的客户画像应该是应用最为广泛的一类,但即使这样,在人的各类行为中,这些数据也仅占到极小极小部分,在工业、医疗、化学、心理、基因等更多领域,我们基于数据来刻画客户也刚刚起步。

同时,从横向的角度看,各类行业的数据短期内不可能有完全整合的机会,从纵向的角度看,每个垂直行业的数据在采集、建模等层面也仅仅是蜻蜓点水,数据的极度稀缺让360度客户画像这种提法没有现实意义。

任何企业只能说在打造一个属于我这个行业这个场景的画像,企业拥有的数据广度和深度决定了你客户画像的潜力,动辄360度画像是疯狂的想法。

现实的客户画像要以业务为导向。

客户标签建设会涉及到鸡生蛋和蛋生鸡的问题,先建标签还是先拿需求一直是BI纠结的事情,任何标签都要针对行业某个具体应用场景,凭空去构造一个标签体系,或者做了几次调研就认为掌握了需求,那也是自欺欺人,标签建设不可能毕其功于一役,但这个在很多传统企业却很常见。

很多时候总是纠结于标签没人用,一天到晚搞推广,其实是在启动项目的时候就埋下了祸根,即使建设的标签符合了业务方向,但往往很难有实用性,业务的复杂性和多变性超过了大多数建设人员的想象。

举个例子,比如很多运营商曾经基于上网数据做了一套上网偏好标签,但对外变现的时候,发现全然不是这么回事,大多合作的企业都希望自己做或者定制做,为什么?

因为你想象的标签too simple,too naïve,对于垂直行业不熟悉,导致了标签完全没有商业价值,比如自己打造的所谓的酒类标签,广告公司根本不需要,它需要某XX品牌的酒标签,客户的细节要求已经远远超过这些做标签的想象。

很多调研都会问业务人员需要怎样的标签,业务人员往往说我需要判断司机,我需要判断商务人士等等,但到底业务场景如何,有些也说不出来,反正可能未来需要吧,要避免这种情况。

无论是服务于企业内,还是服务外部,必须先有业务场景,才能有标签的打造,这是需要坚持的原则,当然有一种标签是例外,就是原子属性,比如收入、职业啥的,这是一种客户的客观描述,更多是作为组装的要素。

对于互联网企业来说,应用的驱动力本身非常强,而对于刚刚+互联网的传统企业来讲,标签更像是发出嫩芽还无人照顾的小草,初期非常容易陷入建设标签的深渊而不可自拔。

客户画像建设少提体系化。

我们习惯于构造一个客户画像的分类蓝图,希望对于客户的刻画方方面面都能顾及到,比如基本属性、短期偏好、长期偏好、位置属性等等。

我们在构造这个蓝图的时候,也非常纠结,到底对于客户描述应该分多少类呢,因此,东抄一个,西想一个,似乎从来没有满意的分类体系,对于这一点,大家都很纠结。

10个分类,100个分类,1000个分类?

判断客户画像的分类就好比要去追根溯源的探究人类的本质应该分成多少类别那么难,笔者倒觉得没必要纠结于所谓的客户画像分类管理,没有哪个企业能说自己的分类体系是***的,只能说适合的就行。

比如运营商有个客户画像的类别是通话属性,但是,大多数公司,根本没必要,而运营商之所以设置了这个类别,仅是因为这个方面的标签太多了,不搞个类别感觉头重脚轻了而已。

同样,也不要迷信互联网公司的分类体系,其***的目的也就是让广告客户能方便找到这些标签。

比如,我们就可以自己搞几套,一套按数据类别分,一套面向外部客户,一套面向内部客户,要走出属于自己的路。

还有就是纠结客户标签的数量的,有些公司,说客户标签有几百个,有些说上千个,这个时候,一些互联网公司跳出来,说我有上百上千万个。

没必要纠结这个,因为大家的行业背景不同,比较往往失去了意义:

一是统计的维度不同,比如某些企业将某个客户是否喜欢体育作为一个标签,而有些企业则将某个客户是否喜欢羽毛球作为一个标签,由此类推,因此,单纯比较数量没有什么意义,大家并不在一个维度。

二是企业的性质不同,某些企业没有那么多的客户或业务,没必要那么多的标签,比如淘宝个性化推荐估计标签数量要海量吧,但运营商商品有限,标签肯定有量级的差别。

对于有***主义的建设规划人员来讲,我们有时的确有点强迫症,但真的没必要。

标签运营是永恒的主题。

前一段时间听到一线的关于某些标签效果的反馈,更是振聋发聩,很多以前很好的标签,无论当初构建的时候是如何轰轰烈烈,效果是如何的好,但一年以后,很多打回原形。

为什么?

打天下易,守天下难,只管建不管埋似乎成了标签甚至是BI领域的通病,我们没有领会IT领域运维的精髓,系统运行的是否良好是IT最关心的事情,但标签运行效果是否良好却很难成为BI领域核心工作,大家都忙于建设,忙于出数,却鲜有人关心标签运维的根本意义。

传统企业在标签运营上的人员投入比例,有没有1:20?跟IT专业相比,估计是几何级的差距吧,甚至可以问,除了项目和开发,有没有标签运营人员?

到底该是谁来为标签效果的好坏负责?业务人员,建模人员,开发人员,运维人员?在传统企业,这是值得思考的问题。

也许,在精细化管理还远未成为企业的核心竞争力的时候,启动标签建设本是个错误,在热情冷却后,似乎每个标签的命运在建设的时候就已经决定了。

但还是要往前看,标签作为精益化运营的一个载体,未来的价值是毋容置疑的,既然做了投资,就需要持续的去运营,标签的效果也是随着一次次的迭代好起来的。

标签如果找合作伙伴做,就要有长期合作的打算,不要搞什么项目,如果合作伙伴总是打一枪换一个地方,尽量不要采用吧,一般IT项目的上线是终点,但对于标签却是新的起点。

互联网的在线运营甚至要求标签按天迭代,这在传统企业难以想象,以前还在为一个标签一个月用几次高兴呢,我们与很多先进互联网公司的差距,机制虽是导火线,但由此引起的思想和认知上的差距,进而在行动也也被越拉越远,这是笔者最为忧虑的。

未来是BAT的,并不是耸人听闻。

标签团队的建设任重而道远。

标签建设和运营是非常专业的事情,很多专做标签的公司,聘用的都是在某个行业有深度背景的专业建模人员,因为即使你有所有的数据,没有行业的业务理解,也很难创造价值。

但无论是数据建模师,亦或数据科学家,传统企业这类人才却非常稀缺,我们更多的是报表取数或者经营分析师。

以前总是对于互联网公司动辄上百的数据建模师团队感到惊讶,想着为什么要这么多人,有必要吗?

但当大数据业务逐步起来的时候,当数据量从以前的T逐步到P,并快速跃升上双的时候,就释然了,标签运营这个事情,没有任何捷径可走,如果要有所建树,付出的代价并不比重建一个企业IT团队少。

人工智能、因果的追求也许是客户画像的***方案。

为什么同样的关联交叉推荐,有些人乐于接受,而有些人则会觉得被偷窥了隐私而大骂一通,原因很简单,你采集到的数据无法表征更多类型的人而已,再深一层次,即使再多的表征数据也仅是表征,我们也许需要直达核心,即知道因果。

很多大数据书在提大数据时代要关注关联关系,而不要执着于因果关系,这句话有点现实意义,互联网企业依靠关联关系的确创造了很多应用,但诸如关联推荐的算法再不错,在可见的未来,如果对于人的研究没有大的突破,要实现此类推荐的跨越式提升很难。

那么,***的推荐是什么?

通过无时不刻的连接,商家需要知道你是什么样的人,处于什么样的境况,在这种境况下会有什么样的需求,这时对于你的推荐的准度是***的,甚至,你也许不再需要主动购物了,你要什么商店自动分发给你。

因此客户画像的下一个风口,估计就是人工智能吧,比如准确理解人的意图是每个搜索公司的***目标,输入关键字当然是一种理解意图的方式,但显然应该有更好的办法,这也是百度发力人工智能的原因。

人工智能、深度学习大家现在也听多了,从客户画像的角度看,它的现实意义是如此巨大。 

责任编辑:庞桂玉 来源: 与数据同行
相关推荐

2019-08-30 14:58:47

JavaScript程序员编程语言

2020-11-10 22:53:54

oracle数据库

2020-12-10 13:37:08

人工智能人机融合

2020-02-28 16:10:13

携号转网运营商中国电信

2020-12-08 05:41:46

人工智能人机融合机器学习

2018-06-22 07:51:13

2020-11-19 15:34:47

前端招聘开发

2011-05-12 14:57:58

2022-06-12 23:36:26

微服务架构单体应用

2022-09-16 10:14:41

消息顺序性分布式架构

2012-11-27 10:36:19

公有云Azure数据中心

2019-08-08 16:39:37

ERP信息化中小企业

2022-09-19 16:38:59

数据产品SaaSSnowflake

2022-06-10 14:13:43

数字化转型企业IT中小企业

2022-06-02 08:03:19

PyCharmPython代码

2024-02-26 21:15:20

Kafka缓存参数

2013-03-04 10:10:36

WebKit浏览器

2018-08-16 08:03:21

Python语言解释器

2020-02-27 15:44:41

Nginx服务器反向代理

2020-02-27 21:03:30

调度器架构效率
点赞
收藏

51CTO技术栈公众号