数据分析师成长记

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

AIU人工智能学院：数据科学、人工智能从业者的在线大学。

数据科学（Python/R/Julia）数据分析、机器学习、深度学习

作者 | 数据海洋

来源 | haiyangxinyong

如何让你的数据处理更加专业而高效？

“数据质量是生命线”，不管是对数据从业者来说，还是针对数据应用者来说，是一样重要的，所以在SQL语言来提取数据的时候一定要保证数据的准确性。

日常的数据需求来源于各个方面，每个岗位根据自己的岗位目标与定位需要不同的数据内容与数据粒度来进行支持各种业务决策。不管这个数据需求是来源于自己要做的数据分析，还是业务部门同事或者你的老板的需求，请读者在写SQL提取数据的时候牢记“九字箴言”：

“理逻辑、写代码、看数据”！

并且按这个逻辑顺序来执行，是数据工作很好的习惯，从而保证数据的准确性。

01 理逻辑

1. 理解清楚需求

收到的业务需求要解决什么问题，谁提出来的，业务需求的描述内容是什么？往往业务需求包括我们自己作为业务人员给数据团队人员提需求的时候，总会很粗的说要提取什么数据内容。但对于需求中很重要的二个部分没有进行描述：

① 数据要解决什么问题。

② 数据具体的内容以及具体内容业务定义。

所以收到需求的时候，不管你是在业务团队还是在数据团队，先花时间去理解这个数据需求，然后对业务需求做上你理解的相关说明。如果你在理解业务需求中，有很多不明白或者觉得不够清楚就记录下来，然后统一与需求提出人员一起当面进行沟通。

例如：需要看某段时间内，会员的购买金额。这个购买金额是如何计划的，假设在一个电商中，一个用户购买商品产生订单，在进行支付时间，订单商品金额可能会有多个内容。

举个具体例子，某个订单一共有10件商品，288元，在用户支付时候：

① 该会员使用了一张优惠券满100减20

② 该会员还使用在自己的积分支付抵扣了50元

在用户收到商品的时候，该会员退货了一件商品30元。【先不考虑退货后要扣除相应的优惠券金额，所以该会员退货30元，需要扣除相应比例优惠金额，最终退还给她的要小于30元。】

在这种场景下，要统计的金额是：

A. 订单商品金额288元

B. 还是扣除退货后的258元

C. 还是扣除优惠券、积分后的218元

D. 还是上述条件都要扣除188元；

如果你对业务比较熟悉，根据业务部门的需求以及你理解的目的做出相应的建议，然后在数据结果中进行备注。但是还是需要与业务需求人进行口径明确。

作者在工作中碰到过这个案例的时候，我和业务需求沟通的时候，我给他的建议是：我把会员的订单金额，我也统计好几个衍生的字段：优惠占比、退货占比，这也是会员购物行为要关注的重要行为，你可以根据这二个比例，再对会员进行价值分层后，再根据这二个指标来分析：会员的优惠特征，以及退货特征。这样可以通过这二个占比指标，进一步细分会员。例如：占比比较高的会员，如果数量达到一定规模，从而可以进一步制定更有针对性的策略。

1. 把业务需求转化为数据需求

在写SQL代码之前应该进行二步的操作：

①明确需求的业务内容。就是要提取哪些数据指标，以及要哪些维度。然后需要把对应的数据指标与维度进行业务角度进行内容定义明确。【可以进一步思考，每个数据指标可以用来衡量业务什么内容。】

② 把明确的业务定义转化为对应要提取数据指标，根据数据指标定义明确用什么样的逻辑来统计出相应的数据指标。

02写代码

在需求逻辑理完以后。

1. 需要明确“数据原材料”在哪。梳理一下各个要提取的数据指标需要的哪些表？哪些表中的哪些字段？对相关字段要进行哪些逻辑处理。

2. 开始写SQL代码。SQL代码尽量按代码规范来进行；在不影响代码美观的情况下，尽量详细进行相关的需求内容、代码行、字段进行备注说明。

在写完代码后，养成一个习惯。花点时间去阅读一下写完的代码，像在 dbeaver的客户端中，因为对语法的相关格式会高亮，所以稍微花时间就很容易检查出错误。

如果在企业的实际工作环境中，像一般代码如果没有注意的话，例如：时间范围，表关联产生迪卡尔积等很容易导致公司的整个数据库“卡住”的，或者一段代码的数据库跑半天还没有出来，但没有及时关闭。从而严重影响了公司其它同事或者相关数据应用的效率。

这些情况，我在工作中经常发生。所以我曾经在团队做个要求，新人或者业务部门的分析师必须有一个“师傅”，当他们写比较复杂的SQL的时间，师傅们需要帮助查看一下。

关于SQL代码的错误:

1. 语法错误。语法错误SQL会执行不下去，所以这是必须要看错误在哪些地方。

2. 逻辑错误。是指SQL程序没有报错，而且顺利的执行下去了。但是可能SQL语言跑出来的结果不是你想的，也就是跑出来的数据是错误的。逻辑错误形式：

① 没有跑出数据。这种和语法错误很容易发现。例如：会员表中的ID直接与订单表中的ID关联，没有报错。但是关联不上没有数据。从而需要检查代码是哪出问题。

② 有跑出数据。这种情况往往不用心的话，很难发现。例如：在过滤条件的时候，对时间的过滤可以缺少几天，或者需要相关过滤的值没有过滤；在统计会员数的时候，没有进行去重。这些因为sql语言代码顺利执行，所以可能不会引起去足够的重视去对代码进行检查。

03看数据

在SQL没有报语法错误，跑完后有数据的情况下。千万避免数据提取后，语法不报错，就直接数据复制到EXCEL，然后发给相关的同事或者领导。这样做非常不专业：如果出现数据错误非常容易导致决定失误或者明显的数据错误或者异常会让同事或者领导怀疑你的能力与做事态度，这在职场中很要命的哦！

所以一定要检查一下，你提取的数据。对数据进行相关查看，例如：看一下各个字段的最大最小值，看一下数据的记录数，对一些数据指标进行简单的比率计算。【这些内容放在excel上，相信花个10分钟足够。】结合你自己的基本的业务常识，就可以对提取的数据是否有明显错误或者可能存在错误进行判断。

再根据明显错误的内容或者异常的数据指标，回到代码中去检查是否问题。例如：在一个提取过去某段时间每周会员数的需求中，当提取出来的数据发现有2周的会员数据明显偏高。当你检查代码没有问题，如果你对业务不熟悉可能问一下之前的老同事这个数据是否正常，也许他会告诉是正常的，去年做了活动或者去年在这个时间点有疑似被刷单的了导致会员数增长异常。

当你把这个数据发给相关同事的时候，你会把这个情况备注说明在excel或者相关文档中。

假设一下，如果你提取的数据，经过上述流程和相关的检查，在发给同事中再把相关数据指标、数据提取的范围和内容进行说明，对明显的数据异常你也做了备注说明。你同事收到这样一份数据是一个“什么样的心情呢？”。

04 总结

数据工作是一个非常非常严谨的工作习惯和态度，这样用SQL代码统计出来的数据才不会是“有质量问题”的“产品”。有质量问题的产品会导致非常严重的后果，如果你数据出现错误，从而基于数据做出的决策有可能是“灾难性”的。

例如：你统计新会员数，如果你数据没有去重，可能会导致结果说某段时间广告投入效果很好，应该持续加大。所以严格按照上述的步骤来执行，才能让你分析的数据质量好，你的部门同事或者老板会对你的“专业性”给出非常高的赞扬。

关注“AIU人工智能”公众号，回复“白皮书”获取数据分析、大数据、人工智能行业白皮书及更多精选学习资料！

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏2 回帖

不懂业务，分析就仅仅只是提数

好枪手是靠子弹喂出来的，好分析师是靠大量项目实践沉淀出来的。

作者 | 老七

来源 | 鸟哥笔记

我的数据从业历程是从咨询公司切入，那里有稍微学术点的指标体系和方法论。然后在数据服务公司应用，那里有比较成熟的数据采集实现技术。而后在微博数据创业公司将之前的知识技能进行应用和商业。回过头来看，那会的观点暂时经得起这五年时间的考验，同时也正是因为没经历过甲方公司的数据分析，所以彼时对业务的重要性感知不深，上文也就未有过多提及。

1. 不懂业务，分析就仅仅只是提数

借用下大数据的梗，“数据分析要懂业务”这句话就像“Teenage Sex”——人人都在谈论，但没谁知道究竟怎么叫懂业务，人人都觉得别人都懂，所以人人都觉得自己懂业务。请允许我老调重弹，以个人视角阐述下什么叫懂业务，不妨以别人家的产品为例——对于头条类的内容产品来说，他的业务模式无非是从(内容)生产到分发再到变现，从而实现从投入到盈利，再到盈利增长这样一个商业闭环，要想将这个模式跑通，他就得有内容（生产者），有用户（消费者），有平台（消费平台），有广告（激励生产者和平台）。

1）如果懂业务，你就不会在日活出现下行趋势时单纯提出加大广告投放这样谁都知道的建议；你就不会在生产者因竞品提升激励费用而出现流失苗头时，只是轻描淡写的报一下同环比；你就不会在关于广告的反馈量异常提升时粗暴建议业务侧全局减少广告频率….

2）如果懂业务，你就会知道数据工作该如何推进。第一阶段应该是基础数据建设，保证数据收集的规范化、全景化和扩展化，保障从打点->收集->清洗->统计->入库这个数据生产流程的效率和稳定。

第二阶段重点关注种子用户的数据表现，用户对产品哪些功能使用不顺畅，对哪些品类的内容更加有偏爱，什么样渠道的用户质量更高，并将以上结论同步输出给业务侧，并持续进行PDCA循环，直至通过留存率测算出来的life-time足够支持进入爆发期。

在爆发期的分析重点就是不断提升运转效率，比如根据用户偏好特征进行定向组织生产，继而扩大分发场景，从APP内分发再到APP外分发，不断提高单篇内容的分发效率；优化产品的栏目布局、功能按钮等动线设计，满足不同人群的使用偏好，提高“坪效、人效”；

从买用户到等用户再到涨用户，目前产品的核心用户群体是谁，在社会人口这个大盘里是否已渗透彻底，如果没有，通过什么渠道可以“捕捉”到他们，以及通过分享/转发这些策略的设计，实现用户的自增长。

在第二阶段的种种目的都是为了不断放大用户与内容的规模效应，为商业化做准备。

第三阶段的分析重点则是关注商业侧表现，内容无论是自产也好，还是UGC也罢，都是有成本的，成本换作了流量，流量又通过商业化实现了变现，所以需要通过数据优化当前的广告形式和策略，帮助金主爸爸找到最匹配的用户，以及让用户发现最需要的广告，从而实现ROI的最大化；

第四阶段则应关注创新发展，国内同行当前的发展模式都有哪些，以及各自的差异化竞争点，国外是否有类似的行业以及当下现状是如何，用户还有哪些延伸需求没有得到满足，内容行业的未来发展趋势是什么，以及可能会遇到的法律法规等政策风险。

3）如果懂业务，你就会知道在相应的阶段老板的关注点是什么，你就会设计出更符合业务视角的报表，通过相应的专题分析，解答老板还未开口的“需求”。

4）如果懂业务，你就会想到首先要了解各业务角色的KPI，对于团队协作来说，最有力的方法就是驱之以利，而非驱之以理，当业务人员知道你们是利益共同体的时候，良好的协作也就有了保障。……

说了这么多，那问题来了，如何检验自己是否懂业务，个人有个小经验，就是看你的主要时间花费和产出都在哪里？如果懂业务，你的主要产出就一定不会是提数，因为老板&业务部门知道，让你提数那就是浪费公司人效&损害自己利益。否则，分析就仅仅只能是提数。

2. 回归本质，数据才能为业务赋能

引用下百度百科的解释，“数据就是数值，他是我们通过观察、实验或计算得出的结果。数据有很多种，最简单的就是数字”数据的本质是数值，只是属于结果而已，要想改变结果，只能去寻找因，从因上做改变，才能引起数变。

这段话可能不太好理解，举一个大家都知道的流水万能公式——流水=日活*购买率*人均购买金额，这个公式还可以继续往下拆，并将拆解后的因子交给不同的业务小组负责，美名其曰---KPI。

老司机都知道，这个公式最大的意义是跟踪和监控，而不能作为执行目标，初期可能还行，但到了稳定期后，日活一旦大幅提升，购买率和人均购买金额反而出现了下降；业务做了很多优化，好不容易购买率得到了提升，购买金额反而下去了；为了人均购买金额达标，运营推荐了很多高价商品，结果购买率却又下降了…为什么？

因为流水只是个结果表现，这个结果是由用户决策产生的，决定流水的正确因子应该是用户的需求强度，购买力，以及相应购买力用户与相应价格档商品的匹配程度。如果不从因果关系上想解决办法，而只在当前的存量购买力下，追求各个伪因子，就会出现按下葫芦浮起了瓢。尤其在甲方业务环境里，各个小组都是紧密围绕在核心KPI的基本路线，如果数据侧陷入到各业务小组的KPI分析需求里而没有及时纠错，那后果将万劫不复。

再举一个例子，下图是业务里常用的数据报表视图，并随着业务的迭代和细化，出现各种报表堆砌，泼盆冷水，这种报表哪怕就是有几万份，哪怕就是进行分钟级别的异动监控，可能对业绩提升也于事无补，该跌还是跌。

我们不妨将视图变换一下：

以上表头只是示意，并没有详细展开，主要思路是将结果型报表变换成过程型报表，以用户视角将整个报表分成基本属性 、兴趣偏好 、使用特征 、商业贡献四个单元。

基本属性主要是以新增日期，渠道，机型，性别，年龄等为代表的用户基础描述。兴趣偏好是用户在使用产品之后表现出来的特性，比如喜欢卡牌、RPG等品类游戏。

使用特征则是用户在使用产品时留下的数据行为，比如浏览/点击/搜索次数。商业贡献则是衡量用户对商业化的贡献，比如购买次数，购买金额。商业贡献结合基础属性其实就是用户LTV的整个监控。

有了这种视图后，就等于有了自变量与因变量，就可以回到我们熟悉的因子，回归，判别这些多变量分析方法上来，至于RFM、CRM、渠道评估/反作弊等解决方案的产出更不在话下。

熟悉业务的好处是可以有相同的对话语境和立场，但弊端就是常常因走得太近，走得太快而忘记数据的本质，一个优秀的分析师是需要建立起一套属于自己的分析系统，其中，很重要的一个环节是自我纠错机制，这点，我也是在摸索。

3. 数据先行，增长才能更加稳准狠

伴随着人口红利消解，互联网大盘流量增长接近上限这个大背景，增长黑客（Growth Hacker）的概念现在越来越火，这里，我想说两点，1）对于什么微信裂变，社群运营，用户补贴，拼团这些来说，都是属于增长手段，手段是有有效期和环境的。他的有效往往是在透支行业平均成功率的基础之上，毕竟后来者的复制会加快人群防疫力的构建， 不仅会慢慢失效，还有可能会对自身造成伤害，在模仿手段的这个赛道里恐怕只有第一，没有第二。

电商行业有句打油诗是这么说的——“用户促活一句话：推送信息把券发，有事没事发短信。您要登陆把礼拿，优质产品在秒杀，再不来就没有啦~要是客户不买账，直接拿券头上砸”

这种生搬硬套无脑跟风做增长的后果就是成本越来越高，效果越来越差。用户的购买决策体系发生紊乱，商家的定价权也受到质疑，“价格太虚了，啥时候有优惠啥时候再来买，反正也不着急”。薅羊毛的用户越来越多，平台陷入了饮酖止渴的尴尬境地。2）增长黑客正确的姿势应当是数据先行，数据的优势是可以客观的，全局的，通过一组指标还原用户场景和动机，进而归纳演绎->找到差异->抓住增长点。再往大了说，数据增长还应包括用户定位，产品设计，价格策略等一系列全链条环节，这个后面有机会再聊。

同时增长类项目能发挥多大效能，还取决两个前提：

• 数据增长是游离在产品、运营、技术、品牌之外的一种高效组织形式，打破常规分工模式和业务惯性，需要跨部门/跨角色间的联动，这种联动越高效越好。
• 正是因为与原有分工体系游离和并存，所以不可避免会有碰撞和交融，那么对增长小组进行直接授权和负责的管理层级别越高越好。
  
  

下图是根据淘宝亲情账号的公关稿以及一组假数据结合的增长案例：

如上所说，流水=日活*购买率*购买金额，在存量购买力下，单纯提高某一个因子对总流水的提升都于事无补，但可以做的是通过数据还原用户的需求场景，继而进行场景再造，健康的将业绩目标进行稳定增长。

4. 总结

数据分析师是个孤独的圈子，孤独在没法跟同行交流和切磋，泛泛谈没有价值，说来说去就是那么几点——趋势/细分/对比/多变量，有价值的是背后各种方法的尝试以及遇到的坑，难免不涉及业务细节，也就没法展开进行描述，不得已用了很多别人家的案例，有不太清楚的地方欢迎进行具体交流。

至于数据分析的前景，无需多做宣贯，只提一点，当像充电宝，单车，咖啡，甚至汽车、大卖场这些传统行业都逐渐开始互联网化的时候，意味着互联网从轻资产走向重资产时代，你觉得企业还会不重视精细化运营么？

产品有bug我们可以及时回滚，可智能硬件的生产制造都是有成本的，一旦生产多了卖不出去就成了库存积压，生产少了用户买不到体验就不好，至于新零售的本质就更是提高人货场的周转效率，这些可都是数据问题啊。效率运营的精细化程度可能逐渐成为未来产品间的护城河。

好枪手是靠子弹喂出来的，好分析师是靠大量项目实践沉淀出来的，上图是根据资料以及自己的理解进行的归纳提炼—数据应用的三层价值模型&数据人员能力成长体系，耐得住寂寞，才能守得住繁华，在数据分析这个道路，我们一起梦想与前行。

作者 | 数据海洋

来源 | haiyangxinyong

一名数据分析师不管在什么行业，在什么类型的企业任职，把服务公司的业务流程、业务逻辑、业务与数据对应起来这是基础的基础。在这个前提下，通过我业务方的沟通与交流，你应该要了解的信息，在时间维度上，可能是未来1个月，3个月，6个月或者12个月：

• 业务背负的KPI是什么？
• 业务痛点是什么？
• 业务要解决的问题是什么？
• 业务今年的重点创新是什么？
• …….
  

了解信息后，以KPI具体数值的为例：数据分析师可以多问自己几个为什么，然后再和业务沟通你的理解，你才有可能真正理解KPI背后的逻辑与原因。业务包括：

• 了解到这些内容后，数据分析师应该有很多为什么想知道！
• 为什么公司要设定这些KPI指标 ？
• 为什么是这个数值？
  

很多数据分析师其实都不愿意或者认为去了解和理解这些内容不重要，或者感觉和自己做的事情无关。数据分析师从做的内容来说，可以分成以下几个层次，每次层次的内容和分析师所处的阶段和数据分析师资历有关系。

1

数据需求处理

所谓有数据需求，就是业务团队根据业务需要。向你提出的希望分析师能从数据库中提取的数据内容。例如：本月做了一个促销活动，想知道促销活动带来了多少新客、顾客，同时想看一下，老客户从过去某段时间内累计消费的频次分布。业务基于得到的数据进行活动总结，来分析这次活动是否达到预期。

在一些业务快速发展的企业，数据需求处理往往占据了数据分析师非常大的工作量。对于初级数据分析师来说，可能占据了他们80%左右的工作时间。

很多数据分析师发现，特别是初级数据分析师在工作一段时间后。天天都是拉数据，处理为完的数据需求；公司的大数据平台或者数据仓库建设不是那么完善，数据提取效率比较低。

有时候因为数据底层的问题，导致提取数据的时候，可能用的表不一样，导致数据取错误的数据。数据仓库底层往往表非常多，1千多张是很正常的。很多公司的数据开发/治理不是那么好，导致表的生命周期管理不是很好。经常对不常用的表可能会使用错误。

往往抱怨，数据分析师好像非常没有“技术”含量。但在我个人认为，这往往是最有“技术”含量的，数据需求往往是帮助一个数据分析师，去理解业务，理解业务痛点，和业务建立紧密关系的最重要的场景。

当我还是一个初级数据分析师的时候：

在处理前：

在收到业务数据需求的时候，我往往都会去思考，给自己提几个问题：

为什么要提这个需求？

业务中是谁真正会用这个数据？

要解决的问题是什么？

用这些数据能不能真正解决业务的问题？

在处理后：

当我给出数据需求的时候，一般我会把每个数据的口径说明清楚，对自己给出的数据做出检查。很多时候我会根据我的理解，再对这个需求提供多一些数据内容，帮助他可能要做进一步的数据分析。

对应数据需求的代码，我们做一下归档。往往很多时候，很多业务的数据需求都是会重复的或者相差不大，用写的代代码修改提取数据，速度要快很多。

在处理数据需求过程中，会和业务沟通确定一下数据口径，也一起问一下为什么会需要这个需求，如果态度比较好，一般业务同学都很愿意和你分享。通过与数据需求建立联系后，有空可以和业务一起吃吃饭，交流交流，会让你更清楚业务情况，这样你也更好的知道应该如何提供数据服务，谁需要用相关数据来干什么。“数据需求是理解业务问题与痛点，与业务伙伴建立沟通的桥梁”

经验分享：

在业务比较理解，数据比较熟悉后，我处理数据需求的时候，往往我会在理解完数据需求的基础，主动和业务做一次沟通，一般是说我们一起确定数据口径。然后对数据需求中的数据口径，时间范围作一个讨论，通过确定数据需求。也顺便了解一下业务。

很多同行会说，有时候很忙，没有时候确定。其实，如果你自己有理解清楚需求再加上沟通数据需求，对你后续数据需求处理效率，以及避免需求处理反工有很大帮助。

小观点viewpoint 如果你所有公司有非常多的各种临时需求，一方面：一般说明公司业务还在发展或者变化中，很需要数据来支持和帮助。另一方面：如果你不能很好的响应与处理需求，对你来说是个坏事，你会天天认为自己的工作就是在处理需求，天天都在写SQL代码，没有什么价值。

数据分析师在处理数据需求的同时，必然都是各种数据报表的需求。各个开发或者设计过报表开发的数据分析师，有没有思考过这些问题：

• 为什么需要数据报表？
• 数据报表定位是什么？
• 数据报表要解决谁的问题？
• 数据报表应该怎么设计？
• 如何评估一张报表的好坏？
• 如何对报表进行生命周期管理？
• ……
• 
  
  

经验分享：

一个好的数据分析师，往往都有一颗“好奇心”。往往对任何事情都会有很多为什么？对一个数据背后，数据分析师和普通人的思维可能会不一样。同样看到某个报道上，某个城市人均月收入破8千，你的感觉是什么？好奇的数据分析师可以会问以下问题：

• 这个数据是谁统计的？
• 这个数据的收入是怎么定义的？
• 数据有没有误差，有一定可信度下误差可能的范围多大？
• 收入的分布是什么？例如：1-3千，3-5千，……，100万以上
• ……
  

基于这些进一步的数据后，才能对这些数据背后的东西做判断。所以在设计报表的时候就要基于业务场景，来思考要用什么样的数据来帮助业务做出更正的判断。

2

数据报表设计

在设计报表的时候经验总结来看，可以不断问以几个问题，从而可以帮助更好的把数据报表设计好：

• 报表的使用对象是谁？使用对象分二类，一类是直接使用对象，一类是间接使用对象；例如：把报表数据导出进行个性化加工，发给部门负责人。
• 
  
• 报表解决什么问题。数据的使用对象，想用这个报表来解决什么问题。比较建议一张报表应该解决一个场景的问题。例如：用于制作
• 
  
• 报表的使用时间。一般报表什么时候用，这涉及到数据报表的数据更新时间。不同企业数据底层架构的稳定性，数据质量可能不一样。所以在明确报表使用对象基础上，报表什么时候用决定了报表数据更新。
• 报表需要的内容。就是报表具体可以取的数据指标和数据维度，以及数据报表的时间范围。
  

什么时候应该开发数据报表提供给业务团队使用。当业务提出要开发数据报表的时候，数据分析师应该有基于业务知识的基础上进行判断。正常应该在二种情况下比较适合开发数据报表：

• 业务发展稳定。当一个新业务开始的时候，并不着急开发相关的数据报表。当一个业务刚开始，更适合通过数据需求的方式去处理。因为新业务刚开始的时候经常会发生变化，可能报表刚做好业务又发生变化，同时业务逻辑不稳定，很容易造成报表中的内容指标发生变化。
• 
  
• 数据需求频率。站在业务角度来说，希望所有的需求都可以开发成报表。方便后续需要数据可以随时去取。但很多需求可能是偶尔性，或者周期性【周期比较长，例如：半月，一月】。从开发、维护成本角度来说，投入产出比不高。数据分析师可以定期手工提取或者自动邮件发送的形式来满足，并不需要做成报表。
  

经验分享：收到报表需求后，数据分析师应该先有判断。并不应该是收到数据需求后，立即就为开发数据报表做准备，多分析这个数据报表需求，从业务稳定性、数据需求频率等角度考虑。如果不开发成数据报表，可以提供其它方式满足业务。

3

小结

一个数据分析师，如果可以把数据报表设计好，数据需求处理好，对于业务来说，满足了业务基础的数据服务，为业务基于数据对业务异常的定位、监控。

当发现业务KPI数据指标不好，我们定位好问题在哪发生？接下来应该要回答的，解决怎么问题，怎么办？就需要我们开始针对具体的业务问题，和业务场景进行专项的数据分析。下一篇我们一起来探讨，如何开展一个数据分析。

如果您是以下几种情况之一：

• 1、想了解更多有关大数据分析、数据挖掘、机器学习、人工智能领域内容的好学者；
• 2、职业遭遇瓶颈，想提升自己在数据分析或人工智能领域的硬件技能的在职人士；
• 3、寻求新出路、新突破，有意向转行到数据分析行业或人工智能领域的求职人士；
• 4、对未来摇摆不定，有兴趣想Python、数据分析、人工智能方向发展的在校大学生。
  

谢谢分享！ 支持一下！

谢谢分享

如何做好一个数据分析专题并落地应用

       

                作者 | 数据海洋        

       

                来源 | haiyangxinyong        

        当一个公司的业务团队，可以比较方便准确、及时、完整的看到数据，往往都会很容易从数据的变化中看到业务问题。再通过关键业务维度的拆分，可以定位清楚业务问题发生的版块、准确衡量业务变化影响大小。

        举个例子，用户复购数是一个很核心衡量用户运营的核心指标。当这个指标出现下降的时候，可能拆分成：

       

        海洋老师小提示：

        这个拆分可能和很多公司不一样。我之前设计的一个数据分析的逻辑，和公司的运营团队尝试按这个来划分，最终希望尽可能多的把用户在一定的时间内都转为3单及以上。每个公司的实际情况可能不一样，不要照搬哦。

        我文章分享的更多是一些思路，一种思考与思维的方式与框架。我个人觉得，这可能这才是真正的帮助的。很多同学说老师，能不能具体讲个案例，我尽量通过一些案例来表达我的：思考方式、思维逻辑！

        同学们，如果你工作中有具体的问题或者案例，想要说出来一起讨论，我可能没有答案，但更多是给大家一种“我是怎么思考，怎么去分析”的思维和方法，当然刚好有一些我之前有做过或者正在做，那我们也可以一起探讨。

        01

        数据分析第一步：四个W

        当定位在哪个变化比较大或者都变化比较大的时候，很多同行总结很多，这个阶段是回答what的问题，就是发生了什么。但是我从自己的经验来说，我觉得应该还要去搞清楚：who 与Where与 when的这三个要素，即四个W。

        在实际工作中，通过分析定位到在哪个业务版块发生，在什么时间点发生，是谁在为这个变化的结果负责，在what的基础上，增加这三个内容，你的数据分析的“着力点”才有可能确定。

       

        不然就会经常同学们说的：

        “数据分析不知道如何入手？”

        “面对一堆数据不知道应该分析什么？”

        “老板叫我做个数据分析，我不知道怎么办？”

        很多时间可能没有找到这个“着力点”，第一步一定一定一定是搞清楚：在哪，什么时候，发生了什么，谁会为这个数据指标变化负责？在这特地提出二个W，一个是who 与 when:

        Who:

        有二层含义：是谁提出来这个问题？是谁会为这个问题的结果负责？例如：1单用户转化率下降，可能是部门负责人看到了或者是数据分析师看到了。提出这个问题，但他们可能不是直接为这个指标负责，部门负责人可能不是直接对这个指标负责。所以发现问题、解决问题、为结果负责可能不是同一个人。

        When:

        做数据的同学，不管哪个岗位一定要记住数据的时效性。我之前和一些业务老大们分享过：数据价值对于点的决策来说，随着时间的推迟价值会越来越低；但可能对于方向与趋势的判断需要数据的时间积累，可能是越来越大的。

        这个when是数据异常发生的时间点：

        开始的时间点，不同的场景可能粒度不一样，可能是天，可能是小时，可能是分钟。持续时间长，在开始时间后，持续多长时间。例如：1单用户留存，发现上周一到周二在下降，后面又恢复正常了。如果你本周做周总结才发现这个数据，你觉得有必要再去花大量时间与资源去分析吗？最有价值一定是当时发现后，立即采取行动。当然要快速采取行动，很大程度又要取决你公司的数据基础。

        通过数据能快速回答上述几个W，才能为后面的工作开始打上基础。最终应该是这样描述的：由A同学负责的1单留存的数据，在上周一到周二，1单用户从平常的30%下降为20%，对整体影响周留存率影响3%。周三到周天又恢复正常水平30%-33%。

       

        经验小分享：

        如果你第一步不是去思考和分析清楚这些内容，你后面基本就“迷失”在数据的海洋中、迷失在数据分析的方向中。你可能会有这样的体会：会不知道从哪个点开始着力，你会感觉这是你一个人在“战斗”，你会感觉到不知道要找谁去讨论与交流，你也不知道这个分析出来结果应该是找到哪个人或者哪几个一起讨论。

        02

        数据分析第二步：一个W（why）

        数据分析师的成长真的没有捷径，是真的需要时间去打磨你的业务知识体系，你对数据的洞察与解读能力，你的数据技术的处理能力。

        假设相关同学收到上述结果后，相信A同学的老板一定会问为什么这二天下降？很多业务同学看到数据变化的时候，往往就会开始向数据分析师提各种数据需求来寻找原因，数据分析师将会有”幸福的烦恼“，所以分析师每天都可能会收到这样对话（当然可能发生在比较成熟有一定规模的公司中）：

        “亲，帮我拉这个数据，帮我取哪个数据。”

        “最好今天给我，上午能给我不？老板急着要。”

        ”亲，好了没有啊？下午和老板开会，老板一直催着我。“

        所以同学们，你写SQL拉数据还是非常有价值。数据需求往往追求的响应效率，因为你的业务方可能老板等着他呢。“把数据需求响应好，处理好。是一个很好的与业务团队构建和谐关系的渠道，多点耐心，多点需求思考（上述的四个W），也许会帮助你更好的理解这个数据需求，理解到业务的当前的痛点：业务同学的当前的痛点可能不是解决问题，是应付老板，应付老板的老板”。

        有做数据的同学好好理解上述这些话，这可能从事数据分析师的同学，不仅仅是刚从事、已从事的同学都应该会很有帮助滴。

        “懂业务很重要，非常重要，你懂业务才能和业务有共同语言。还要懂谁在负责这个业务，然后适当的去懂“他“的痛点。在有共同语言的基础上，懂“你服务用户的痛点””。

        这个为什么回答：

        一是，通过业务同学的基于经验形成的各种业务问题的各种假设，希望用数据去证明这个假设是否成立。所以这个假设可能会很多，但他基于经验会告诉你最有可能是哪个，会有相关的优先级。

        二是数据分析师在服务业务一段时间后，在懂业务的基础上，最好能用一个数据指标分析体系构建后，快速寻找到相关指标来形成这个“为什么答案的假设”。从而让业务的这些假设沉淀在你的数据体系中。

       

        经验小总结：

        如果你觉得你想做好数据分析师，请同学们好好总结上面这段话。也请记住一点，数据分析师的成长真的没有捷径，是真的需要时间去打磨你的业务知识体系，你对数据的洞察与解读能力，你的数据技术的处理能力。

        前面提到都是我自己经验总结下来，告诉他们一些这个过程中“杭”，让大家更理解这个背后的东西，希望同学有好“心态”去做好数据分析。

        回答上述案例，假设你平时有一定的数据体系去分析与定位这个关键的KPI数据指标：

       

        “在案例中的回答可能是，发现上周一、周二来的用户有50%用户订单金额中促销占比超过60%，客单价基于都在40元以上，刚好满足新人券的门槛。”“可能是由于某个渠道存在异常用户，周三停止该渠道后复购率后续恢复正常。所以建议停止该渠道的投放。”

        03

        数据分析第三步：回答how

        如果上述二个步骤没有做好，你会直接“迷失”，找不到重点。更不用谈所谓有数据分析逻辑的。能否回答好，还是基于你本身的“业务知识与业务模式”的理解，基于你对数据指标体系构建，平时对于数据敏感性的培养。

        我们还是回到上述的案例，我认为how要回答的问题不仅仅是通过定位确定异常，定位清楚原因，可能很多时候是没有办法得到因果关系，所以大数据时候很多时候通过核心的指标对比形成相关关系。可能这也就是很多人说：大数据时代相关性大于因果关系。

        我更希望数据分析师们去回答的how，是在上述有一定基础上，去针对核心的数据指标回答的问题应该是这样，应该这样和业务和自己对话：

        “为什么月度复购留存是30%-33%，为什么不能做到35%以上！”

        “如果要达到这个指标，我应该怎么去分析与洞察数据，怎么从数据分析寻找到这个机会点？”

        “从哪些数据指标与维度，可能不断去细分，不断看各个细分机会点的趋势变化。”

        经验小提示：

        当你会提出我说的HOW的对话场景的时候，说明你可能已经是一名合格的数据分析师。当然还是要不断学习，不断从数据中去探索。也许你是解决所谓的业务增长的问题，解决是增量问题。

        我写的文章，没有太多的框架；太多的“套路”；更多是我基于自己经验的一些点或者线的总结，当然也许几篇文章写完就是一个框架，对觉得有帮助的同学可以看个二遍会有一些共鸣，希望对同学们有帮助。

        如果您是以下几种情况之一：

•                 1、想了解更多有关大数据分析、数据挖掘、机器学习、人工智能领域内容的好学者；
•                 2、职业遭遇瓶颈，想提升自己在数据分析或人工智能领域的硬件技能的在职人士；
•                 3、寻求新出路、新突破，有意向转行到数据分析行业或人工智能领域的求职人士；
•                 4、对未来摇摆不定，有兴趣想Python、数据分析、人工智能方向发展的在校大学生。
  

感谢分享~~~

如何体现数据分析师的价值？

       

                作者 | 数据海洋        

       

                来源 | haiyangxinyong        

        很多从事数据分析的同事都以为数据分析师，应该是通过数据对业务团队决策、公司管理层的决策进行“指点江山”。在实际工作内容应该是做数据分析报告；构建机器学习模型；打造数据产品，做的都是非常有“技术含量”的活。

        举个场景，业务团队要做一场促销。数据分析师理想状态应该这样：

•                 进行各种数据分析，告诉业务小伙伴，根据你的目的，你应该设计什么样的活动，投入什么样的资源，针对什么样的用户群。
•                 收集数据发现活动效果很好，一定是平时活动效果的N倍。然后继续下一次迭代。
• 
  
  

        这是很多数据分析师认为应该的工作状况，当然这也是大多数数据分析师的梦想状态，因为像很多大公司中的数据分析师的确是在实践着这个“梦想”。而不是活动前、后都只是叫数据分析师提个数据，做个报表。

        经验小提示：

        上述案例场景通过数据分析发现机会点指导业务进行精准营销，的确应该是数据分析师价值最重要体现之一，但要实现这个场景，需要企业数据文化、公司的数据质量、公司的业务规模、公司的数据团队能力……

        数据分析师价值体现

        “理想很丰满，现实很骨感！”很多数据分析师在实际从事数据分析师工作却发现，自己都只是在从事着数据需求和数据报表这二块内容。这是很多数据分析师从事“数据分析师”一段时间后都会面临的困惑，感觉自己就是一个取数工具，一个是提报表需求的人，对这个职业失去了信心。

       

        但反过来想想，如果这二个基础做不好，后续“高大上”“有技术含量”的事情也是做不好的。我个人认为：如果这二块基础做不好，可能你也没有时间深入理解业务，即便理解可能是比较粗与浅，是很难做出一份高质量的数据分析报告的。

        很多朋友写的数据分析报告，往往都在罗列数据，感觉PPT做的很多图表，很多数据，但是你问问他你这份报告的结论是什么，支持结论的数据是什么，这份数据分析报告应该针对谁？可能就……

       

        经验小分享：

        数据分析师的工作根据公司规模，公司所处阶段、数据分析师工作经验、数据分析团队的架构与定位，数据分析师工作内容会有不同的侧重点。

        在前面的一篇文章中，我放了一个下面的一张图，把数据分析师工作内容可以分成以下几块：

       

        数据分析师工作如果从“价值体现”来看，我划分成二个阶段，这个价值体现请各位同学记录，一定没有高低之分，只是公司在不同阶段和具体场景需要的数据价值去匹配，只有适应与不适应之分：

        1）看事实数据发现问题

        通过准确、及时、完整的、相对客观的数据指标与数据体系来：监控业务状况，定位业务问题点。我随时随地知道我业务进度，业务是否有异常，根据我需要的常用维度进行拆解。

        销售额，我知道KPI完成进度VS时间进度，一个维度：按品类拆分的进度；知道谁好谁坏；一个维度：按客流、客单拆分，知道是哪个因素导致；一个维度：可能按门店拆分，看哪个门店、哪个区域有问题。请牢牢见一个原则，如果你的拆分维度后的数据指标没有人为这个负责，找不到责任人那还是不用这个维度。能达到这样的数据状态企业非常非常少。真的，真的，真的。特别是传统的企业，互联网类型的可能好点。

        2）挖掘数据价值找到问题答案

        这个阶段更多是“洞察”，对数据进行深入的分析，“数据分析商业洞察”，挖掘出隐藏在数据背后的规律，从而支持各种商业决策。在实际工作中，根据具体的业务场景可能会需要不同的数据分析方法，例如：做用户的分类，可能会做一个“顾客聚类”模型，对用户流失可能会做一个用户流失预测模型。但千万记住，核心是“解决问题”，核心不是“技术含量，技术复杂度，用什么工具”。