這款產品以旅行比價+預訂為切入點，面向對價格敏感的用戶群體，通過大數據收集、整合、多平臺資源暴露，運用分享砍價得現金券等運營手法，借力自研的AI智能推薦系統，支持語音輸入&搜索&下單。

圍繞全網比價、低價預訂、分享砍價、快捷、科技范，幫助廣大消費者找到攜程&美團等OTA無法提供的低價&可訂的旅游產品。

一、確定產品要支持的預訂渠道

總的預訂渠道分為線下和線上兩大類。線上預訂的主要渠道有APP、小程序、H5網頁、web 網頁等，線下渠道主要是門店，熱線預訂等。

考慮到推廣方便、開發迭代敏捷、獲客成本、潮流趨勢、人群屬性、業務場景、搭載功能的載體、封殺下的存活等因素，做了如下分享，并最終確定 APP+小程序+H5 的線上預訂渠道。

二、圍繞產品所解決（比價）痛點找數據

要突出產品的比價必須做幾件事： 業務數據盡量全； 參與平臺盡量多；平臺資源覆蓋盡量廣。

要完成這幾件事，進行了如下規劃：下面以酒店數據為例。

1. 數據的獲取

主要從公開渠道 和 合作方獲?。ü_渠道其實大家都懂，合作那就更不用說了）。目前已經涵蓋的平臺數據共20個，酒店數據總量超過1600萬條。

2. 數據的處理

主要包括幾個步驟： 格式標準化&算法去重&去僵尸&合并，最終提煉出一套標準格式的馬踏飛燕酒店基礎數據。

酒店靜態數據有了，怎么把城市/POI跟酒店關聯，供用戶查找使用呢？

3. Region數據的獲取&整理&標準化

由于酒店數據來自20個平臺數據的提煉，同時有國內和海外之分，在Region數據的抽取方面剛開始走了很多的彎路，整理出來的數據出現過不全面，格式不對匹配校驗難推進，數據重復錯誤等情況。最終采用逆向處理，才把全球的Region數據弄全，弄準確。

I. 對酒店基礎數據進行 經緯度提取，校驗，正確性驗證。

II. 對提取的經緯度數據進行：google、百度、高德、騰訊 等格式的轉化。

III. 通過多條經緯度反查Region，再對各反查結果進行清洗，整合，層級劃分。

IV. 根據 百度，高德，騰訊 和 Google 在區域性上的數據優劣，采用優為主，劣為輔。

V. 通過層級整合出一套全球的Region 基礎數據，再通過映射關聯酒店信息。

例如： 每個國家的Region劃分存在較大差異：

百度數據在中國大陸和港澳臺地方的Region 層級劃分采用： 大洲-國家-省-市-縣（區）-鄉鎮 的6層結構

而google數據在海外有優勢，同時又考慮到google地圖在不同國家的層級劃分有差異，因此定義其層級劃分時采用了兼多并廣抓主的策略 ，設置了如下層級：continent，country，administrative_area_level_1，administrative_area_level_2，administrative_area_level_3，locality ，postal_Town，administrative_area_level_4，administrative_area_level_5，natural_feature,，sublocality，neighborhood。

通過上述處理整合出了一套12w+的樹形結構Region基礎數據，并支持根據酒店資源的新增情況同步擴充Region數據，真正做到了數據的可靠性高，可擴展性強，延伸面廣，層級劃分清晰；

三、圍繞產品所解決（預訂）痛點找資源

在完善酒店數據和Region關聯酒店數據后，用戶可以找到全球260萬酒店，也已經支持一鍵跳轉到第三方合作平臺下單。但此時用戶仍只能對各OTA進行比價，沒有一手資源房型的低價供用戶預訂，接入API 一手資源，提供跟直接的低價預訂則是接下來的重頭戲。

這個過程持續的時間較長，先后接入了藝龍、去哪兒、好巧網、道旅網、捷旅假期、龍騰捷旅、美團、途牛、攜程、聚優惠、同程等11個API平臺。

在這個過程中拋開商務談判外，對接多平臺時各API的兼容和展示模式，是產品必須全盤考慮到一個問題。

I. 展示模式：采用了淡化知名度&去中心化，全以價格優劣來分層展示，保證各平臺的公平競爭。

II. API兼容上：我們從用戶訴求出發，結合各API的數據支持情況，抽取并整合出一套標準的API接口格式；然后再根據標準的API格式對各平臺接口進行解析。

這個過程不是一蹴而就的，需要進行了大量的溝通、整理提煉、相互改進等工作。

在策略上采用先易后難，由簡到繁，進行了多個迭代： 首先只解決了房型名稱和價格等核心信息的展示；后續再迭代加入了早餐、床型、住客限制、容納人數、房型圖片、發票、禮盒、設施、取消政策及退款等功能。

III. 運營上： 根據功能的完善情況，推廣上也慢慢發力，采用冷啟動，循序漸進。這樣用戶體驗上：對房型的認知就慢慢由抽象不確定 到 可見更全面認識，增強了用戶對平臺可靠性和真實性的信心。再加上截長圖分享， 領紅包砍價 和 小程序里的拉新活動，用戶能得到真實底價上的再減優惠。

V. 用戶感知上： 優化UI布局，增加必要的快捷篩選功能，增加權威性，又加入了酒店官網數據。

最終多平臺比價的頁面就打造出來了：

四、下單流程的梳理

前面講到的主要是基礎數據展示、接口數據展示、產品痛點的突出等方面的內容。

用戶下單過程中的流暢便捷其實更關乎產品是否成功：用戶越到流程的末端，對異常和阻塞的容忍就越低，當精心挑選的房型在填寫頁、支付頁出現異常時，沒有一個用戶不會咆哮和憤怒。

因此這些頁面的產品使用情況一定要站在用戶角度深刻體會，進行徹底解決或者友善的引導。

如：

I. 資料填寫頁：增加 常旅客&常用聯系人 快捷入口，發票信息的自動帶入歷史數據等。

II. 支付頁：默認選中滿足條件的現金券，減少干擾項。

III. 對各API的下單可靠性進行長時間的調研分析，針對分析結果進行重點優化，直至到達預定目標。

IV. 對影響入住的信息進行突出展示，完善通知短信，郵件等用戶信息獲取渠道。

為了產品的完整性，分步搭建起了：

• app+小程序+h5預訂的格局；
• 對CRM公用模塊 和 后臺模塊進行了整合；
• 為了增強用戶的互動性，打造了網紅酒店、完善點評系統、完善了LBS地圖的立體展示等功能模塊；
• 對可能出現的風險點 規劃了數據加密、反爬等技術提升；
• 對數據進行了 持續的定期更新，保證數據的準確性和完整性；
• 同時啟動了喚醒計劃。

通過一系列的優化迭代，酒店訂單由原來的每天0單、1單，經過近8個月的緩慢增長，攀升到目前的每天120單左右，預訂確認失敗率控制在2%以內。

目前酒店項目比價頁的UV用戶達到170W+, 注冊用戶56W+，小程序的 DAU 5000+，MAU 7W+，在沒有廣告推廣的情況下新注冊用戶以每天3000+左右增加，后續還會在性能，用戶體驗和細節上繼續提升。

給大家展示一下APP的首頁，可以試試AI推薦和語音下單了， 下一版再解鎖醫美產品。

本文由 @飄雪的南方小城 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議