数据分析别急着下手，理清思路很重要！

简单就是美

业务与数据这第一个衔接点，处理好第一个衔接点，还有第二个。

互联网公司一直处于技术的前沿，技术大都不是问题。更多的可能是对技术的选择和技术人员精力的分配。

笔者以为互联网行业的数据分析需求可以大体上分为三类：

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

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

3.有主题有针对性的挖掘分析类，为运营、产品的改善提供数据依据，具有一定的数据驱动价值

对于第1类和第2类需求，不同公司有不同的方案。有用开源报表的，有用商用报表的，有用BI工具的，有自己用echart集成开发的，也有的不少坚持用excel的。对于第3类需求，有用sas的，有用spss的，有用python和R语言的，甚至有用c++的。不同的方式方法有什么差别呢？哪一类技术或工具才是最好的呢？笔者相认为没有最好的方式方法，只有适合的方式方法。如何选择适合的方式方法则更为关键。结合不同的业务场景，有时是多种工具同时使用才是最佳的。如何才能做好这一点，笔者认为就是要有清晰的分析思路和熟练的分析技能。在较低的技术要求下，选择更为灵活便捷的工具来实现数据分析。这也就是做好第二个衔接点。

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

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

笔者也该去找一下老王了，问问他是不是解决了这三大类的数据分析需求，是不是按照我的建议：先审题，再思考解题方法，最后下笔解答。额，老王会不会又懵逼了。

来源：http://www.itongji.cn/cms/article/articledetails?articleid=4999

简单就是美

数据分析要有价值，有两个衔接点：一个是业务与数据的衔接点，一个是工具与技术的衔接点。

很久之前你我都曾经做过物理题。记得那时老师经常唠叨：“先认真审题，理解题意，然后再想方法，最后再落笔去做”，“审题啊！审题啊！说过几遍怎么就是不听，寻思鹰呢？”

理解当年老师的良苦用心，历经磨难，你我也都顺利结束了学业，不必再审题、不必再做题、不必再考试。然而，人生不如意十之八九，你我又走上了数据分析的道路。我们做数据分析的目的是解决问题。换个词来说是为了有用啊。那么你做的分析，要解决什么问题呢？有用吗？怎样做的分析才有用呢？

数据分析有用的关键在于数据分析结果如何转换为实际业务调整，而实现这个转换的就是业务部门。或许我们应该按照当年物理老师教我们的思路来做数据分析更有用。

1.先审题（理解业务需求，这是数据分析方向）

2.思考解题方法（整理数据分析思路，设计数据分析方案）

3.下笔解题（选择分析技术，开始分析）。

数据分析的套路和我们当年做题一样的。当年的物理题也做过了不少，多苦多累我们都熬过去了，为什么到了数据分析这里，还是很多问题呢？笔者认为，做题是一个人的事，单打独斗，而现在做分析，变成了一个组织的事，团队作战。团队作战就涉及到分工合作问题，现在数据分析也正是合作衔接这块出了问题。

我们先看下做数据分析可能出现的失败场景：

1.分析结果就是错的

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

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

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

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

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

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

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

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

场景b：业务：“老王，感觉公司的综合转化率有点低，你给我做个分析，看看是什么问题”

向来以行动力强、技术水平高的老王，结合大量的访问数据、用户数据、订单数据，采用聚类分析算法、主成分分析法、相关行分析法等分析挖掘手段，几个通宵就拿出了漂亮的报告。报告成功的发现：年龄段在40岁以上的男性群体综合转化率超高，平均达到47%。所以建议业务部门制定拉新策略提高这一用户群体的访问量，整体的转化率就可以上来了。

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

老王再次懵逼。

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

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

老王三次懵逼。

老王他已经很努力了，但是数据分析带来的效果确不尽如人意。

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

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

我想这就是业务与数据分析之间的衔接出了问题。业务不相信数据的准确性和完整性，当数据分析结果与业务部门的设想不同时，业务部门首先就是怀疑数据；当数据分析结果和业务部门设想相同时，数据部门所做的数据分析仅仅是验证自己的观点。这样一来，数据分析完全失去了决策数据支持的作用。业务也就完全成了业务部门一个部门的事情了。

笔者调研过数据分析做的比较好的公司。A公司的数据分析主管是bi经理是产品经理出身，他既懂业务，又懂产品，还懂运营。所以他带队做的数据分析项目自然十分贴合业务需求。而B公司与A公司不同，B公司将数据化运营提升到了很高的管理层乃至战略层的高度。他们着重培养公司业务人员具有数据意识，了解数据分析的方法和思路，认同数据分析的价值，知道如何有效的利用数据分析结果。

笔者经验：要打破业务部门与数据分析部门的藩篱，做好业务与数据分析的衔接工作，可以是数据分析师向业务多走一步，也可以是业务人员向数据多走一步，使得两方面有一定的重叠，做好这个衔接，数据分析就会更有指导作用。数据分析核心目的是为业务发展提供指导和服务，业务部门和数据部门迈出的这一小步，就是公司的前进的一大步。

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

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

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

所以，对于整个数据分析体系而言，工具和技术都只是辅助，业务和分析思路才是核心。

Angela

赞一个,赞一个