解读关联规则

[Qing]

很久以前，研究数据挖掘的康师傅告诉一种应用，叫做交叉销售。它是用来向用户推荐目标业务的。背后的原理是，通过分析现有用户的业务使用组合，对于那些常常一同出现的业务，这就是一种规则。譬如有一对业务总是出现，只要有其中一种业务的，70％的可能会有另一种业务。就可以对那些只使用一种业务的推荐另一种业务，因为这个规则的缘故，照理来说，成功率是很高的。

 

听起来很酷，我想这应当就是关联规则呗，数据挖掘似乎就是靠它被渲染起来的。那个经典的啤酒尿布的故事，可不也就是如此，发现买啤酒的和买尿布的同时出现的几率很高。这种规则，通过人的大脑，还真的不容易分辨出来。

 

这不，眼前摆在我面前的是一份产品关联分析的结果，我要从中找出一些有意思的规则出来。这是我的第一次，虽然以前也跟人喷过关联规则，但自己从未解读过这种结果。

 

虽然名称叫做"产品关联分析"，但看起来，更应该叫做"业务属性关联分析"。上面的例子当中是两项业务之间的关联，或者是购买物品之间的。当然，我们也可以将"订购xx业务"，或者"购买啤酒"当作用户的属性，不过属性的含义太含糊。此处，我们的产品关联分析中，将年龄、性别、客户级别、主叫多（大于平均次数）等等。可以看出来，这种和"购买啤酒"的属性多少还是有些差别的，但差别在什么地方，还真的难以用言语表达出来。

 

在关联分析结果中，仍然用"业务"这个词来表示上面提到的"属性"，将"年龄：19-26岁之间"作为一种业务多少有些奇怪。

 

既然是关联，就得考虑两种业务，业务一、业务二。据说这种叫做单维关联规则，还有一种多维关联规则。单维的关联规则表示为，如果A那么B；而多维的可以表示为，如果A并且B，那么C。明显，多维关联分析的复杂度要高一些。看来我们的建模人员选择了一种省事的做法。

 

每条关联规则，都有一些指标来衡量是否有效，或者成为"强度"吧。这里就是通过几个指标来衡量的。支持度、置信度和lift。

 

支持度是指使用两种业务（或称具有两种属性，下面也都可以用"具有属性"一词代替"使用业务"）的占总分析人数的比例。

 

置信度是指使用业务一，有同时使用业务二的，占使用业务一人数的比例。

 

lift，是指在业务一中使用业务二的比例，比在总分析人群中使用业务二的比例提升了多少倍。

 

可见如果lift值高，那么这个规则就真的是那么回事。如果A，那么B大多数情况是成立的。但也要考虑置信度阿，因为如果业务一和业务二关联性本身就是非常强，甚至是一种依赖关系的话，这个规则也就没什么意义。例如业务一为"使用GPRS"，业务二为"使用手机报纸"，置信度＝1，这条规则当然也就没什么意义。那么是否置信度越小约好呢？好像也不是这样的，越小，说明业务一、二关联程度并不高。因此，恐怕这个置信度得取一个合适的区间。当然，这个区间范围是多少，我是没有谱的。另外还得考虑支持度，如果同时使用两种业务的比例实在太小，那么这条规则能不能说明问题？即便后面lift能够达到10倍，甚至几十倍，恐怕也是因为基数小的原因。

 

将这几个指标的含义弄明白，接下来就是要将有意义的规则挑选出来。可摆在面前的关联数有几千条之多，让人头大。

 

[Qing]

上回书说到关联规则的解读中，几项指标的含义。

 

要知道几十种业务一和几十种业务二进行两两关联，会有多少种可能吗？应该用中学的"组合"来计算吧。具体公式是怎么回事已经遗忘，不过看看摆在面前的关联分析结果就知道这个量会多大了。

 

拖动滚动条，拖了很久，总共是八千多行，我的吗呀，怎么从中分辨出有意义的规则呢？

 

很自然地，我想到应该是过滤掉无意义的，可何谓无意义？要明确意义，就得明确目标。最后我们拿到这个结果是要用来指导营销的，对什么样的人推荐什么样的业务。那么就将业务一当作是"什么样的人"使用的业务，而业务二，就是要推荐的业务。

 

显然，如果是这样的，某些"属性"就不能作为业务二的。譬如年龄、性别、超常使用长途等属性，这些属性看起来是用户固有的，不是通过推荐而改变的。因此，显然可以将这些属性作为业务二的规则去掉。

 

为了区别，可以对每条规则增加一个标签，例如用"c1"表示刚才那种情况，表示业务二不适合推荐，去掉。这一步已经能够忽略很多的规则。接着再考虑还有哪些是可以忽略掉的。

 

作为业务一，是表示使用该业务或具备该属性的目标人群。可是否有些属性是强加给用户，而不是自然选择的结果呢？例如有一种"手机邮箱"的业务，很多营销案中会将它捆绑进去，结果大部分用户都有这个属性。其实这种属性并不能表明用户的业务特性，应当去除。标记成"c2"吧。

 

第三步，再考虑lift值的情况。lift值是指在业务一中使用业务二的比例，比在总分析人群中使用业务二的比例提升了多少倍。如果lift<1，意味着这条规则没有作用，业务二和业务一的关联很弱，甚至不比平均水平高。不仅如此，我还狠了狠心，将lift<3的都忽略，认为这些规则都是不值一提的，标记成"c4"。

 

第四步，考虑confidence，它是指使用业务一，有同时使用业务二的，占使用业务一人数的比例。其实可以如果业务一、业务二对调一下，lift是不变的，而confidence不同。如果confidence＝1，表示业务一完全依赖业务二，没有必要去根据业务一去推荐业务二。因此，可以设定一个confidence的最高阀值，也是一狠心下，设定为0.6。要注意，上面将lift<3和confidence<6都是一种主观的行为，没什么根据。

 

至于是否要为confidence设定一个最小阀值，我不知道该不该设，但此时，有效的关联规则似乎已经很少了，达到可以阅读的情况，于是便住手。将剩下的规则都看成有意义的。

 

不过最好还得分得再细一些，我想。

 

对于每种待推荐的业务，应该优先考虑再哪些目标人群呢？

对于某种目标人群，应该优先考虑推荐什么业务呢？

 

这简单，第一种情况。按照业务二升序、lift降序排序，将每个业务二的规则，标记出前三名和前三名之外。例如"p0"表示前三名，"p1"表示之外的。同样，第二种情况，按照业务一升序、lift降序排列，标记前三名和前三名之外。因为前面已经有"p0"/"p1"的标签，因此对于前三的，在原有标签后面加上"p2"，三名之外的，加上"p3"。如此，就会有四种组合的标签。

 

如果要查看最优先考虑的规则，就看"p0p2"的标签好了，此时已经非常少，一屏一目了然。

 

似乎是次不赖的解读，完美的第一次，我很得意地看着这份结果，有些沾沾自喜。

 

[Chen Ming]

庆哥是用的什么关联规则挖掘工具?(或者说是关联规则结果分析工具?


Chen Ming ， cm1...@hotmail.com
2006-7-25

[Qing]

上回书说到面对几千条的规则，如何层层过滤，抓住重点。

 

不过是自以为抓住重点了。但只要和产品关联分析最终目标一联系，就发现，上回的方法有些不实用。我们的目标是什么，不是没有驻牙，是要推荐业务。可经过一番过滤，将自认为没有意义的规则去掉，有些业务自然也就看不到。

 

在拿着这份结果跟人讨论的时候，无法用标签字段仅仅显示"p?p?"的规则，这只是一小部分。别人还是要针对每种业务二，看那些业务一跟其关联程度大。

 

可能一开始我就走错了路。

 

抓住重点的想法是没错的。但既然是推荐某种业务，那就将他们作为业务二的规则挑选出来，这样岂不是更能抓住重点？只是因为一开始并不知道用户最关注的是哪些业务，因此做了泛泛的过滤。特别是在对confidence和lift的过滤中。

 

上午在客户处交流这份关联分析结果。

 

预先设定的那个标签字段几乎没有用上。倒是有位女士提出对这个字段的疑问，也不想过多解释，只是说标明了规则的强弱。最后还是取了大约三四种业务二，一一地分析每条规则。

 

没有办法去给confidence或lift定义一个阀值，以区别强规则和弱规则。因为，有很多属性之间的是相似的，统计口径可能也是相差无几，譬如"使用wap"和"使用wap娱乐"，这两者有一种隶属关系。最后和业务二关联的lift很高，但显然，只需要取一个就作为选择目标用户的条件就可以了。但很多这样的有些重复的属性会导致理解起来困难。

 

我想，在设计关联分析的输入变量时，是需要考虑一下变量之间的明显关系，例如是否有依赖关系，甚至是否表示同一个业务含义。

 

曾有个想法——对于业务一、业务二看起来没有任何关联的，但数据反应出来的却关联很大，这种规则才是最有意义的。对于那种不用数据看就知道存在依赖关系的关联，没有必要用数据挖掘来做。因此，上回将confidence值太高的去掉也就是这个原因，因为明显表现了一种依赖关系。经典案例中，啤酒和尿布看起来实在是关联不大，可这种规则才是吸引人的。

 

经过和客户的讨论，上回自认为不错的方法实在不是个好点子。关联规则的解读不能只从数据结果看，必须得结合业务经验来阅读（不过这听起来像是废话）。

[Qing]

用的是teradata miner，具体怎么做的不清楚，不是我做的。但最后结果出来可以生成一张表：

（业务一、业务二、support、confidence、lift）

 

将这份数据放到excel中进行结果解读。我做的应该算是业务分析，不是挖掘建模，但刚才也谈到了一些，在关联分析建模前的变量选择上面（也就是业务一、业务二的选择），可能应该也是要让业务分析人员参与的。

 

On 7/25/06, Chen Ming <cm1...@hotmail.com> wrote:

庆哥是用的什么关联规则挖掘工具?(或者说是关联规则结果分析工具?

...

[BI-season's life]

联规则的解读不能只从数据结果看，必须得结合业务经验来阅读.(虽然是大的废话,但是这点我比较赞同.)我研究FP-growth算法做关联规则挖掘,后来试用sqlserver
2005,当支持度置信度设置较低的时候,生成的关联规则那个多啊,后来提高了这两个变量的值,靠,挖掘出来的规则我都看不懂.慢慢研究发现,原来由于对业务理解的不够,在做ETL的时候,没有删除重复数据.那个郁闷啊.

现在看来,大多数的关联规则挖掘都要牵扯到多维多层的概念,怎么做?如何定义维度,层次?都要跟业务结合的比较紧密.还有,就是增量更新后的关联规则挖掘问题(这是个技术问题,不知道现在哪个工具支持关联规则增量更新这个功能,庆兄知否?),都不容易.