直接将分析结果利用，转换为价值的，是业务。或许按照这样的路线来做分析，更有用。

1、先审题（理解业务，做为方向）

2、思考方法（分析思路，设计分析方案）

3、下笔（选择分析技术，开始分析）。    

可见，套路是和我们当年做题一样的吧，可是，当年的物理题也做过了不少，多苦多累我们都熬过去了，为什么到了数据分析这里，还是很多问题呢？私以为，做题是一个人的事，而现在做分析，变成了一个组织的事，衔接出了问题。

做数据分析可能出现的失败场景：

l   分析结果就是错的

l   分析结果是对的，然而并没有什么卵用，结果产生不了价值

l   根据分析结果，可以给出建议方向，但是很空洞，无法落地

l   分析结果对、建议方向也对、也有落地的方案，但是业务就是不执行        

第一种场景比较少见、而后面的几种场景却是做数据分析的经常会碰到。举个栗子。

场景a：

公司在6月18号跟着京东一起搞了个618大促，结束后业务找到老王，说：“老王啊，我们活动做完了，给我做个分析，让我看看活动效果怎么样？”    

老王接到任务开始收集数据、处理数据、做模型、画报表。最终出来结论：“我们本次活动期间，环比上周末uv增长了150%，综合转化率提高了27%，订单量增长了110%，销售额增长了85%。其中江苏省订单占比最高，达到了27%。。。。”              

业务：“你要说明什么，是想告诉我活动真好，明年还搞618大促吗？”        

此时，老王只能期待他一脸懵逼的表情来萌翻业务了。

场景b：业务：“老王，感觉公司的综合转化率有点低，你给我做个分析，看看是什么问题”向来以行动力强，技术水平高的老王，结合大量的访问数据、用户数据、订单数据，采用聚类分析算法、主成分分析、相关行分析等挖掘手段。成功的发现，年龄段在40岁以上的男性群体，综合转化率超高，平均达到47%，所以建议业务，制定拉新策略，提高这一用户群体的访问量。整体的转化率就可以上来了。        

业务：“但是这群人，平时很少上网啊”。        

老王再次懵逼。

场景c：

老王：“我做了一个用户流失预警模型，发现有a类行为特征用户在注册后30天左右流失概率最大，有b类行为特征的用户在40天左右流失概率最大，有c类行为特征的用户在50天左右流失概率最大，那么我们只需要做一个精准的关怀，针对不同行为特征的用户，在不同的时间点，推送广告、或者发放优惠券，就能够有效的降低流失率”。        

业务：“老王，你说的很对，但是我们公司小，实现这样的精准投放成本太高了，我们现在每天忙成狗，核心的内容体验还没做好，你的建议后面再考虑吧，辛苦了。。。”

老王他已经很努力了，但是分析结果确不尽如人意。    

我们常常见到数据分析师抱怨：我的工作不够重视，他们要数据的时候就让我提取一下，最多做个简单的加工；业务做决策都不看数据，全凭经验来；业务开会，讨论方案从来不叫上我，不参考我们的意见。    

同时，也能听到业务方的抱怨：数据部门提供的结果，都不是我想要的；数据部门太天真，提供的方案太多漏洞；数据部门的人都不懂业务，拿着点数据就能来指导我们吗；        

我想，这里就是业务与分析之间的衔接出了问题。业务不相信数据，当一个分析结果与他的设想不同时，首先就是怀疑数据，他所做的分析，仅仅是为了验证自己的观点。      

见过数据分析做的比较好的公司，一个是bi经理是产品经理出身，懂业务、懂产品、懂运营，所以他带队做的分析项目自然贴合业务需求。还有一个是公司将数据化运营提升到了很高的高度，培养公司业务具有数据意识，了解数据分析的思路，认同数据分析的价值，知道如何利用分析结果。        

可以是数据分析师向业务多走一步，也可以是业务人员向数据多走一步，使得两方面有一定的重叠，做好这个衔接，数据分析可能就会更有用。嗯，你们迈出的这一小步，就是你们公司的一大步。    

一方面，培养全公司业务的数据意识，是需要时间并且有难度的。另一方面，作为一个数据分析师，也应该更多的了解业务，这样才能把“业务的需求”转化为数据需求，再进一步把分析结果转化为有意义、可落地、可产生价值的方案。同时也能反过来完善自己的知识体系，提升自身的业务理解能力和数据分析能力。        

问题来了，怎样去了解业务呢，只能说，世上无捷径，除非你改行。能想到的方法，就是交流交流再交流，当业务需要分析一个活动效果的时候，多问一句，你关心哪些指标？哪些参数会影响一个活动的成效？当业务要分析转化率的时候，多问一句，影响转化率的因素有哪些，有哪些方法可以提高转化率。都是一个公司的，没事请业务吃顿饭，没有什么是一顿饭解决不了的，如果有，那就两顿，吃着吃着，不仅你懂了业务，业务也懂你了。    

交流，听起来很简单，做起来是最难的，尤其大部分数据分析师都是数学、统计学、计算机等这种理工科出身。会有人期待一个更简单的方法。例如：数据部门只做技术，分析全都交给业务部门如何，我们买bi工具，让业务实现自主分析。你说用bi来节省工作量降低时间成本我信，你给bi这么艰巨的任务，且不说bi工具的分析能力有限，无法实现深度分析和挖掘，业务部门的数据意识上去了吗？没有统筹，各个业务部门的分析结果相互冲突怎么办呢？业务部门的分析结果不客观，对于公司来说，是最好的吗？        

所以，对于一整个数据分析体系而言，工具和技术只是辅助，业务和思路才是核心和重点。谈到技术，再进入到第二个衔接点。        

互联网公司一直处于技术的前沿，技术可能都不是问题（如果跟一个互联网公司说你技术不行，就希望他们公司程序员加班太多打人的力气都变小了吧），更多的可能是对技术的选择。私以为互联网行业的数据分析需求可以大体上分为三类：

1、业务常规需求，主要是辅助业务日常工作用

2、指标监控与数据呈现类，为管理和决策提供支持，也为后面的针对性的挖掘分析提供入口

3、有主题有针对性的挖掘分析，为运营、产品的改善提供数据依据，具有一定的驱动价值对于第1类和第2类需求，有用开源报表的、有用商用报表的、有用bi的、有写echart的也有用excel的。对于第三类需求，有用sas的、spss、python的、r的甚至有用c++的。

要说哪一类技术或工具才是最好的呢，我相信没有，如何选择，更多的是要结合业务场景，有时是多种工具同时使用，才是最佳的。如何才能做好这一点，我想就是要有清晰的分析思路，和熟练的分析技能（对各种工具的了解）。也就是打通第二个衔接点。    

对于很多分析师来说，这一点要比第一个衔接点容易的多。但是我再多说一点的是，分析手段的选择，不仅要考虑分析实现的可行性，也要考虑分析成本，主要的就是时间成本。R语言现在大量应用于互联网公司，我想也是因为它提供大量的统计函数和算法，降低了数据分析成本的原因，当然，少不了它开源的巨大优势。    

同样，对于第1类和第2类需求，选择实现方案，也要考虑成本。相比较来说，这两类需求的实现难度更低，相信对于任何公司来说，也都是并非核心技术。有坚持用excel的，也有坚持码代码的。当然，具体怎样选择也要结合业务场景，但是综合起来看，如果有方法一天就实现，就尽量不要花两天时间去开发。比如有些场景你如果机智舍去excel，用finereport，甚至相比于开源report或者echart来说，还是节约一定时间成本的，省下的程序员，还能打扫打扫卫生啊。        

以上是我对互联网行业中数据分析业务的一些浅薄的看法，如有不当的地方，欢迎批评指正和交流。