基于地理围栏的网约车广告模式*

朱昱衡 吴陈

（江苏科技大学计算机学院 镇江 212003）

随着移动互联网的发展，网约车越来越走进人们的日常出行中，成为人们短程出行的首选。与传统的出租车出行不同的是，网约车的商业模式，用经济学语言描述，就是乘客委托平台，指派合适的司机，以一定的时间将自己安全稳妥地从A点送到B 点，并为此支付相应的费用。因此，相较于传统的出租车而言，网约车在未上车前就能得知出发地、目的地和性别等信息，这一点在广告的精准投放上占有极大的优势。

目前，出租车的广告还是以纸质广告为主，少数的LED广告也比较僵硬，不能灵活更改。如果让网约车也采取传统出租车的那种广告模式，则并不可取，所以本文结合网约车的优势跟易装卸的车载显示屏，通过地理围栏跟ES 相结合的技术来完成投放广告的线上模块设计。

地理围栏的概念就是在地图上用虚拟的栅栏圈取一块范围，当手机进入、离开某个特定地理区域，或在该区域内活动时，手机可以接收信息。该技术被广泛运用到无人机［1］、监控［2］、定位［3］、车辆调度［4］等方面。本次实验主要用地理围栏技术来判断用户的出发地跟目的地是否在某个圈定好的围栏中。

2.1 围栏样例

实际项目中是通过内部的地图进行围栏划分的，为了方便展示，以腾讯地图为例。

图1 是从腾讯地图截取的，以某商业广场为中心圈定的围栏，当某一用户打车目的地位于该围栏内时，会在车载屏上投放相关的商业广告，如广场内部某商家的广告，进行人群的较为精准投放。将围栏信息存储在数据库中，划分出的各个地理围栏均有各自的id，会在ES中起识别作用。

图1 某商业广场的围栏

2.2 经纬度识别

一个围栏里面的每一个位置都有对应的GPS的经纬度坐标值，因此判断某定位的经纬度在不在圈定的围栏内的这个问题可以转换为判断点与多变形关系［5］的问题。

常用的方法是射线法［6］，它对凹多边形、凸多边形均适用，且不存在精度误差问题。射线法主要是通过对目标点向右引一条射线，计算该射线跟多边形边相交的点的个数，如果是奇数一定在多边形内，反之则不在。

如图2 所示，从不规则多边形内部某点向右引的射线P1 与多边形边界只有一个（奇数）交点，从外部某点向右引的射线P2 与边界有两个（偶数）交点。

图2 射线法示意图

3.1 ES的应用

ES 全称为Elasticsearch，是一种非关系型数据库，能够分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索，并且是一种实时分析的分布式搜索引擎［7］，有着倒排索引、高稳定性、高访问效率、高容错性、高可扩展性等优点，能适应现今的大数据时代［8］，广泛应用于天文［9］、气象［10］等领域。ES的更新机制跟一般的InnoDB型数据库有细微不同，它执行更新操作时分为两类：全部更新跟局部更新。为了避免脏数据的产生，本项目的ES采取全部更新。

项目中一个简易的ES数据表如表1所示。

表1 ES样例

各个字段的作用跟含义如下：id字段表示数据段的顺序；
ad_id 段顾名思义就是具体对应哪一个广告；
sex 字段0 代表性别不限，1 代表男性，2 代表女性；
minAge 跟maxAge 表示年龄上下界；
city 字段代表城市，采用的高德API 定义的城市编码，样例中110000 代表北京，310000 代表上海，0 为自己定义的不限；
fence 字段表示地理围栏，具体对应地图上圈取得哪个范围，样例中0表示不设范围，2表示A 广场，3 表示B 广场；
status 字段表示状态，1 代表下架，0代表下架。

以上每一条数据都是通过广告平台录入的，可以随时更改相关数据。

3.2 数据处理

实验主要目的是为了验证这个模式在线上能否走得通，因此对数据量要求不大，反而对数据的多变性要求偏高，因此数据以mock居多，确保实验的多样性。

mock 是一种白盒测试的方式，测试时需要跑几条真实数据，但制造真实数据较为繁琐，为了覆盖全面，需要对该数据进行部分字段的修改，这个时候就需要通过mock的方式。

3.2.1 广告数据

实验中，一条符合要求的广告具有：id（自动生成）、名称、视频、投放范围（即哪个围栏）、每天投放时间段（本次实验对此不做约束，默认全天投放）、投放日期、状态。

3.2.2 用户数据

因为市面上网约车的用户数据获取都是由订单信息里的手机号去内部获取，得到用户注册时的信息。所以实验中，取部分用测试号真实打车的订单，其余订单数据模拟生成，一步步解析后得到包含性别、年龄、城市、围栏的数据。

4.1 实验流程

整体分为两部分：广告平台跟投放主流程。

如图3 所示，与传统的上传平台不同的是广告平台增加了对接ES的功能。

图3 广告平台

网约车的整个打车状态可以分为六种，广告投放作用在行程开始的状态下，起中台作用，对上下游交互数据进行处理。

如图4 所示，广告投放中台位于“行程开始“状态下，整体流程分两部分进行，在ES 处交汇，进而输出正确的数据封装返回给下游。

图4 打车topic

图5 中流程可以细分为四步，分别是订单分析、用户分析、经纬度分析、ES 筛选，其余都是对输出数据进行包装处理。

图5 投放主流程图

4.2 实验过程

实验采取线上模式，通过数据在代码中的输入输出来进行实验。根据输入的订单数据处理首先得到出发地跟目的地的经纬度，从而得到相关围栏，接着又得到性别、年龄之类的判断条件，进而封装成一条数据段参与ES 的筛选，从而得到对应广告数据，对所得数据跟透传数据进行封装，输出返回值传递给与终端交互的下游。

4.3 测试优化

4.3.1 降低耗时

多次实验发现，这个系统的耗时过长，足足有近300ms，这个问题在实际的线下是致命的。分析后发现是调用获取经纬度的接口次数过多，一次的经纬度获取耗时就有近80ms，其他的用户画像获取跟ES 筛选均10ms 左右，通过增加中间值，将经纬度获取降为一次，耗时成功控制在100ms左右。

经纬度的获取并不在本此中台的实际代码设计中，而是通过对外部接口的调用来获取，作为支撑网约车定位的外部接口，位置精准是达标的，并且之前的多次调用返回的经纬度一致也侧面证实了这一点，因此降低经纬度接口调用并没有降低位置准确度，可以满足围栏需求。

4.3.2 异常case测试

故意对数据进行错误的模拟，例如错误订单验证；
对经纬度作修改，验证了经纬度在围栏外的场景；
对将与ES 比较的数据修改，验证了ES 处理逻辑，从而发现了全局覆盖的问题。

4.3.3 兜底值处理

实验中，多数测试对象的年龄、性别等属性均模拟输入，忽视了可能出现无法取值的现象，对中间相关参数的传递进行了兜底设置，哪怕取不到，也会通过语句判断，在传递中给附上默认值，以防代码bug导致系统中断。

4.4 实验结果

通过不断的调试，当订单信息进入系统中，在100ms 的延时后，得到一条封装好的返回值，值中包含广告id 这一属性，并且为了避免误差，对实验进行了多次异常测试跟回归测试，结果都很理想，符合预期，图6 是一次成功取得广告并封装的返回值。

图6 返回值

由于是在中台上进行处理，因此成功封装好返回值就代表实验结束了，返回值交给下游处理，并转换成视频展示在关联的车载屏上，整个中台的延时约为120ms。

作本文的研究结果，以围栏为主要维度的网约车广告模式在理论跟线上的系统设计中都是合理可行的。大数据时代，根据用户数据来针对性地投放广告已是一种常态，因此笔者顺应趋势，将该方式与打车这个场景结合，达成互利共赢的广告模式。网约车公司跟司机获取广告收入，广告商得到流量，因为外部设备是车载屏且广告无声，对乘客的影响比传统出租车的广告还低，因此也不会对乘客产生负面影响。

本次研究还有值得进一步探索的地方，就是广告的推荐。如果广告量大了后，如何判断用户留意了何种广告，用户跟广告之间的交互如何设计是个难点，并且用户跟广告之间是一种隐式反馈，如何根据用户之前对某类型广告的关注来直接推送同类型的广告，这些方面还值得深入研究。

本次实验主要是模式探索跟线上实验验证，对实际乘客打车，在网约车上看到广告的场景没有进行研究。不过，据笔者所知，滴滴出行在杭州跟上海投放了一千辆带有车载屏的网约车，来探索这个广告模式的实际效益。