大数据运营（二）



数据化运营常见数据分析项目

数据化运营分析项目从简单的统计分析到复杂的机器学习，类目众多，这儿我以运营流程为主线，介绍一下较为典型的分析项目。

1、目标客户的特征分析

数据化运营的第一步是找准目标客户，目标受众，而后才会设计相应的运营方案、个性化产品与服务；

目标客户的特征分析分为两种情况：一种是试运营前的虚拟特征探索；另一种是在试运营后来自真实运营数据基础上的分析、挖掘和提炼；

试运营前的虚拟特征探索指目标客户在真实的业务场景里并未产生，没有与真实业务环境一致的数据来源可用于分析目标客户特点，只能通过简化、类比、假设的手段进行模拟探索，从中发现一些似乎可以借鉴、参考的目标用户特征，之后根据真实的效果反馈来修正目标用户特征；

试运营后的特征分析相对而言比上述这种来的更为真实可靠，也贴近业务。数据的提取完全符合业务需求，也收集到了真实使用该产品的用户数据，不再是虚拟的猜测和模拟；

2、目标客户的预测（响应、分类）模型

在试运营且拥有一批真实用户后，我们可以根据这批核心用户的特征，来寻找拥有同类特征用户的群体，根据业务环节的不同，可以分为流失预警模型、付费预测模型、续费预测模型、运营活动响应模型等；

一般来讲，如果响应比例低于1%，该响应模型属于稀有事件响应模型，主要通过抽样的方法人为放大分析数据样本里响应事件的比例，增加响应浓度，从而使得模型更好地捕捉自变量与因变量的关系；

另外，预测模型本身输入的自变量与因变量的关联关系也有重要的业务价值，甚至是数据化运营中新规则、新启发的重要因素；

该模型涉及技术一般有逻辑回归、决策树、神经网络、支持向量机等

3、运营群体的活跃度定义

活跃度定义一般没有定论，都是根据特定的业务场景和运营需求来量身打造的，但仍有一些基本的元素和原则存在：

1）活跃度的组成指标是业务场景中最核心的行为因素；

2）定义是否合适在于其能否有效回答业务需求的终极目标；

活跃度定义主要涉及两个技术：一个是主成分分析，另一个则是数据标准化，前者目的是把多个核心行为指标转化为一个或少数几个主成为，并最终转化为一个综合得分；后者则是因为不同指标有不同的度量尺度，只有在标准化后才有相互比较和分析的基础；

4、用户路径分析

通常来讲，在互联网企业是以漏斗分析的角色出现的，主要是分析用户在网页上流转的规律和特点，发现频繁访问路径模式，从而提炼特定用户群体的主流路径、用于网页设计的优化和改版、用户行为路径的预测、特定群体的浏览特征等；

该分析在多个部门都存在需求，包括运营、产品设计、用户体验设计等；

路径分析常用有两类，一类是有算法支持，另一类是按照步骤顺序遍历主要路径的。

如果能够将单纯的路径分析与算法及其它数据分析、挖掘技术整合，那么将会出现更广阔的应用价值，比如通过聚类划分出不同的群体，然后分析不同群体的路径特征，针对不同群体的路径分析，优化页面布局，提升转化率，减少用户流失风险；

5、交叉销售模型

交叉销售通俗来讲就是进一步挖掘客户的潜在价值，客户一旦购买商品后，企业通常有两种运营思路，一种是让客户长久地留存，延缓客户流失，这时通常使用流失预警模型；另一种是让客户消费更多的商品和服务，挖掘客户利润，这时就要使用交叉销售模型了；

该模型通过用户历史消费数据，找出明显关联的商品组合，去构建消费者购买这些关联商品组合的可能性模型，再用这模型寻找新客户中购买特定商品组合的可能性；

大家最为熟悉的应该就是关联分析，又叫购物篮分析，但也可以借鉴预测响应模型，为几种核心商品或商品组合分别建模，对潜在消费者进行精准推广；另一种思路是通过决策树的规则算法，发现基于数据资源的具体规则；

6、信息质量模型

互联网买卖双方最为直接、最关键的纽带是海量的商品，而商品的目录、商品展示的质量、结构、布局直接影响到交易是否达成。

信息质量模型主要涉及商品详情质量优化、网上店铺质量优化、网上论坛发贴质量优化、违禁信息过滤优化等；其涉及的技术包括回归算法、决策树等，不过不同于其它模型，因其没有直接的目标变量信息，目标变量的设定通常用专家打分（有时辅之以客户调研）的方式；

7、服务保障模型

服务保障模型一般是B2B平台为更好地服务于平台的卖家更构建的，主要是通过让卖家购买合适的增值产品、续费产品、卖家社区的热点分析等更好地武装卖家。

8、用户分层模型

分层模型即对买家分个三六九等，区别对待，既兼顾了精细化的需要，又不需要投入大多资源到预测模型的搭建和维护中，适用于运营初期及战略层面的分析中；

分层模型应用场景通常分以下几种：1、客户服务团队针对不同用户群体设计不同说辞和推荐服务；2、管理层需要获取买家的分层分析视图；3、运营团队需要根据分层模型来指导相应的运营方案制订；

分层模型所使用的技术既包括统计分析，又可以有预测模型，也可以运用聚类分析；

9、卖家交易模型

主要目的是为卖家服务，帮助卖家获得更多的买家反馈，促进卖家完成更多的交易；

模型包括：商品推荐模型、交易漏斗分析、买家细分、优化交易路径设计等

10、信用风险模型

包括金融行业及互联网行业的欺诈预警、纠纷预警、高危用户判断、信用评分等。

这类模型有其自身的显著特点：1、时效非常短，更新频率高；2、行骗手段随机性较强，对模型挑战较大；

11、商品推荐模型

    推荐模型包括类目推荐、标签推荐、店铺推荐等，其中尤以商品推荐最为典型。当前的主流模型为规则模型、协同过滤和基于内容的推荐模型；

其中关联规则常用的是Apriori（先验）算法，该算法首先找到数据集中的频繁项集，其频繁度要大于等于最小支持度，然后根据频繁项集产生强关联规则，该规则必须满足最小支持度和最小置信度；

如给定关联规则x—>y,即根据x推出y；

则

                    

                    

关联规则适用于交叉销售的场景，如旅行根据机票推荐酒店，情人节巧克力与鲜花捆绑销售等；

协同过滤算法分为启发式（基于用户或基于项目）和模型式两种，启发式算法包含三个步骤：收集用户信息à寻找相似的商品或用户à推荐商品；

基于用户的协同过滤首先需要计算两个用户的相似度，而后再计算该用户对某个商品的评价或喜好程度；相似度计算一般用pearson相关系数或余弦相似度，其中pearson相关系数公式如下所示：

                                   

那么该用户的评价或喜好得分公式如下：

                                       

如上式所示，协同过滤算法需要遍历所有用户，对计算量的要求非常高，一般为减少计算量，通常选择与目标用户最为相似的几个用户计算用户的评价得分；基于项目的协同过滤算法与基于用户的计算方法相似，只不过它是先算项目之间的相似度来推算用户的评分；

商品推荐模型在实际应用中往往会遇到许多问题，如如何从商品标题、类目、属性提取商品重要属性、新用户问题、长尾商品问题、稀疏性问题。在实际应用中，需要根据业务场景、充分利用各种算法优点，设计混合推荐算法，提升推荐质量。

 

数据化运营的团队定位

数据挖掘的价值、数据分析项目的价值要落实到企业具体的数据化运营实践中才可以得到检验和实现，而在运营实践中与业务团队的结合是很关键的问题。

首先，在数据化运营中，运营团队应提出合理的、有价值的、有意义的业务分析需求，即需求应经过业务团队内部的讨论、过滤，尽量避免无效、无理需求的产生。由于业务团队水平存在差异，有些来自业务方的需求甚至于是伪命题，比如未考虑是否有足够相关的数据、多种关键因素不可控、运营方式难以多元化等问题。针对业务团队的这些问题，数据团队理应在引领业务团队数据化水平成长过程中扮演“授人以渔”的角色。

运营人员看待业务的角度与深度与数据人员有明显差异，其具备更为敏锐的直觉和业务敏感，如果没有运营人员的参与贡献，单凭数据分析师埋头苦干，需要消耗太多的时间而且结果的业务可解读性也会非常差。因此运营人员提供的业务经验和参考建议往往对项目推动有事半功倍的效果。

运营效果的跟踪与反馈是项目的应用核心所在，通过运营效果跟踪一方面可对数据模型的质量进行客观的评价，另一方面也可对运营的技术、手法进行比较和判断。前者是考量模型的实践效果、稳定性；后者是在排除模型本身效果因素的前提下，考察运营因素导致的效果差异，运营效果评估常用A/B测试。

数据化运营是多团队、多专业的协同作业，绝不是仅仅一个数据团队或加上运营团队就能够很好地落实。如下表为某品牌在淘宝的双11运营活动，该活动从策划、准备到活动的执行与过程控制，包括最后的总结、反馈、挑战，涉及了企业的所有职能部门：

	阶段任务	责任方	主要成果	具体任务
双11前	总目标制定	数据分析团队，管理层	销售额=流量*客单价*转化率	流量预测
				风险防控
				店铺活动转化率预测
				客单价预测
	销售目标分解	数据分析，运营	品种、款式、数量、生产排期、库存	历史数据分析预测
	运营策划	运营	流量最大化	活动、广告等引流
			转化率最大化	位置、布局、奖券
			客单价最大化	促销措施、奖励设计
	客服准备	售前、售后	资源安排	客服匹配
			压力测试	满负荷压力测试
			针对性培训	客服一键式培训
				快捷回复
				主推产品培训
				售后环节
			预备资源	临时、兼职客服
	仓库准备	仓库、物流	仓位布局	货品与仓位布局设计
			压力测试	发货流程压力测试
			打包	打包环节落实
			物流	物流公司对接核实
双11中	执行与控制	运营、仓库、客服	抓流量	直通车、老客户引流
			产品调配与更换	页面转换调整
				产品更换调整
				超卖情况控制
			支付环节	电话、短信催付
				活动设计催付
			物流发货	打单发货进度
				物流公司收件进度
双11后	总结与调整	各参与部门	成绩
			缺憾
			后续的改进措施

上面这个表格仅是一个大体的框架，真正的运营远不止于此，但上述案例从流程协作的视角揭示了数据化运营的复杂性和专业协调性。

数据分析师常见错误观念

目前市面上关于数据挖掘的书籍多如牛毛，但绝大数是站在技术、算法的角度来阐述的，影响数据挖掘成果的因素非常多，而其中数据分析师本人对于数据分析的价值观念、态度，以及数据分析师所具备的商业意识和敏感度对数据分析成果、价值的影响远大于纯技术层面的影响。

按李笑来的说法，今天的我是过去的我积累的结果，未来的我是今天的我选择的结果，价值观决定选择，选择决定优劣和方向，优劣和方向决定各色人群和三六九等，不外乎是。

很多时候技术层面的差异所带来的分析结果差异不是非常明显，但是错误的观念和思想将造成结果的南辕北辙。

一、轻视业务；数据分析师由于本身所具备的技术门槛较高（呸！现在学个相对论也就是个把星期的事），工作时总是不自觉地带有一份优越感，因而轻视业务工作，不愿学习业务逻辑、背景、知识，甚至有些根本没有意识到自己不懂业务，最终出来的结果往往是一大堆的图表、方程式、模型而极少提到针对具体的业务需求、业务应用的对接点，纸上谈兵、华而不实。数据挖掘的本质是源于业务需求、服务于业务需求，让数据分析师主动参与业务部门会议，强制学习相关业务知识，了解业务人员思考模式，有助于分析人员将数据分析的思路、技术、方案与业务的融合。

通过虚线实线的双线管理模式和考评体系，针对数据分析师的管理和考核，分别配置实线主管和虚线主管来考核。所谓虚线主管，通常是对口业务线的业务团队主管，重点针对分析对业务运营效果提升、配合度、与团队的融合度来考核。

二、技术万能；还是同样的原因，我给这样的人取了个名字，叫“数据妖魔化”，建议看一本书叫《数据是会撒谎的》，这实质是不能客观看待数据分析的功能和数据分析的技术，对数据分析挖掘技术期望过高。

这个问题最大的危害是，不论业务人员提出什么样的数据分析需求，都会一股脑地全盘接受，根本不考虑这些分析需求的可行性。

数据不是万能主要有两个原因，一是数据本身存在缺陷或项目需求不合理；二是业务条件不配合，很多时候业务因素的欠缺或不足会严重削弱数据分析技术的作用（简单来讲，业务或运营人员能力不足或不作为，再好的模型也只能获得一个极差的结果）。

数据分析应建立分析课题评估机制，在前期的课题评估阶段引入专家评估小组，对需求本身的合理性、技术难度、数据产出物、业务因素，做出合理、客观的判断，从而决定是否可以通过数据分析、数据挖掘得到有效解决。

三、技术尖端；我称这种人叫“迹部流”（网王的，没看过的自动忽略），这种分析师（特别是年轻的）会过度地追求所谓尖端、高级的算法技术，什么神经网络、向量机、机器学习等等，以显摆自己的分析水准，没有想过从真实的需求出发，用最为合理、最有性价比的分析技术去解决。不同的分析技术需要不同的资源投入，还需要不同的资源配合，一味选择高端的算法可能会造成时间、人力、资源的过度浪费。

四、建模应用两段论；不少数据分析人员将模型或分析结果完成后直接丢给业务人员，至于业务人员如何应用却并不关心，甚至并不了解模型在业务应用中产生的问题或瓶颈，缺少主动分析、诊断并找到业务落地应用困境的原因的动力。这种问题一小部分可能是分析师自身对业务欠缺了解，更多的原因是偷懒、不负责任的心态在作怪，更深层次是企业管理层、决策层对数据化运营和挖掘应用看法比较肤浅导致。

业务落地应用的环节往往比数据分析、挖掘更为复杂，它需要多方的配合、协调，需要分析师持续跟踪、讨论、修正、建议。除了模型结果，业务人员需要了解数据建模思路、分析师的提醒、业务应用出现问题时需要分析师及时诊断、效果评估时需要分析师的合理评估。

数据分析工作的考评不是基于模型本身，而更应该基于业务落地后应用的实际效果和业务反馈。这样能够显著减少数据人员的工作脱线情况。

五、机器万能；这个病的特点是认为机器能够最大程度替代分析师的手工劳动，过分地依赖机器的“智能”,比如分析师拿一堆数据不加处理就丢进软件里，搅一搅，然后拿出份似是而非的结论。这主要是分析师对数据分析、数据挖掘的原理、数学背后的涵义理解不够透彻，基本功不够扎实。在数据挖掘项目中，80%的时间是花在熟悉数据、熟悉业务，对数据进行清洗、处理、整理、转换上的，并且由于业务场景和业务需求的多样化，很多算法其并不是通用的，选择什么分析手段，如何设置参数，需要依靠经验和实际业务理解去判断。

#######################################################################

欢迎微信交流：左码为作者微信，右码为作者公众号（博客文章会同步于公众号发布）