我们那159915的数据，然后根据过去3年的数据，每100天作为一个图像输入，第一个作为基准输入，然后从节点200开始，每20天作为一个时间切片的起始点，来算两段图像的相似度，把距离最短的保存起来，然后用于展示，最后的图像如下图所示；

目前来看，狗绳算法效果稍微好一点；

接下来，我说另一个数据处理一定会做的事，就是归一化，常用的归一化方式可以百度
我这里用的Min-Max Normalization，也就是x∗=(x−min)/(max−min)，这样就把x归到0-1之间去了，这个算法不好的地方，就是一旦有一个极值，数据就不好看了，因为分母特别大；

其他算归一化的方式，还有zscore（x∗=(x−μ)/σ），这是认为数据符合正态分布的；这些实现numpy里面都有，然后得到了下图；


还是有点不像，所以说曲线相似也不好搞，而且股票还有一些问题，因为你不能用全部的股票集来算训练，因为很容易过拟合（想想为啥容易过拟合），我一般做到这里，然后用相似函数作为核函数用kmeans来聚类，或者直接选取几种图形来算相似度，也是解法，
发现字数够了，然后后面的事，我抽空继续写写

我很早之前就很喜欢一句话，这个世界上大部分人并没有到要比拼天赋才能成功的时候；很多时候你获得一些东西，并不是你牛逼，其实也就是你运气好，但是我为什么喜欢这句话了，因为我相信大部分人，包括我自己，还有机会；只要你做好足够的准备，只有你运气到了，一定是可以的；有些话很玄乎，一般也就是忽悠人，什么一切的必然都是偶然，或者所有的偶然都是必然；

当然这些都是废话，这一年回忆起来，有几件事，会是特别的印象深刻；

一个是单车日单量做到6.17，这个完全是一个忽悠人加强迫人的操作手法，当时运营对刷单这件事，其实内部是有两种意见的，更多的时候，反对的意见是占了上风，推动他们其实很难；这里面有两个很关键的点，一个是alyssa，alyssa菇凉是一个特别有主见有想法，且想做一件事的人，有闯劲，当时的alyssa菇娘刚刚转岗到分时，那个时间点很重要，另外一个是忽悠海杰说了一句，那么我们就本周做到5单把，当时fancy还没来，没啥人管，就拿着鸡毛做了令箭，建了一个5单群，把单车日单量到5单，变成了一个政治任务。。。。。其实很多事情也就是这样，就好像营销这件事，说到本质，其实就是补贴，补贴到位了，触达渠道、产品、活动，不要做的太差，自然就起来了，所以很快那周单车日单量就到了5单，然后就又起了新的政治目标，全周的单车日单量平均到5单，然后把之前没有进入又有些想法的立炜拉进来，BC端一联合，就刷出了当时到现在的最高单，6.17单，其实还可以刷的，补贴率才45%，但是这个时候，有些局已经瞒不了了，内部对45%的补贴率非常不满，所以之后也就那么回事，直接就开始降补贴率了；现在回头来看，这个6.17和年底的毛利做正，是一样的，都是非常重要的标志，或者是信心；所以虽然这一年结果和我预期的不一样，但是现在来看，至少这两点，对结果、对老板都是非常重要的结果；当然后面的毛利做正，我也就是打了个辅助，大部分都是运营宗炜、万老板的功劳，这也就不说了；

上面是kpi方面的，第二件事其实是抽人的事情，我这个人向来都是偏乐观，所以对别人的答复一般都是好，虽然最近也开始收一收了，哈哈，不敢给别人太乐观的结论；因为发现你一乐观，人家就直接干了；抽人这个事情分为三个阶段，前期是偏乐观的答应，毕竟是支持老板的安排，拥抱变化，能做的也就是帮助之前的同学，帮他们去拿到一个相对来说比较有利的结果，不要让他们变成牺牲品；第一个阶段其实是短暂也不算痛苦的，毕竟我觉得和人沟通也算是我的一个优势，和人交心，好处坏处一说，大家都是开心的结果；第二个阶段对我来说才是比较痛苦的，回过头来看，确实也不算是太复杂的系统，但是真的是没办法干完，一天干14个小时，每周干个6天以上，也干不完，后面有运营有产品在argue你，第一次在40人的会上argue你人少了会延期，我也就脸皮厚一点，当第二次，第三次说你延期的时候，压力突然就来了，同时违章也出了一堆的问题，而且新工单上线那个惨无人睹，当时确实是非常大的压力；当然也确实感谢黄总&辉哥&源哥&林沁&丁菁&燃佳的支持；那个时候真的不是1,2个diss你，是10个，20个人天天diss你，那一段时间对我心气的一个培养，很重要；也是那句话，人觉得痛苦的时候，才是成长最快的时候，那个时候常常一个人凌晨一点逛西湖，也就是放松一下心情，当然从涨价以后，也就不去了；人一辈子，不会是一直顺的，决定一个人能走多远的，除了天赋和努力，更多的是韧性，百折不挠才是千仞钢，那2-3个月对我来说，韧性的提升才是对我最大的提升；

然后是第三点了，这一年我对自己最大的改变，其实是把目标集中了，以前我会同时看很多个事情，都是大事情，最后的结果其实是每一件看起来都算不坏，但是也仅仅是不坏，这一年我聚成一件事，从目前来看，虽然也还是不坏这个评价，但是这一年我确实学到了很多东西，主要是这一年和运营不仅仅是点头做个朋友，而是更加实实在在的去做事情，去看这个事情真正的问题是什么，这个流程是很重要的，同理心、细心、耐心都算是提升；我这个人的兴趣其实很广，从玩游戏，看小说，看动漫，体育运动，旅游，逛吧，刷抖音，这是优势也是弱势，聚焦才能获得收益。。发散只能忽悠小姑娘；未来我会尽量聚焦，这是一个趋势，也是个提升；发散是为了消遣，聚焦才是为了结果；

整体来说，18年还是不错的，认识了很多的人，结成了还不错的关系，19年，希望自己能够有更多的提升，留在另一个文章里说吧；

http://www.lfd.uci.edu/~gohlke/pythonlibs/

2、命令行安装

在cmd中，转到whl文件所在目录，输入如下命令：

pip install whl文件名

安装成功，到这里已经可以用了

3、检查

查看python安装目录下的site-packages目录中，是否存在tablib文件夹

4、测试

使用环境为eclipse python

直接import不报错

5、附下载python的TA-lib压缩包，网址为：

http://mrjbq7.github.io/ta-lib/func

一、背景

我们是从16年下半年开始做租车的，刚开始做的时候觉得比较简单，因为滴滴是一家非常强运营的公司，而且当时滴滴的用户已经很多了，那我们那时想，既有流量，又有运营方式，那么租车的快速成长是显而易见的事情，但是在实际做的时候，我们发现并不是这样，专车和快车的用户人群，都是短途出行的人群，他们的特征是短频快，而租车是一项较长期决策的过程，两者的用户既有重叠，也有不相关，所以当时如何利用滴滴自身的资源去快速的把租车的用户找到(流量获取)并且引导他们下单（提升转化）就成了当时我们最重要的两个问题；

二、流量获取

首先讲流量获取，流量获取是所有app最头疼的事情，其实我们还占了一个比较大的优势，因为我们已经有了一个成熟的app，所以不用费多少劲就有不少的流量进来，这点是优势，但是对所有的app来说，流量是永远觉得少的，今天主要讲的是，如何通过和滴滴的数据结合找到我们的精准用户并引导他们进来；

当时我们主要考虑的点是两个，一点是找到用户租车的场景，在什么时间、什么地点、什么人会有一个租车的需求，另外一点是我们怎么利用滴滴的数据去找到这些人、时间和地点；第一个想到的场景是旅游，因为我有小孩，所以自己在旅游的时候，确实是需要租一个车的，这样小孩很多东西都会比较方便；当时的第一个目标就是怎么找到这些人，旅游嘛，第一个自然是订机票或者火车票，所以，最好的嵌入场景是在买机票或者火车票的时候，下面放一个租车的按钮；但是我们没有呀，我甚至当时想要不要做个滴滴卖机票，反正滴滴也没有，滴滴作为一站式出行平台，应该解决所有的出行问题嘛。。后面从成本的考虑，我们退而求其次了，滴滴有用户的出行数据，所以我们当时根据用户出行的行为，来寻找潜在的目标用户，主要有三种：在机场和火车站画个电子围栏，如果打车出现在这附近，那会给他做一个旅行的标签；针对异地打车的用户，和他们的常驻城市做一个对比，给他们打上另外一个旅行的标签；我们会根据用户的历史的行为，比如性别、年龄、出现在机场次数、过去3个月去过多少城市、专快的订单比例等等，用lr或者决策树去做个预测分类，判断该用户是否是旅游人士，打上第三个标签；其中前两个会更重时效性，对这些用户，会发券以及给出若干优惠活动，刺激他们来租我们的车；当然针对亲子游的用户，还会加上安全座椅的活动；这个在旅游城市，比如成都和青岛，效果都还不错；

另外一个旅游场景是周边游，这个也是很大的一部分用户群体，这个的做法主要是标注了一些旅游景点，然后根据用户去景点的次数，旅游人士的概率，来判断用户是否是一个周边游的用户，然后结合景点门票优惠和用户的消费能力，定期对相关用户做一些推送，这个是搭配旅游一起做的，效果一般吧，还有很多可以研究的地方；

有些场景是可以直接通过规则找到的，而另外一些场景可能是需要模型来做的，比如我们在推送的时候会遇到最大的一个问题，我们的用户并不一定会打开滴滴app，而且还会把通知关掉，这样就会有很多的推送是无效的推送，因为发过去，我们的用户看不到，而公司对每个产品线的推送数量又是有所限制的，所以我们根据用户历史打开app的行为，去做了一个预测用户是否今天会打开app的操作，这个东西很简单，但是却极大的提升了触达率；

刚开始的时候，我们其实就是这样一个一个按场景去找的，把场景找到了，做推送，分析效果，猜测原因，继续优化，在这个基础上我们还引入了一些模型，通过模型我们把用户历史的一些打车行为加进来，比如消费能力、打车地点、是否商旅人士等等，通过lr或者svm来训练模型，用来排序，深度学习也在研究中，预计今年也会把这个加到算法中，对每一个场景可能会有个标签，加上滴滴本身的用户画像，就成了一个标签系统，每天大概会有上百个这样的特征人群吧，然后通过运营平台，对用户进行推送；其中一部分推送用户是未验证效果的，通过做abtest来判断效果，另外一部分是验证后效果比较好的，就扔到一个自动推送平台去整体把控；

这个自动推送平台主要是两个功能，一个是因为公司限制，比如整体发送数量限制、同一用户不能发送多次，做一个对所有发送的统筹功能，另外一个就是对发送的内容和时间做管理的MIS系统；当然还有动态调控，根据标签的推送效果，来设置每个标签推送的数量，目标是保证整体的效果最优；这个效果还是比较明显的，推送的成本大概下降了90%以上，但是触达率反而有所增加；

中间还做了很多模型分析的工作，其中一个是希望把多个场景的特征做整理，从整体做一个模型去优化效果，这个我们做了很久，也试过不少方法，但是效果并不如单个场景的好，所以并没有一个整体的模型去一劳永逸的解决所以问题；而是将模型和场景的特征做了一些结合，这些结合的目标主要是因为我们推送的资源有限，需要在单个标签内部做一些排序，刚开始也是通过规则来做的，比如消费能力、时效性，后面加入了模型的方法，来保证整体最优；

三、提升转化

提升端内转化，是另外一个非常重要的问题，但是这个其实也挺难的，怎么改，怎么算改的好，对一个新产品来说，都是不太好解决的问题；之前我经历的一些新项目，大部分都是根据拍脑袋，然后事后验证，这样的结果有好的也有坏的，好处是决策快，坏处就是并不可控；

我们的做法是在一开始做租车的时候，就做了一个详尽的数据跟踪和监控系统，对C端的所有的操作加上埋点，并且做了非常好的数据可视化；通过这些可视化，我们既可以看到整体的转化效果，每个页面的拦截率，每个按钮的点击率，也能看到某群人的转化效果，比如家庭游用户的转化、行为路径等，还能看到每个人的历史操作，事实证明这个系统对之后产品的优化影响非常明显；

通过这些，我们既可以对一些宏观的问题，很快的找到问题的关键，然后做适当的处理；比如上线不久，我们就发现在列表页到详情页的漏斗，拦截了90%以上的人，然后我们看了一下，全部是中间的某个风控操作拦截的；我们分析了一下，因为风控需要扫描身份证，但是对很多人来说，身份证并不一定在身边，所以很多人就直接走了；但是扫描身份证是不是必须的了？我们和风控的同学讨论了一下，发现并不是，就把这个改成了手输身份证号码，一下子降低了一半的拦截率，效果还不错；

再举个例子，我们在做用户分析的时候，发现有很多用户的行为很简单，要么访问首页，要么访问一下列表页，然后就直接退走了，有的用户甚至一天有几百次的这种行为，这个在整体看数据的时候，是很难看出来的，但是在数据分析的时候，却是很大的噪声，我们猜测这些是机器的行为，因为大部分属性都类似，所以做了一些统计，并根据统计结果做了一些过滤，事实也证明过滤后的数据更能看出用户的行为；

还有对新上线版本的评估，用户研究对产品的调研，运营标签的生成（如什么时间点是下单高峰），用户行为跟踪都是可以通过这个系统来完成的，事实也证明，效果还可以；

四、展望

我们过去一年做了一些事情，比如标签系统、运营平台、自动化推送平台、数据监控系统，有一些效果还是不错的；接下来还有更多的事情，比如讲深度学习运用到寻找用户，设计用户做自传播的活动框架，我们还会继续努力，有机会再和大家沟通；

最近在做驾照的重构，引入新的驾照翻译方；从背景来说，这是件很有意义的事情，因为从之前收到的调研来看，驾照问题是影响用户最重要的几个因素之一，而我们之前的驾照翻译只有单纯的字面翻译，调用的是开源的库；这会遇到两个问题，第一是翻译的质量问题，直译会有很多翻译的不好的地方，比较难理解；另外一个方面，在很多场景下，这种直译的翻译件并不能起到驾照的凭证，应用场景比较狭窄；所以在现状的基础上，我们引入了新的翻译方，这个是可以通过国际认证的，所以可以应用于更多的场景；

本文介绍两部分，第一部分为老系统的架构，第二部分是新系统的架构；

         原来的逻辑由一个页面构成：从首页进去后，填完所有的信息；点提交后，会将数据先入数据库；再通过第三方lib对数据进行翻译；翻译完成后，将数据入库；同时生产pdf文件，并将图片信息发送给用户；

过程还是比较多的，主要是2个数据库操作，1个翻译，1个生成图片，1个发送邮件，会涉及多个外部lib

新版的增加了多个页面，大概8,9个页面，后端增加了10几个接口，主要分类为：

1.      订单list：2个，查询，最近一个详情查询

2.      订单类：2个，查询，修改，

3.      订单类地址：2个，增加，修改，只修改订单绑定的地址id

4.      地址类：4个，地址的增删改查

5.      线下，回调数据

修改了一下，将订单的地址抽象出来，变成订单的一部分，然后对原有的重复接口进行合并，就只有7个接口了：

1.      订单类(增加个订单绑定的地址id，默认-1)：3个，list查询，查询（如果没有订单id，则返回最新的一个订单），修改

2.      地址类：4个，地址的增删改查

3.      线下，回调数据

其实还有个更老的版本，有13个接口，梳理一遍，只有7个接口，看起来这个事就是个很简单的事情了；

写到这里，但实际在想，7个还是很蛋疼呀，是不是可以搞一个自动生成的脚本，自动生成api查询的框架，我一个都不用写；再扩展一点，我们的mis系统，是不是基本上都是数据库的增删改查，是不是通过这样一个框架的落地，前后端都可以通过配置完成，可以解决80%的mis问题；回到海外租车，我们的竞品租租车已经成立6年了，线下的我们不说，线上的我们如何通过5-6个人的小组花半年的时间去干1-2百人的花了5年干的事情，那这个新的框架就更有意义了；

所以稍微想了想框架的雏形，留待后用，就不画图了：

1.      后端的表是要提前提供的，这个需要预先准备；

2.      前端提供的是框架+模板，将通用的页面通过模板的方式固化下来，变成可配置的

3.      后端提供的是框架+api接口，将数据库的增删改查抽象成api接口出来，并对接口做业务上的控制；

总结起来无非就是一个自动生成api以及自动生成页面模板的功能，介绍一下2和3部分；

第二部分的核心是交互，如何有效降低门槛，让大部分的界面和接口配置变得非常容易，是这部分的关键，事情上分为3小块：

1.      抽象常用的业务模板，这个很简单；

2.      搭建前端框架，主要解决，a.引入模板，b.模板部署和上线，c.模板和后端api的交互配置(每个模板有多个接口，每个接口对应一个api接口)

3.      搭建后端Api配置，api主要配输入、输出和sql，这个和常用的框架差不多；

第三部分是后端的架构，主要是保证稳定性和各服务的独立性，一期为了简单些，这个都可以不用考虑独立性的问题

1.      定期从数据库读取各模块配置，并将配置变成本地缓存；

2.      根据api接口的参数，选择对应的api配置，并进行处理参数（过滤，判断是否合法等通用处理），调用sql，返回数据包

很简单有没有，这个搞完之后，大部分的增删改查的简单逻辑就可以通过配置来解决，项目的瓶颈就只在于一些静态页面和一些逻辑比较复杂的业务模块（如排人排车，这一类的比较少），而这些都可以通过堆人力去解决的，因此整个项目的开发速度会大大加快；

说一下优点：

1.      开发人员不用去配环境，新同学上手快；

2.      新增接口QA测试的点非常少，且bug会大大减少（因为大部分的功能框架都做了）

3.      整个开发流程增快很多，PM出完后，就能很快在线上看到，QA环节也时间减少

4.      不用上线

整体总结下来，就是减人力，开发快，且出bug少。。。

缺点：

1.      只能做简单业务处理，这个算优缺点并存吧，不过我们大部分的场景都是简单业务处理

2.      多个接口在一起，如果项目代码开发不好，会影响多个业务；

整体总结下来，就是因为只能处理通用问题，所以肯定不能覆盖所有，且如果推广多，会变成比较重要的业务，影响面大；

不过现在这个阶段，看到的业务和技术瓶颈还是比较明显的，技术瓶颈通过这个应该可以解决不少问题，但是还是不能花主要人力去做这个，因为主业务压力就很大了，所以其实项目的前期瓶颈还是在人身上；