第六章 客户关系管理

 

       1．CRM概述

       CRM (Customer Relationshop Management):以产品为中心的应用方向转移到受客户需求驱动的应用定位上来。

       对客户了解得越多，就可以将与他们之间保持的长期而有价值的关系维护得越好。CRM的目标就是在整个时期内最大限度地维护与客户关系。它致于关注从市场工作、营销、加工与服务，到建立与保持互利互惠的客户关系在内的各个方面。为做到这一点机构必须开发一个涉及各个客户的单一集成视图。

       CRM 的另一个目标就是从不能获利客户变成可以获利的客户

       CRM需要一些基于完备的客户接触点数据获取与分发的新信息流。

2．操作型与分析型CRM

       CRM 要经受住双重性格综合的考验，因为它必须给出操作型与分析型应用这两方面的需要。

       分析型CRM由数据仓库中准确性好、综合性强与容易理解的客户数据来启动。于是，可以对过去做出决策的有效性进行测评，以便优化将来的协作行为。客户数据可以支持更好地识别上销（up-sell）与搭销（cross-sell）的机会、查明低效率的情况、生成需求与提高凝聚力等行为。

       收集（操作型源系统）－>集成（数据转储）－> 存储（数据传储）－>分析报吿（数据存取工具）－>建模  （闭环分析）

      

3．客户维度

       一致性客户维度是建立有效CRM的关键元素。得到良好维护与配置的一致性客户维度，是进行以客户为中心的合理分析的基石。

客户维度可能显得特别深（具有数百分行）与特别宽（具有数打或数百个属性），并且容易遇到相当快速的变化。对于更为复杂的情形来说，数据维度通常都是取自多个内外源系统的数据大融合。

       B2B (business to business)

       B2C(business to consumer)

 

注意：

统一的表示：设计方案应该在国家与国家之间保持一致，以便相似的数据元素出现在客户维度表中可预见的类似位置。

文化方面的正确的：这包括书信，电子邮件或者电话问候方面给出适当的称呼与个人标记工。

地址方面的差异：不管是从一个国家发向另一个国家的国外邮件（包括表示收信城市、国家的大写字母之类的）

 

常见的其他的客户属性：

       日期：日期维度的拷贝都被定义为语义明确的视图，诸如具有惟一列标签的“首次购买日期”。

       客户分析属性与分值：客户维度中最为有力的一些属性就是分段等级或者分值。这些属性很显然会在业务环境中呈现很大的不同。比如，性别、种族或其他生命阶段分段、收入或者其他生活方式等级、状况、引用源、崭新程度等

 

用做属性的聚集事实

       用户通常对于基于聚集性度量指标在客户维度上施加约束条件的操作感兴趣。那就针对这钟情况进行特别的事实表处理，放粒度大的事实数据计算好存放在事实表中。

 

代基数属性集的维度支架

              维度的低基数列被移出而形成单独的规范化表之后，再连回原来的维度表时，那么就说该维度是雪花状的。一般地说，在数据仓库环境中并不提倡进行雪花处理，因为它几乎总是使用展示操作变得更加复杂，另外还对查询操作性能具有负面的影响。

       如果支撑性的客户维度很大的话，确实可以节省不少的空间；如果查询工具坚持使用一个非雪花状的经典星型结构方案，那么可以通过一个视图定义而将支架隐藏起来。

       维度支架是可以授受的，但它们应该只是例外而不是规格，如果在设计要通过支架来解套的话，就应该给出一个红色的警告；还要注意避免屈从于对设计进行过度规范化处理的偏向。

 

大型变化客户维度：

       巨型客户维度比适度大小的维度更有可能发生变化。有时这种情形被称做快变超大维度（rapidly changing monster dimension）有一项技术手段能够在同时应付浏览器操作性能与变化跟踪跳战方面提供支援。解决方汉是，将分析频率高或者变化频率大的属性拆成称微型维度（minidimension）的独立维度。将比较恒定或者查询频率不高的属性保留在原来的巨型客户表中。

       以上像是会计科目的目主原料与辅助原料一样的功能！

       创建微型维度时，诸如收入与购买总额这样的不断变化的属性，应该被转换成呈波段分布的范围。尽客这会将应用限制在一组预定的波段，但它极大地减少了微型维度中的组合值数目。

4．多业务处理的客户数据分析

在将单个维度表同时连接到两个具有不同基数的事实表时，要非常小心，在许多情况下，这样会在关系型系统中返回错误的结果。将两个具有不同粒度的事实表直接连接在一起，也会引起同样的问题。