前几天听人说了hubspot这个项目，今天写文章，正好乘着这个机会去了解了一下；


首先简单介绍一下hubspot这个项目，hubspot成立于2006年，14年10月在纽交所上市，之后2.5年的时间，营收从1.2亿美金增长到2.7亿美金，他做的主要事情是营销自动化，面向的对象是to B；


营销自动化是指通过营销软件，将邮件、社交媒体和网页上的多次重复操作转为自动化完成，提升客户营销的效率和精准度。


上面是网上搜到的解释，然后hubspot实际上做的是将整体流程分为4块：


1. 引流
2. 转化
3. 成交
4. 口碑营销


然后分开处理，整体打包，这四块差不多类比于现在的C端拉新，端内C端漏斗，leads跟踪对应的CRM系统，后服务等等；hubspot将这整体的系统流程化和标准化了，我觉得挺好的；这个系统对当前的车商城，基本上是量身匹配的，而且因为to B的业务大部分都有一个线下成交的过程，所以整个系统和一般的to C 的营销还不一致；


简单放了一个图，可以看到各部分分别作了些什么；


第一块就是现在的拉新，可以按渠道分为微信、SEO&SEM、媒体工具等等；如果按另外的维度分，可以有内容营销、活动营销、用户运营等等，按工具来分，可以有活动制作工具、网站打分、移动页面优化、用户生命周期等等，根据分法的不通，这些子类目都可以做成不同的系统出来；


第二块转化指的是端内的优化，数据获取，落地页优化，基于场景的营销等等；


第三块指的是在线上下单之后，用户需要去线下去完成订单，但是这个过程中，用户流失特别明显；这里面有一个CRM系统，还会有leads跟踪，用户评分，销售提醒等等，除此之外可能会有邮件优化，短信优化等等


第四块是在于我们完成订单后，需要对用户进行持续的跟踪，类似于现在NPS，当然我们还可以做其他的事情来提升口碑，比如用户反馈，微信拉群等等；


其实回过头来，这四个点我们大部分的系统都有，对大部分to C，第三块内容是没有的，更关注的是1，2，4，这样看来，作为一家15亿美金的公司，貌似也米有做多少东西嘛；而且国内貌似也米有成功做好的公司，这肯定有原因的；另外to B的工具往往都是收费的，不收费别人反而不敢用，这样看来，今年揉吧揉吧，明年可以整一套系统拿出去卖了；


最后从to C的角度来看，我们第三点暂时不用做，第二点主要是提供数据支持，这样来看，自动化埋点还是需要的，对于拉新来说，常用的拉新工具，我觉得自动做活动页，微信端数据营销，裂变营销都是比较重要的部分，而且现在第四点也做得不好，如何让用户觉得我们产品好，及时给一些反馈，也是个很重要的东西，这里也是可以去整一个方法论的；


大体就是这样，对营销来说，这里面是有很深的学问的，今年的一个主要的方向，也是如何抽象出营销，使之变成一个可以迁移的高效系统；

本周的比赛内容是客服系统设计，所以这次文章我们就写一下这个系统；

这个系统简单理解了一下，大概分为3个部分：
1. 线下的mis管理：主要涉及问题的输入和答案的编写
2. 线上的展示，主要涉及问题按分类进行输出，已经点赞等功能的支持
3. 自动答复功能
第一部分:faq的后端mis管理，主要是由两个表组成，主要是分类和问题编写，分类是多级的，主要考虑到之后可能会用在多个业务线，以及问题会属于不同的类目，方便进行筛选；

第二部分:faq的前端展示，主要是模板的编写，页面根据mis管理功能进行展示，然后以及一个点赞功能；

前两部分基本上都是一些数据表的增删改查，我就不在这里细说了，主要说第三部分的事情；

第三部分是自动答复功能，主要由3个模块来构成，分别是语义解析，后端搜索，排序截断这三个功能（因为时间有限，所以比较简单）：
语义解析主要是涉及到一个切词的功能，这个开源的切词模块都有，百度也有，切完之后，将高频词什么的都删掉，留下一些特征比较明显的名词或者形容词，另外这个切词的模块，最好自己用训练集训练出来，这样的话得到的结果会更加优美；

根据第一块切出来的词，我们会将这些词去做一个检索功能，检索功能是分开的，一部分是建索引，另外一部分是查询，建索引的操作和语义解析类似，其实也就是把问题和答案进行切词，把高频词去掉，留下特征词，可以根据需求，判断索引key的长度，最好是不要建单个字的索引，那样的话找出来的结果非常不好，建立好索引之后，查询这里的功能其实就是把各个切词拿出来的结果做个merge返回给前端；

第三个模块是排序和截断，排序主要是用来判断相关性什么的，另外还可以根据这个回答的点赞数，优先级进行加权平均，另外考虑到用户的个人属性，还可以把用户之前问的问题，做切词来进行查询做一个补充；根据排序会做一个截断，返回3-5条的答案返回回去，并给用户一个反馈的功能，好或者不好，用来优化下次功能；

这三部分做好了之后，一个基本的faq就做出来了，剩下的就是一些问题的补全等等；除此之外还可以接入一个聊天机器人，当后端能回答的用faq，不能回答的用人工，其他场景下用机器人

时间有限，就写这么多了；

index.php 增加一个module
jappengine.js 增加一个controller_confs

25日下午4点，第一次在妹妹家发现小朋友拉肚子，以为是正常的现象；
25日晚上8点，在高铁上发现小朋友第二次拉肚子，然后小脸通红通红，当时并没有太注意；
25日晚上10点，到达上海，在停车场泡牛奶给小朋友喝，喝了两口，就把火车上的东西都吐出来了，当时以为是火车上太闷了导致晕车，抱着开车回家；
25日晚上11点，到家后，给小朋友洗了个澡，然后小朋友很困了，在床上想继续喂点奶，结果又吐了；给小朋友整理了一下，发现太累了，就让小朋友睡了；
25日上午7点，起床后，发现小朋友精神还是不好，早上又拉了一点，纠结了半个小时，然后就去医院了
25日上午9点，出门的时候发现小朋友38°，到医院发现已经39°了，在人山人海的医院里，化验了血、大便，医生说是轮状病毒，开了若干个药，就打发我们回去了，路上发现美林也没有开，又回去找医生开了个美林；回去前买了个散热贴，贴到小朋友头上；
25日上午10点，在医院想起之前比较火的网文，讲中年人的流感，所以又去买了大人和小朋友的口罩，大人是带上了，小孩子怎么都带不上，就放着他一个人在那里呼吸医院的空气；
25日12点到家，12点半吃了美林后，开始逐渐降温，松了口气，小朋友开始活泼一点，就和老婆去上班，路上吃了碗面；
25日下午4点，打了个电话，发现小朋友还是很活泼；
25日6点多，爷爷通知又发烧到39度了，原来睡了一觉，又开始发烧了，于是马上赶回家；
25日7点半，第二次吃退烧药；
25日8点半，到家，小朋友貌似精神又不错，玩了一会，给小朋友洗了个热水澡；
25日10点，又开始发烧了，开始越来越热的样子，39-40度；
25日12点10分，第三次喂美林，等到12点半，还是没有退烧的样子，12点半，第二次去医院；
26日凌晨1点，挂了号，就开始漫长的排队，小朋友和他爸他妈一起在车里等着，爷爷奶奶在急诊室看号码，然后发现口罩也没有带来；
26日1点40，发现才过去两个号，一直是5,6号在里面看，接着就发现小朋友又退烧到了38度3；
26日2点20分，发现还是那两个号，进去看了一下，听说患者冲进去吵架了，发现医生在里面和熟人聊天；保安来了，又吵了一架；刚开始医生和保安很厉害的样子，后面看到人一多，就怂了，然后有人把视频发网上去了；
26日3点，吵完立马速度就快了，大概3,4分钟就看完一个，然后2点半终于开始看了；医生问了问情况（因为退烧了），说你们回去吧，如果继续发热，明天去看看流感；
26日3点40，到家，小朋友又开始发热了，发现手脚都比较冷，头很热，就用热水给小朋友泡了泡脚，用热水擦了擦脖子和前胸；太晚了，让爷爷奶奶先睡了；
26日4点，发现小朋友还是挺热的，用温水和散热贴继续敷；
26日4点30分，第四次喂美林，然后继续擦身子，温度大概39度多，喂了水，调了半个小时的闹钟，要是没开始降，就要第三次去医院了；
26日5点10分，发现降了一点，温度只有38度多了，喂了水，又调了一个1小时的闹钟
26日6点，发现开始出汗了，温度只有37度多，和老婆觉得松了一口气，终于开始退烧了
26日7点，发现拉肚子不是特别厉害了，换了个尿布；
26日8点，奶奶给儿子喂了喂水，然后发现又有点发热的迹象
26日9点，量体温又到38度3了，有不好的预感，和老婆去上班
26日11点，打电话又到39度3了，和爷爷奶奶说物理降温，多敷一下，等到12点多再喂退烧药
26日12点半，39.4度，喂美林，喂水，小朋友在床上睡觉
26日13点半，39度，小朋友喝了点粥

到中午反思一下：
1. 第一天晚上应该直接去医院，可能会好一点；
2. 医院生病的小朋友太多了，隔离要是做不好，很容易交叉感染；
3. 每次去医院之前吃退烧药，到医院了退烧了，然后回家不久又发热了，路上还奔波，小朋友还累；
4. 医院太远了，复旦大学儿科医院要开40多分钟；
没啥特别好的解决办法，不学医的总是面临问题的时候才会去解决问题，这种往往是很仓促而且无力的；

感性上说，自己看着还是挺悲伤的，小朋友生个病，一方面是精力体力的挑战，所以我一直劝人早结婚，早生娃。。年纪越小，你越有体力去抗住整个家的运作；从自己来说，虽然体力和精力还不错，但是和10年前刚读研究生的时候比，完全不是一个量级上，另外一方面是心理上的，看着小朋友难过的样子，真的是希望是自己生病；那种无力无助的样子，感觉特别心疼；很多情绪真的是当你到了一定的年纪，才会衍生出来，小时候特别怕死，然而年纪大了，发现接受一些东西比逃避那些东西会更好，所以才会有很多的看淡，才会有更多的勇敢；

理性上说，想到几个点：
1. 私人儿科医院（防止交叉感染，防止小病变大病）；
2. AI的协助诊疗、咨询；（在整个过程中，有太多慌张了，生病的时候，需要注意的点，哪些是其实不用那么慌张的，哪些是一定要注意的），包括前端时间比较火的那个中年人的文章，生病的时候的注意事项，可以避免很多可能是悲剧的事情；
3.小朋友去过的医院有复旦大学附属儿科医院、新华医院、上海市第一妇幼保健院，基本上是上海甚至是全国最好的儿科医院了，然后在整个过程中，会发现还是有很多的医生不负责任，敷衍了事；（这里面的原因很容易理解，因为很多病症是类似的，大量的流水线的作业使得其实很多时候并没有那么多精力去关注每个病人，而即使是敷衍了事，小朋友大部分情况也就是多生病几天），但是肯定会存在因为错过了两天的悲剧；上海已经是这样了，这两天查了不少网文，发现小地方的医生更甚，这是个普遍现象，是问题也是个机会；

暂时想到这么多，简单交个作业哈~

重读了一遍精益创业，最重要的点就是3个：

1. 提高效率

2. 数据推动

3. vip用户

1、在windows中安装TA-Lib，首先下载LA-Lib的whl文件：

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

最近在学习的时候，用到bagging和boosting的方法，所以在这里做一个简单介绍；

我们在做机器学习的时候，经常会很头疼，很多时候，我们选了不少的特征，做了很多的优化，但是准确率和召回率，到了一定的程度，他就不上去了,这种时候就会很头疼，当然这种时候也有很多的解决方法，增加数据集、换模型、优化特征清洗都是不错的方法等等，这里介绍另外一种思路，去解决这些问题；

提出bagging算法的人，其实我想就是受了日常一个非常简单的原理启发：当我们遇到一个问题不是很清楚，或者大家有分歧的时候，大家用的最简单的方法，就是投票吧，把这个理论应用到机器学习,bagging就是最简单的resample方法，通过从一个训练集随机选出N个子训练集，然后用来训练模型，训练出来的模型准确率只要大于0.5就可以留着，然后通过这若干个模型的投票，来确定最后的结果，就是bagging的简单介绍；这样将若干个弱分类器通过投票就变成了一个强分类器，准确度更高。另外，通过可放回的抽样，保证了这个套路可以并发进行，从工程的角度来看，可以使计算速度更快；

adaboosting是另外一种resample的方法，首先用训练集训练出一个模型，然后用这个模型进行分类，再将分类分错的样本拿出来，训练出第二个模型，第二个模型具有更高的权值，这样反复迭代，可以得到一个强分类器，可以保证全局最优；但是这个策略的问题是，如果有一些异常值，就会导致整个策略的效果不好；


其他还gbdt,xgboost,等之后系统的看一下的时候，再来写吧；

然后记一下最近看到另外一篇文章，通过以下方法可以有效提升机器学习的准确度：

1. 增加更多数据
2. 处理缺失值和异常值
3. 特征工程学，a.归一化，b.把不均匀分布变成正态分布或其他，c.分箱，d.建新特征
4. 特征选择，pca, lca等，可视化，
5. 用多种算法
6. 调整参数
7. 集成学习
8. 交叉验证

这里以备以后复习；

今年一定要有质的变化

滴滴打车和滴滴专车人群，并非和租车用户在场景上吻合；滴滴在推出租车服务后，通过重新分析专车和快车人群的多个维度特征，抽取与租车存在联系的画像特征，打标签，并进行训练。随后引入ab测试模型，并设计闭环数据产品，在不断对比和优化过程优化好推荐租车服务的模型，配合优惠政策，从而达到较好引导用户的效果；

一、背景

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

二、流量获取

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

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

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

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

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

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

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

三、提升转化

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

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

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

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

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

四、展望

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