先做用户属性细分

刘庆 20060425

又在开展客户细分的工作，这是挺让人头疼的，因为其目的性太不强了。
 
早先曾经提出过"用户标签"的想法，现在越来越觉得需要这样的东西。强名之 "用户属性视图"，当然这是一个逻辑的视图，物理上可以分布在不同的表当中。逻辑结构如下：
（用户ID，属性1，属性2，属性3…）

属性可以为"是否集团客户"，"是否VIP"，"是否使用彩信"，"通话时长"等。基于这个结构，当市场人员需要定位一个特定用户群的时候，可以通过属性的组合获得，例如对于"是否集团客户＝是 且 是否VIP＝是 且 是否使用彩信>200"的用户推荐一种新业务套餐。这将用户群的筛选决策交给市场人员，而不是用以前常提到用挖掘模型来作客户细分的方法。

客户细分模型一般基于聚类，其实输入的变量也就是用户的若干属性，也就可以将"用户属性视图"看作是挖掘模型依赖的宽表。然而它就像一个黑盒子，指定若干群，得把得把，得到每个群的特征，根据这些特征给每个群一个名字。可这样的分群如何和业务应用联系起来呢？常听说有哪儿的项目得到十种客户群，可这些客户群几乎都是停留在ppt中。因此，这种客户分群起到的作用仅仅是一种参考——"我想知道这些客户都有哪些特征，给我分分看"。

如此，不去奢望得到一个明确的客户分群，而是提供原材料，也就是哪些用户属性，让市场人员自由组合。在目前这个阶段，这种做法恐怕是客户细分更加贴近应用的现实之举。当然这也就要求对"用户属性视图"进行详尽的业务元数据定义，每个用户都有什么属性，其确切的含义，判断标准是什么。另外，要细到物理层面，还要维护属性和表字段的映射关系等。
 
当然，其实最重要的是对这些属性的分类，随着业务需求变化，会有不断增加的属性，但要让每个新的属性都能够归入某一类的属性中。例如在分析竞争对手时，需要判断哪些用户是"被策反嫌疑用户"，于是给这些用户打上标签。然后在业务元数据中，将这个属性归入类别"客户行为类>通话行为类>交往行为类"。

G 20060427

小弟是做人力资源方面的，在进行人力资源统计时，也常常用类似的这种方式，先做一张视图

工号  属性1  属性2    属性3    属性4……

然后根据实际需要灵活的进行筛选、汇总。非常的直观。

在数据量小的时候，通过excel的数据透视表就可以灵活的进行分析。

但是对于属性的分类，我还没什么概念，怎么才能保证能把新的属性都归入到已有的属性的分类中呢？

刘庆 20060427

我也是用excel来分类的，曾经用这种方法分析过存储过程、blog文章，最近又做了用户属性的分析，屡试不爽。
 
不过先声明一下这个方法的适用范围。G的例子中，每个员工的属性是固定下来了，还是会衍生出新的属性？如果是已经是人力资源报表，那么很有可能这些属性是固定的。但在这里所提到的方法是针对不固定的属性，是一个数据分析的过程，需要强调的是这是一个"分析过程"，并非分析结果。

首先明确分析对象，不论是存储过程，还是工号，或者是用户的属性，这都是"分析对象"，因此我所言的"属性的分类"跟对员工的分类没有太大区别，一个员工属于那个部门，是什么级别的职位，工资等级几许，这是对员工的分类。一位新员工进来，归入那个部门，什么级别的职位需要确定下来，新的属性也是如此。

不同的员工有一些共同的地方，也有不同的地方，分类就是要区别他们。属性也是如此，如果都将它们称作"用户的属性"，太粗放，很明显"客户年龄"和"网龄"是两类属性。因此，这个方法就是一个求同存异的过程。而对于"用户属性"这个分析对象，列出"属性之属性"，这和元数据——关于数据的数据是类似的，其实这里用户属性的分类正是元数据。
之所以分析用户属性，是为了客户细分的目的。目前还没有将这个方法抽象并表达出来，仍然有些难度，只能将过程描述出来。

首先列出了可能的用户属性，非常多，百十来个。接着从经验上增加了三个属性，大类、中类、小类，也就在excel中添加了三个字段。这种"类"是排他的，树状的，一个用户属性属于其中一个类，就不会属于其他类；一个小类属于某个中类，也不会属于另一个中类。
之所以分三个级别，因为考虑到每种类别数量不能太多。譬如，大类上面，可以将客户价值类、生命周期类、客户行为类和产品使用类和产品使用类，这完全是靠经验判断的。接下来细分到中类，客户价值，可以分成贡献和成本；生命周期类是指那些代表用户使用服务过程中的状态属性，可以分成业务属性和自然属性；客户行为类可以将通话行为、客户服务行为区分开；产品使用类可以将业务的开通情况和参与的营销案区分开，等等。

但此时发现，产品使用类的业务开通属性和生命周期类的业务属性很难区分，于是将这两个大类合并，都称为生命周期类。可以将业务开通、营销案等作为小类都归入"服务属性"这个中类当中。

接下来细分到小类，有些属性已经不容易细分了，例如对于生命周期类的自然属性，客户年龄、性别等就可以直接归入这个中类，无需细分。而对于通话行为这个中类来说，有几十个属性等待细分，例如什么主叫漫游时长、本地被叫网间通话次数等等。从经验上，根本无法分出小类。如果在小类中分出长途类、本地类、漫游类等、主叫类，显然有些属性即属于本地类又属于主叫类，例如本地主叫次数。

对于这种情况，便想到另一种做法，为这些通话行为属性打上标签。于是在excel中增加了一些字段，例如长途类型、是否漫游、主被叫类型、通话对端、时段、度量类型等，姑且称之为"标签类别"。通话行为属性可以通过这些标签类别组合起来，当然在每个标签类别里面的标签是互斥的，例如长途类型里面，本地和长途肯定是互斥，不存在"本地长途次数"这种属性。

通过这些标签类别，将每种通话行为属性区分开来，并且基于这个数据做成一个旋转透视表观察其数量分布情况，以进行分类。基本上从结果可以看出，主被和通话对端结合的属性比较集中，于是分成两个小类，主叫对端类和被叫对端类。另外时段方面的属性也有一堆，于是形成一类，还有呼转、交往圈方面的，各自形成一类。剩下来还有若干长途、漫游等结合的属性，为数不多，单独形成一类。大约形成六类，每类分布比较平均。

但后来想到，这样的分类方法有问题，跟究竟给出多少属性有关，这是尚待思考的。

最后的成果是得出了每个属性的大类、中类和小类这样的树状分类体系。以后每个新的用户属性都可以归入这个体系中。例如发现"是否使用xx套餐"，可以归入"生命周期类>服务属性>营销案"类中；再如"主叫xx号码的次数"可以归入"客户行为类>通话行为>主叫对端"类中。如果发现一个新的属性，归入不到小类，只能归入中类，或大类，说明这个分类体系还不够完善。

Babituo 20060428

看了庆哥和G哥对属性分类的讨论，感觉我对BI的兴趣原来是在不认识她之前就有了的，尽管我刚刚认识了她。

我曾经出过一道对系统分析员的招聘考试题:"请您对对人的分类原则再分类"，居然测到有好些人对这个问题莫名其妙。现在看来这道题对搞BI的人来说，只是小菜一叠了。

其实，我们对事物属性的认识，好多时候是含混的。属性，就其概念意义来说，本来是事物自身固有的分类原则，一般是不会动态增加的，增加的原因一般是:"属性是不会增加的，增加的是我们对事物属性的认识。"

为什么我们总会得到属性是会动态增长的印象呢?其中的原因大部分是:我们把事物对外界事物的关联，也认为是事物的属性了。比如说:某某客户的住址，我们认为这是客户的属性，似乎一点也不奇怪。但是，这个属性和类似客户的"性别"这种属性相比，有什么本质的区别呢?其实，客户的住址并不是客户的属性，而是客户的住所的属性，是住所的"地址"属性。因为，存在"客户要住在一个住所里"这个外在的关联，所以，住所的地址属性就可以顺着这个关联"投射"到客户这种对象身上来了。从原则意义上来说，这类属性不是属性，是关联。

不管是OO还是ER模型，用来实现关联的办法就是给类或实体添加"属性"，这极大地赞助了"属性"这个概念被轻易地得到偷换。

回头说"地址"，这是一类是非常有意思的属性。

按照属性的严格定义。任何的"地址"都不是事物自身的属性，而是事物在周边环境中可用来"定位"的一种关联；事物的"地址"一定是被定位事物的周边事物的属性在被定位事物身上的投射。

比如，某甲客户的住址是XX市YY街ZZ号。这个属性就关联到三种事物：城市、街道、住所。这三种事物的“号码”或“名称”的“属性”均来源于对包含它的事物的空间表面进行划分的结果。

对事物空间表面的划分结果是被划分事物自身真正的固有属性，这些固有的属性，通过“包含”的关联，投射到被包含的事物身上，于是，被包含的事物就拥有了“地址”属性，实际上这是一种关联。

区分很多“属性”是来源于关联，而非事物自身固有的特性，对做“对属性进行分类”这种事是非常有意义的。其中的意义交给各位自己去体会吧。

刘庆 20060428

对于严格称呼"属性"，欧阳大侠也曾如此说过，是这样说地：
 
"只有属于事物自身内部决定的才叫属性,说的玄一点,叫"定域存在".比如由内部结构决定的本质等.其余应该是关系存在,不应该叫属性"
 
其实将事物内在和外部区别开，似乎是很明显的事，可细想下去会走火入魔，想不清楚。什么是事物？内和外的区分是什么？这种东西经常思考，却无果，恐怕只能是慢慢体会了。
 
不过在对用户属性进行分类的时候，确实没有去考虑内在或是外在，大部分属性都是指外在与其他事物的关联。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友