一款从0到1的旅行比价产品是什么（一款从0到1的旅行比价产品）
一款从0到1的旅行比价产品是什么（一款从0到1的旅行比价产品）酒店静态数据有了，怎么把城市/POI跟酒店关联，供用户查找使用呢？主要包括几个步骤： 格式标准化&算法去重&去僵尸&合并，最终提炼出一套标准格式的马踏飞燕酒店基础数据。要突出产品的比价必须做几件事： 业务数据尽量全； 参与平台尽量多；平台资源覆盖尽量广。要完成这几件事，进行了如下规划：下面以酒店数据为例。主要从公开渠道 和 合作方获取（公开渠道其实大家都懂，合作那就更不用说了）。目前已经涵盖的平台数据共20个，酒店数据总量超过1600万条。
这款产品以旅行比价 预订为切入点，面向对价格敏感的用户群体，通过大数据收集、整合、多平台资源暴露，运用分享砍价得现金券等运营手法，借力自研的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协议
