作者:大师兄 本文为「心中有数」CDA征文作品

大家好,作为一名CDA持证人,一晃我在数据分析行业已经做了几年了。

作为一名电商行业的数据分析师,我时不时的想写一些个人的经验分享,但是又担心自己在这条路上走的还不够深入,所以一直没有下笔过。最近心态发生了一些变化,还是准备写一些东西,也当做对自己这几年的一些总结和思考。

本篇文章主要分成三个部分:

  • 数据分析师转行的进阶之路
  • 数据分析师要掌握的必备技能
  • 简单的项目经验思路分享

01个人的成长经历

初识:

我是15年大学毕业,在学校学习了统计学、Excel、SAS等学科和软件,恰巧毕业的时候大数据概念被炒的火热,学校学的东西是非常相关的,所以毕业之后进入了一家数据相关的公司,从事项目相关的岗位,并不是一名数据分析师。

认知:

刚开始工作会用excel做简单的数据处理,随着应用场景和需求的变化,发现有些数据用excel不能很快速的处理。后面在cda系统地学习了统计学知识和一些主流的分析工具:MySql、Python等,选择恰当的场景应用这些软件对我的工作效率有了很大的提升。后面因为公司业务发展,对数据分析的需求越来越多,而我刚好掌握了相关技能,就正式成为了一名数据分析师。

在CDA课程学到的数据分析的方法理论、数据指标体系、算法等技能也慢慢的使用了起来。在这家公司的沉淀,让我对数据分析有了更深入的认知。

成长:

19年加入了一家电商公司做数据分析主管,公司在天猫、京东、唯品、拼多多等线上平台以及线下都有比较好的销售业绩。但是店铺从线上线下能获取的数据是比较少的,并且电商平台自带的一些分析功能已经能满足了大部分的运营需求,所以虽然公司规模很大,但是在数据分析的应用上并不是很多。

我加入这家公司之后,经历了一段比较痛苦的时间,基本算是从零开始,这期间通过熟悉公司业务、和做数据的朋友深入交流,以及阅读很多电商相关的书籍,慢慢的对电商业务有了更深的了解,然后开始组建团队,推动相关工作的开展,主要是三个方面:

  • 一是建立数据库,整合全平台的数据(自有数据+行业数据+竞品数据爬取等);
  • 二是提升工作效率,比如通过RPA软件实现数据自动更新到数据库,然后通过BI软件进行分析展示,同时在BI测设置权限分配,保证了数据的安全性;
  • 三是扩展数据分析的深度,建立行业分析和竞品分析的指标体系和流程,分析店铺人群画像,复购分析后进行push,大促活动准备等等方面的工作,再后来直播带货兴起,也围绕各直播平台做了数据获取框架和分析流程等等。

在这家公司做分析的同时,也会做数据存储、数据安全、提升效率等事项(但因为数据维度有限,所以也只是做了皮毛),对整个数据、电商业务上下游的事项有了更深入的了解,有了较快的成长。

进阶: 

现在进入了一家电商平台,电商平台涉及的数据场景非常非常的多,日常会做各种各样的分析,比如时效(用户收货时长)对用户留存、复购的影响,提出一些时效相关的策略并验证数据的改变;也会做对平台卖家的管控,对买家的分析、供应链的分析、仓库的动销分析、仓库线路优化、平台流量分析等等,这只是其中非常小的一部分内容。

因为场景非常多,对应的对个人能力要求也很高,包括工作的效率,要在比较短的时间内快速响应需求,给出一些分析结论;还有分析的深度,要有比较清晰的分析思路,掌握常用的分析方法和算法是基本功,还需要对业务有充足的了解和认知,基于业务提出合理的建议和策略。在这家公司算是真正进入了数据分析的大门。

未来:

回想这一路的数据分析的工作经历,从一个新手到现在成长了很多,但也发现自己才刚上路,这条路很长,还需要慢慢探索...

02需要掌握的技能

因为笔者有经历过不同大小的团队(大小仅指团队规模),所以从个人角度给大家分享下不同的团队对数据分析师的技能要求

大厂的分工非常明确,所以要求数据分析师需要熟练掌握某一方面的技能,主要如下:

SQL必须熟练掌握

这是老生常谈的事情,但还是要非常重视。

大公司对SQL的要求绝对是软件上排第一位的,我现在基本每天要写五六百行SQL,忙的时候一天一两千行也是有的,所以必须对SQL非常熟练,才能很快的响应业务需求。有的人可能会说SQL不就是那点东西嘛,select、from、where、group by+having、连接、子查询等等。

从SQL语法上面确实是这样,但是大家可以想一下,在数据量比较庞大,一个表有几十G的数据(如果是有分区的表,可能就是几十TB),一个业务场景需要五六张表,数据逻辑也需要反复的连接嵌套,查询的脚本要四五百行甚至更多的的时候,就不仅仅是一个查询语法这么简单了。

首先要逻辑清晰保证正确的结果,其次要考虑性能问题,如何用计算量小的脚本替换掉占用资源的脚本,比如我之前写的一个脚本,每次执行要四个多小时(系统定时执行),有一次因为执行时间太长系统报错了,我就从底层开始一步一步优化,优化的方向主要是减少子查询,用到with as的用法,还有一些函数看起来很简单,但是特别占用计算资源,比如group by后面跟case when、分位数函数等,最后优化完的脚本只要20分钟就可以跑完,所以大家可以看一下这个前后的差距了。

计算资源是有限的,所以就要求SQL脚本必须是比较优质的,对应的就需要一些SQL非常厉害的人(一般大厂第一轮面试都是SQL)。PS:不是代码越短越好,有些短代码执行效率非常低,所以不要以代码长短作为是否优质的标准。

一些练习建议:

工作之中,或者业余时间自己练习。一定要反复的写SQL,比如用Excel能做的想想用SQL如何来实现,用python能做的想想用SQL如何实现,多动手尝试,才会提升技能熟练度。大家应该都有自己的学习路径和方式,这里就不给大家推荐资源了。

擅长某一领域的分析或者某种分析方法

你可能做过多年的人群画像,对人群拆解、人群定义非常有经验,可以快速的通过一些定义将人群划分为几个级别;或者擅长搭建指标体系。

在一个业务从0-1的过程中,可以根据业务发展现状搭建出一套可以反应业务实际运营情况的指标,给领导和运营人员做参考和复盘;再或者你对金融行业非常的熟悉,知道什么时候用什么分析方法或者算法,清晰的知道数据背后体现的业务逻辑是什么等等,综合来讲就是你是这个业务板块的资深人士或者专家。

大厂的团队都是分工明确的,团队内部每个人负责不同的方向,很少会有很多个人做一件事情(除非是比较大的经过立项的项目),所以面试官希望你可以熟悉某一板块的业务或者知道你熟练掌握的程度,这样入职后也方便你在某个业务领域有深耕。

大家也不要感觉这个很难,其实只要在日常工作中善于总结善于发现,把自己工作中做的事情总结提炼,形成自己的独到经验就可以。

如果总结不出经验,或者做的事情还非常简单不涉及到业务场景,那从现在开始,可以改变自己,可以在现有工作中深挖业务,或者换一份可以深入业务的分析工作。

需要熟练掌握一个BI软件

毕竟可视化报表是数据分析非常核心的而工作,但不同公司用的软件不同,一般公司也不会要求员工硬性掌握特定的BI软件(如果不会入职后可以现学,毕竟多数BI软件都不难),如果是特别难的比如power BI,那在招聘的时候就会有要求了。

最好能使用Python

这个是不强制要求的,除非你面试的岗位必须要通过python来实现,否则不会有硬性要求。但掌握总是好的,有时python真是神器,这个是后话了哈哈哈。

另外大厂的数据分析不需要非常精通算法,只要掌握算法的原理能用就行,因为一般不会让数据分析写算法的,有专门的算法部门,数据分析是业务和算法的桥梁,毕竟算法真的不太懂业务。


小厂的分析师比较少,领导希望每个人都是全才,主要如下:

SQL熟练

当然不需要特别熟练,因为数据量、应用场景有限,有可能写一套脚本可以复用很长时间,所以相对大厂来说要求会少很多;但是需要额外的掌握一些SQL的存储、约束等技能(可能公司没有数仓团队),比如建库建表、插入数据、主键索引等,整体上不需要多精通但相关的都要会一点,说不定什么时候就用上了。

Excel熟练

可能公司的大部分数据处理和报表都是通过Excel来做的,而且运营、市场等人员都是用的Excel,这时就需要分析师也熟练掌握这门技能了,说不定还会让你给相关部门培训Excel的使用方法。当然Excel本身也很强大, 在数据量比较小的情况下可以通过透视表、函数、图等快速的得到一些分析结论。

Python熟练

Python的数据处理能力和算法实现能力就不多说了,另外就是分析方法论和常用算法要求很多(没有专门的算法部门)。

以上是大概做了分类,实际的公司情况会有出入。

总的来讲小厂的数据分析师不仅要做分析,还可能要做数仓、算法相关的工作,有时候还甚至做一些开发的工作。比如开发个企业微信机器人,调一个API接口,搭建一个自动化系统等等。

大厂的分析师分工明确,需要在某一方向深挖,各有利弊,大家可以根据自己的情况考虑去哪种类型的企业。讲一个笑话,一个同学投了很多中小型公司,但是面试一直不通过,某一天面了个大厂很快入职了哈哈哈,所以大家不要感觉大厂很难进,只要充分准备就有机会。

03分析项目思路和流程分享

这里简单的分享一个大厂内数据分析的项目流程,希望可以让大家对数据分析有一个更真实的认知。

以下内容有点长,可以摘取重要部分分为几部分叙述:

  • 业务背景
  • 业务逻辑
  • 碰到的问题
  • 如何解决的
  • 实现后的效果等


项目背景:

公司想在平台增加运费险服务,如何合理定价。

分析思考:

大家应该都有在淘宝或者京东等平台买东西的经验,在提交订单的时候大概率会有运费险,可能是一两块钱,买了之后如果退货可以获得一定的运费赔付金额。那大家有没有发现一个人买不同的东西运费险是不一样的,或者是不同的人买一样的东西运费险也是不一样的(假设邮寄的地址都一样),那这个不同商品、不同买家之间的运费险定价是怎么来的?

如果不考虑通过运费险盈利,那么运费险定价可以简化为 运费险定价=单均取件成本*单均退货率(商品维度+用户维度),也就是平均一笔退货订单的单均快递成本 * 一笔订单的退货率,就是运费险的定价。

第一期的业务逻辑:如果一个电商平台没有运费险,现在需要增加整个服务(一般都是和保险公司直接合作),这里假设自己做,那迭代第一期,可以只考虑类目维度,不考虑商品维度和用户维度,也就是所有的用户购买一个类目的商品运费险价格都是一样的,当这个版本跑通之后,再考虑商品和用户维度。

流程如下:

和平台运营沟通,由运营选出一定数量的spu(按类目维度,每个类目选几个),针对用户进行A/B测试免费赠送运费险(退货运费全赔),就是这些商品的订单,有50%左右是没有赠送的,另外50%的订单是赠送的,经过一段时间测试后,有真实的退货产生,并且退货快递费已经赔付。

这时可以统计一些数据:有运费险的退货率和没有运费险的退货率的差异(可以发现免费退货造成退回率增长的幅度),每个类目的单均退货成本=各类目退货成本/各类目退货单量(因为每个类目的商品属性不同,就导致不同类目商品的退货成本不同),每个类目的运费险定价V1=每个类目的退货总成本/订单数(卖家发货的,排除买家没收到货就取消的订单),实际上就等于单均取件成本*单均退货率;

因为是运营选出的商品,不能代表大盘的真实情况,定价是不精准的,所以会用到第一步的两个数据,一是退货率增幅,二是单均取件成本。用这个去测算过去一段时间大盘的整体数据(假设整个大盘都是有运费险的),将真实的退货率*增幅,核算每个类目的运费险定价V2;

如果将运费险上线后,买家可以自由购买,因为购买运费险的人本身退货率就要比不买的人高,所以还要考虑这个因素,需要给第二步的定价一定的增幅(增幅比例可以由运营和领导协商确定,主要看这个项目承担亏损的能力,如果承担风险能力较强就可以给比较小的增幅),这样得到每个类目的运费险定价V3;

通过数据测算,得到了每个类目的定价,就可以考虑产品上线了,但是产品上线需要考虑几个事情:

(1)定价应该是变化的,不能是固定,如果价格固定并且定价偏低,导致亏损只能下线这个产品,所以希望定价是动态变化,根据上个周期的实际成本和退货率数据,这就需要产品接数仓,数仓每天根据之前真实的退货数据和订单数据更新最新的定价到产品接口;

(2)不能所有的商品都参加运费险,比如退货率高的spu,那怎样把这些商品排出去的,是退货率top20%还是top15%的商品,这个不能盲排,需要将过去一段时间所有商品的退货率数据取出来,然后看一下退货率分布,找到退货率的拐点,这个拐点包含大多数商品,也能将退货率较高的商品排除去;

(3)用户的排除,有的买家习惯性退货,或者是黄牛,这些也需要进行制定规则排除(比如近半年购买单量7单以上,并且退货率高于40%的不支持运费险);

(4)赔付上限,不能所有订单的退货都是全额赔付快递费,那如果用户买了跑步机退货,那平台就亏很多了,所以需要设置一个赔付的金额上限,这个上限金额也要根据过去一段时间实际的快递费的分布趋势,能保证涵盖带部分商品,但也能把一些特别高的费用派出去。

等全部内容确定后,就可以上线产品了,刚开始可以灰度测试10%的用户,不断的更新价格等到比较稳定后,再开放灰度的比例,等开通全量用户并且不亏钱的情况下开始第二期的迭代。

整体思路就是这样,但是等自己做的时候,会有各种各样的事情。比如定价动态变化,那动态变化的公式是什么,需不需要订单归因逻辑,时间窗口如何确定等。

第一期稳定后开始第二期迭代,需要根据用户和商品维度进行运费险定价,一个用户买了商品,点击了提交订单,需要制定针对这个人这个商品的运费险。那这个运费险怎么生成,是当用户提交订单时,将用户ID和商品ID传给数仓,数仓计算好价格后再呈现在订单页内,但是这种实时的方式对计算资源要求特别高,不太现实。

另外一种方法是每天提前算出每个买家每个商品的运费险价格,不管这个用户买没买,算完之后直接根据用户ID和商品ID调用,但是这样用户和商品要笛卡尔计算,计算量也是非常大不可能实现,那如何实现区别定价呢?这个问题留给大家想一想,没有标准答案。只要核心思路没问题,剩下的实际问题慢慢攻克就好啦。以上项目只是抛砖引玉,简化了很多步骤,目的是帮大家了解一个分析项目要考虑的事情....

本次的分享也就到这里了,感谢大家的观看。机会是留给有准备的人,种一棵树最好的时间是10年前,其次是现在。