简历项目深挖

Nike

项目背景 

1.    该项目耐克作为全球的核心长期发展策略的O2O数字转型项目（关联合作伙伴项目：CP）。发展期望：制定线上线下相互引流策略，在保持 原有客户架构的基础上，与多方团队及经销商合作达成新的数字化运营模式

 大目标： 

1.将更多的消费者纳入耐克自己的会员系统：从而来记录消费者的购买等行为为未来做用户分析打下更好的基础，也可以多一些裂变的玩法。这是我们从线下到线上引流的主要目标：就是让更多的消费者加入自己的生态中。 2. 增加总营收：根据当时全球的市场调研，会员用户会比非会员高出30%，并且会在更多的平台上进行消费。所以对于线下我们也会在经销商店铺中通过改变陈列等方式可以达到和直营店一样的体验，并且会有线上的流量比如一些活动和功能引入线下。最终实现全平台的营收提升。  

项目细分Breakdown：

我负责的部分主要是设计，维护并监控线上多平台渠道的功能使用数据，以及落实到线下以后的营收，会员，产品信息与库存，功能使用度等一些核心指标。

1. 说对于线上功能部分，我们有自己的app，有微信小程序以及官网。我们会有一些基于地理围栏或者活动的推送刺激消费者去线下购买，也会有线上平台查询实时的线下店库存信息，也会有一些店内使用的功能比如扫描二维码查询产品信息如库存，扫描之后会在线下试穿，最终在线下或线上进行购买。所以对于这些线上功能我们会考察整个漏斗的表现和转化率，并作出归因分析和提出解决方案。  

2. 对于线下部分我们则主要关注业绩营收相关。 

会员很重要-》

会员 非会员 Member and non-member:    

 Member revenue, member transaction, member checkout rate     Member aov（单价）, member upt（购买件数）     Member without member product check out%/REV%     Member product revenue, member product transaction+%, average selling days  所有的都按客户，地区，concept拆分，store, 来进行对比 

 除此之外就是围绕其开展的一些支持或统筹，比如线下赠品活动的对比和统筹安排，进行总量的计划，并且我们也把这方面的库存整合进了数据的监控看板中。或者经费的预估，主持个团队的沟通会议。

Amazon

项目背景：

我们大部门主要负责支持欧美业务和部分的一些跨境电商的一些合规性分析，身边别的小伙伴主要是给不同种的商品加上分类的标签，并进行合规性的检查。加入团队的时候正处于海外疫情刚开始的时候，亚马逊开始在家办公，海外用户的消费行为和需求都发生很大的改变，并且分销商供货和商家商品方面也发生了一些变化。总的来说在工作量和工作效率方面有相应的波动。所以我们希望搭建一套衡量工作量和工作效率的指标体系，从而追踪数据的波动并做出相应的预测，来优化人员结构和工作量的分配。

项目细分Breakdown：

我做的其中一部分工作就是数据处理方面。一部分数据是来自于redshift中的用户反馈评论投诉记录及员工解决这些案例的时间，每个商品被进行分类的记录。对于这些存储在数据仓库中的数据，会用sql进行清理和业务指标的计算。另一部分数据来自于各个团队定期维护的手工报表，我主要是用python进行表的标准化等处理，最终统一为业务逻辑一致的一维表。我们采用的业务指标大概有首先代表工作量的进入业务量和产出量，表示工作质量的例如达成率，dpmo（defects per million opportunities), 表示工作效率的一天完成多少case(8h), 单位小时中完成的case,tp90(完成90%的case)所用的时间。

SPC report

“统计制程控制” SPC或称统计过程控制。SPC主要是指应用统计分析技术对生产过程进行实时监控，科学的区分出生产过程中产品质量的随机波动与异常波动，从而对生产过程的异常趋势提出预警，以便生产管理人员及时采取措施，消除异常，恢复过程的稳定，从而达到提高和控制质量的目的

我这边主要是建立维护tableau上的看板，表现各项指标的波动和各个部门之间的差异性。

除此之外还涉及到了一些分析上的探索，比如通过一些界限和人为干涉添上的关于部门或小组的标签，借助统计模型或者机器学习模型进行标签的预测，从而基于3sigma的预警系统能有所提高。还有一些类似于多种指标的人员效率综合评分，但这个是基于员工的比较敏感，并且其实我们在评估活动的时候也知道，太多的指标混为一潭很容易造成问题，所以我离开的时候是没有实际落地。

主指标越高越好，副指标作为下限

mapreduce 

优化问题

1. 对大表和小表进行join时，可以用mapjoin将小表加载到内存中，让大表去内存里循环读取小表

2. 大表和小表join时，可以将大表先转成小表

数据倾斜

Map:将数据转化成<key,value>对，reduce会将具有相同key的数据进行合并计算

因此，假如有大量的key数据集中在同一个reduce任务中，就会有数据倾斜的问题

解决办法1. 当groupby分组时，某些key占比特别大，可以设置map的输出任务随机分布到reduce中，在将相同key的数据重新聚合

2. 执行count(*)时可以设置map任务数量的上限

3. join产生大量空值时，可以在join中用where忽略控制，再用union加上

4.用sum groupby 来替代count（distinct）

ctr

曝光特征：统计所有ID类特征在8天内的曝光次数（即count特征）

交叉特征：统计用户ID与所有广告侧ID、广告ID与所有用户侧ID的类别交叉，如某个用户ID曝光过多少不同的广告ID（即nunique特征）

CTR特征：统计所有ID类特征前所有天的历史点击率

embedding特征：构建广告曝光序列，训练word2vector得到广告表征，平均广告表征得到用户表征