基于地理圍欄的網約車廣告模式*

朱昱衡 吳陳

（江蘇科技大學計算機學院 鎮江 212003）

1 引言

隨著移動互聯網的發展，網約車越來越走進人們的日常出行中，成為人們短程出行的首選。與傳統的出租車出行不同的是，網約車的商業模式，用經濟學語言描述，就是乘客委托平臺，指派合適的司機，以一定的時間將自己安全穩妥地從A點送到B 點，并為此支付相應的費用。因此，相較于傳統的出租車而言，網約車在未上車前就能得知出發地、目的地和性別等信息，這一點在廣告的精準投放上占有極大的優勢。

目前，出租車的廣告還是以紙質廣告為主，少數的LED廣告也比較僵硬，不能靈活更改。如果讓網約車也采取傳統出租車的那種廣告模式，則并不可取，所以本文結合網約車的優勢跟易裝卸的車載顯示屏，通過地理圍欄跟ES 相結合的技術來完成投放廣告的線上模塊設計。

2 地理圍欄

地理圍欄的概念就是在地圖上用虛擬的柵欄圈取一塊范圍，當手機進入、離開某個特定地理區域，或在該區域內活動時，手機可以接收信息。該技術被廣泛運用到無人機［1］、監控［2］、定位［3］、車輛調度［4］等方面。本次實驗主要用地理圍欄技術來判斷用戶的出發地跟目的地是否在某個圈定好的圍欄中。

2.1 圍欄樣例

實際項目中是通過內部的地圖進行圍欄劃分的，為了方便展示，以騰訊地圖為例。

圖1 是從騰訊地圖截取的，以某商業廣場為中心圈定的圍欄，當某一用戶打車目的地位于該圍欄內時，會在車載屏上投放相關的商業廣告，如廣場內部某商家的廣告，進行人群的較為精準投放。將圍欄信息存儲在數據庫中，劃分出的各個地理圍欄均有各自的id，會在ES中起識別作用。

圖1 某商業廣場的圍欄

2.2 經緯度識別

一個圍欄里面的每一個位置都有對應的GPS的經緯度坐標值，因此判斷某定位的經緯度在不在圈定的圍欄內的這個問題可以轉換為判斷點與多變形關系［5］的問題。

常用的方法是射線法［6］，它對凹多邊形、凸多邊形均適用，且不存在精度誤差問題。射線法主要是通過對目標點向右引一條射線，計算該射線跟多邊形邊相交的點的個數，如果是奇數一定在多邊形內，反之則不在。

如圖2 所示，從不規則多邊形內部某點向右引的射線P1 與多邊形邊界只有一個（奇數）交點，從外部某點向右引的射線P2 與邊界有兩個（偶數）交點。

圖2 射線法示意圖

3 數據分析

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 實驗過程與結果

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。

5 結語

作本文的研究結果，以圍欄為主要維度的網約車廣告模式在理論跟線上的系統設計中都是合理可行的。大數據時代，根據用戶數據來針對性地投放廣告已是一種常態，因此筆者順應趨勢，將該方式與打車這個場景結合，達成互利共贏的廣告模式。網約車公司跟司機獲取廣告收入，廣告商得到流量，因為外部設備是車載屏且廣告無聲，對乘客的影響比傳統出租車的廣告還低，因此也不會對乘客產生負面影響。

本次研究還有值得進一步探索的地方，就是廣告的推薦。如果廣告量大了后，如何判斷用戶留意了何種廣告，用戶跟廣告之間的交互如何設計是個難點，并且用戶跟廣告之間是一種隱式反饋，如何根據用戶之前對某類型廣告的關注來直接推送同類型的廣告，這些方面還值得深入研究。

本次實驗主要是模式探索跟線上實驗驗證，對實際乘客打車，在網約車上看到廣告的場景沒有進行研究。不過，據筆者所知，滴滴出行在杭州跟上海投放了一千輛帶有車載屏的網約車，來探索這個廣告模式的實際效益。