运用大数据和风控手段，解决共享单车供求匹配问题

最近，看了不少共享单车方面的文章，其中有不少是探讨如何改善用户体验、提高共享单车供求匹配度和单车适用频次的。无论是文章本身，还是大家的评论，都让本人受益匪浅，以下是个人总结的一点资料，欢迎吐槽。

用户痛点：想用车的时候随时都有车可用；

企业痛点：提高每台单车的日均适用频次（企业需求）。

两者矛盾体现为：用户想用车，附近却无车可用或有车却用不了。而企业呢？一方面，用户有用车需求，却无法及时响应；另一方面，在其他区域，有大量的单车处于暂时闲置状态。这个需求其实是供与求在时间上、空间上相匹配的问题。匹配度越高，问题解决的就越好，匹配成本越低，效益就越好。

为了便于理解，先引入一个需求场景的例子，如下：

以深圳为例，年轻的上班族居多，也是共享单车的主要用户群体。早上大部分单车都停留在地铁口，公司上班时间一般是8:30或9:00，而在8:00 ~ 8:30之间的第一波上班族，把单车都骑到公司楼下了。结果8:30 ~ 9:00很少有从写字楼往地铁口骑车的，这期间出地铁的人，就无车可用，大量的单车停留在写字楼下，一直到下班，利用率极低。

那该怎么解决此类需求呢？很明显这属于大数据范畴了，通过大数据来实现是最理想的。此外，尚需引入风控思想，二者结合可达到意向不到的效果。另外，还需调整并新增功能，以摩拜单车为例，调整和新增的功能主要有：临时用车、预约用车、用车需求、接单。

临时用车：指的是普通用户，直接通过扫二维码用车的情况，此功能无需调整。

预约用车：指的是普通用户，通过摩拜APP提前预约用车的情况，预约生效时间为：距离预约时间5分钟至30分钟内的一个时间段。预约的不是某一辆具体的单车，而是指定区域内的骑车服务，补充说明见后文。

用车需求：当用户预约用车时，发现附近可用车辆有限，为了一会能顺利用车，可以发布一个用车需求，让其他用户通过接单，来满足自己的用车需求。用车需求与预约用车相比，在用车权利上是相同的，但失效条件略微不同。另外，在特定条件下，预约用车会自动转变成用车需求，详细说明见后文。

接单：当有用车需求产生时，用户就可以接单，将单车在有效时间内送至指定区域。用户发布的用车需求或由预约用车转变成的用车需求，都是属于某一具体区域的。如你想接单，通过骑车去到某个地方，你只需输入目的地，系统就会自动匹配并显示，由当前位置至目的地的几条主要骑行参考路线，以及接单方案，如图1所示：

当然，你也可以从当前位置直接骑车去到目的地，中途不换车。接单功能跟预约用车类似，接单也是不绑定具体的用车需求，而是指定区域内的任意用车需求。由图1可知，接单流程大致为：选定接单区域（可多个）→启动接单任务→将单车送至指定区域→结束接单任务（锁车后，系统默认匹配离失效时间最近的用车需求、或用户指定完成某一接单任务，个人倾向前者）

为了进一步阐释临时用车、预约用车、用车需求、接单之间的关系，请看图2和下方注释：

图 2

如图2所示，若甲直接扫码用车则属于临时用车的范畴；

在图2中，甲位于区域五，如出门前预约了区域四的单车，预约时间内骑的也是区域四中的单车，则属于预约用车；若实际骑的是其它区域的单车或不在预约时间内用车均属于临时用车；

如甲在区域一中发布了用车需求，乙接单了，并在有效时间内，将车送至指定定点（区域一），则乙顺利完成接单任务。否则，视为接单失败。

通过众包接单的形式就很好的利用了大数据的特性，当然也有些朋友指出，可通过后台大数据分析，在适当的时候安排车辆进行调度。其实，在成本可控范围内，安排专车调度也是不错的选项。

下面结合大数据和风控来详细介绍下，如何在保证预约用户用车的同时，又不影响普通用户临时用车，还可提高单车的适用频次。

首先，必须明确一点，用车需遵行的基本原则是：先到先用，这里指的是具体的人，谁最先扫码，谁优先使用该单车。

为了更方便的说明问题，把右图中的单车标记为不同颜色，以便于区分。以区域五为例，在区域五（直径100m的正方形）中，蓝颜色的单车，表示停放于该区域内的单车，数量为A；绿颜色的单车，表示区域五之外，到区域五中心半径为250m范围内，用户接单后骑行中、且目的地是区域五的单车，数量为B；红色表示距离区域五中心，半径250m范围内，骑行中的单车（这部分单车目的地是随机的），数量为C。若区域五中预约用车数为M，令Q = (A+B+uC)/M,（其中u是比例系数），P = A/M。如取Q = 0.6，P = 0.4为锁定预约用车阀值，则表示，当Q > 0.6且P>0.4时，临时用户与预约用户，均遵循先到先用车的原则；当Q <= 0.6或P <= 0.4时，区域五中的单车将被锁定，此时需优先满足预约用户的用车需求，先到先用车的原则就暂时只适用于预约用户了。

例如：图2中的甲预约了15分钟内区域五中的单车，那么如果当满足条件Q <= 0.6或P <= 0.4时，临时用户无法使用区域五中的单车，只有跟甲一样的预约用车用户才能使用单车，且预约用车用户之间遵行先到先用车的原则，只要先到，就可以使用其中的任何一辆单车。当条件被破坏后，则先到先用车的原则同时适用于预约用车用户和临时用车的普通用户。

上面已经包含了风控的思想，其中有很多风控点，如：区域的大小、预约用车时段、上图中的圆半径、以及P、Q、u等参数。如果想把风控做的更精细些，还需考虑其他因素，如：天气、行业竞争、历史影响（使用周期的问题，个人认为以周为单位比较合适）等。

预约用车与用车需求之间的关系：

当P <= 0.6时，新产生的预约用车会自动转变成用车需求数据。如前文所述：预约用车与用车需求在用车方面，权限是一样的，但失效条件，略微不同。当用户在预约时间段内，使用了预约区域中的单车，预约用车即可失效；或在预约时间内，用户未使用预约区域中的单车，则预约时间结束后，预约用车即失效。

针对某一区域的用车需求，当P > 0.6时，在指定时间内，有用户完成接单任务的，用车需求即刻失效；若在指定时间内，无用户完成接单任务的，指定时间一过，则用车需求失效。

当P <= 0.6时，若无用户完成接单任务，用车需求将保留至次日凌晨2:00后自动失效。值得注意的是：用车需求的失效与否，与发布用车需求的人，是否在指定时间内，使用发布区域内的单车无关。

可根据长期的实际运行效果和收集的数据，不断完善和调整风控规则与参数，使风控效果趋于完美。另外，若用户量有明显增长，也需考虑适当加大单车投入量，以保证用户用车的基本需求。

需要特别说明的一点是：为了更好的引导用户使用上述功能，达到通过众包、大数据、风控等手段来实现共享单车在供求关系上的高度匹配，从而解决用户用车难、有车不可用，单车适用频次低等问题。可以适当、合理的引入奖励（物质和精神上的都行）措施和社交元素，如：发布用车需求，可9折用车，接单可享受5折用车，鼓励大家绿色出行，用户量积累到一定量，可创建骑行日（如摩拜骑行日，可多个，如春、夏、秋、冬），并设置骑行日大奖（适当的设置一些获奖门槛，以达到长期互动，维持用户热度的效果）、形成骑行社区和社交圈等。当然，如何把握好奖励力度、实现激励用户的目标，并保证企业收益，也离不开大数据和风控的思想，此文就不在做深入的探讨。