揭秘Keep幕後：跑步路線的產品設計

健身 07-22

前言

隨著越來越多的跑步、騎行用戶選擇 Keep 進行記錄，我們在時空兩個維度上沉澱了越來越多的數據。在對這些數據進行組合後，不同地域的運動軌跡映射出了紛繁複雜而又極具特色的城市肌理，彷彿一幅構思精妙的延時攝影：

這些軌跡熱點客觀反映了城市裡熱門的運動線路，而這些軌跡數據對於我們幫助用戶合理規劃跑步和騎行活動，甚至是在幫助進行城市空間規劃、人行道和自行車道的布局上都能起到積極的作用。

針對前者，我們發現各種問答網站上都散落著這樣的需求：在知乎和百度知道上用「城市」和「跑步路線」為關鍵詞會搜到大量的問答內容；各類諮詢網站也常見某某城市十大熱門跑步線路等榜單。因此，我們自然地希望通過結構化的產品形態把這些內容落地到跑步模塊中，讓用戶更方便地發現身邊適合跑步的路線。

跑步路線產品形態

在思考產品時，我們想照顧到各個層次用戶的需求。針對 Keep app 內數量眾多的初級跑者，希望以「城市嚮導」的身份給這些用戶推薦路線。因此，除了展現路線本身的軌跡、海拔等信息外，也希望把路線上的風土人情圖文並茂地展示出來。無論你是小白還是大神，不管是你熟悉的還是短暫停留的陌生城市，都希望你能發現適合的跑步路線，激發你運動的衝動。

*註：在跑步子首頁和地圖頁面推薦的附近熱門跑步路線。

自然地，基於這些跑步路線實體我們聚合了同一條路線下的跑步記錄。用戶可以看到這條路線下的動態、打卡榜、成績榜等信息。對於路線上最近一個月打卡天數最多的人，我們會授予「路線主任」的頭銜，作為你勤勞圈地捍衛主權的一種獎勵，也希望你因此能被更多人關注到。

*註：壟斷紅領巾公園路線主任的用戶和激烈爭奪中的奧森南園跑道。

相較而言，路線下成績榜的展現更偏向「硬核」用戶：用戶可以對比自己歷次的路線成績，也可以看看這條「城市賽道」上誰是速度之王。在記錄的匹配上，為了盡量公平和排除不同客戶端硬體設備的差異，我們在成績的計算中盡量模擬實地比賽的情況：可以把過程想像成街機里的賽車遊戲：在賽道/路徑上會有許許多多個關卡(Checkpoint)，根據你通過的關卡的數量，我們會告知是否在按照預定的線路在完成比賽。而由於通過關卡時記錄帶著時間戳，我們也就知道了你在路線上的成績。

*註：奧森南園的路線成績榜

當然實際情況沒有這麼理想。跑步路線的類型各異，需要不同的匹配模式去對應不同情況：比如一條封閉的天壇公園環線，起終點並不固定，這種情況下我們需要根據跑者實際的跑步軌跡動態地匹配進入環線的點，以此作為起終點再進行匹配度的計算。在後台實現上，我們主要使用了 Geohash, KD tree 等演算法滿足快速的路線匹配和成績計算需求。

*註：路線匹配的示意圖。

路線內容的生產

PGC 內容

我們比較早地確立了通過 PGC + UGC 的方式進行內容的生產。針對 PGC 內容，通過技術 + 運營的手段梳理歷史數據，進行內容的準備工作。主要的手段包括但不限於：

A：對於開跑時間和地點相近，距離近似的跑步數據進行聚合。

B：通過現有的城市跑步路線榜單等信息，確定起終點和距離，匹配數據路中近似的

跑步數據。

C：計算跑步數據的質心，把質心相近的跑步路線進行聚合。

D：抓取高校列表，通過地理信息編碼獲取經緯度，並通過運營工具生成高校田徑場。

方案 A 獲得的數據聚合有很強的群體活動性質。由於成規模的跑團活動一般有比較好的計劃性，獲取到的路線質量較高；方案 B 獲得的路線質量同樣很高。但由於人工參與的部分比較多，效率較低。方案 C 獲得的路線數量最多，路線聚合則有很強的圖形屬性。由於演算法特性，匹配到的多是封閉的繞圈路線，其中以操場路線最為典型，和方案 D 結合比較有效。

UGC 內容

在產品上線 PGC 內容冷啟動之後，跑步路線內容的生產更多地轉向自於用戶提交。通過在產品中增加投稿入口以及運營線上的徵集活動，我們每天都收到來自全國各地甚至是海外的提交。

*註：跑步等級 R5 以上的用戶可以在記錄中提交投稿，看每天收到的來自世界各地的投稿會有春晚賀電的既視感。

後台處理工具

在人力有限的情況下，後台工具的搭建對於提高處理速度和在沒有「本地嚮導」的情況下完善內容尤其重要。跑步路線的生成、審核、下架等一系列流程都在我們的 CMS 後台完成。針對圖片和內容，我們藉助 Foursquare 的 API 介面獲取 POI 圖片和點評信息；針對海拔信息，通過接入 Google Elevation API 進行校準；針對軌跡信息，主要使用了 Mapbox 和 Turf.js 對點集進行查看、裁剪、標準操場生成等操作。