快捷搜索:  汽车  科技

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)酒店静态数据有了,怎么把城市/POI跟酒店关联,供用户查找使用呢?主要包括几个步骤: 格式标准化&算法去重&去僵尸&合并,最终提炼出一套标准格式的马踏飞燕酒店基础数据。要突出产品的比价必须做几件事: 业务数据尽量全; 参与平台尽量多;平台资源覆盖尽量广。要完成这几件事,进行了如下规划:下面以酒店数据为例。主要从公开渠道 和 合作方获取(公开渠道其实大家都懂,合作那就更不用说了)。目前已经涵盖的平台数据共20个,酒店数据总量超过1600万条。

这款产品以旅行比价 预订为切入点,面向对价格敏感的用户群体,通过大数据收集、整合、多平台资源暴露,运用分享砍价得现金券等运营手法,借力自研的AI智能推荐系统,支持语音输入&搜索&下单。

围绕全网比价、低价预订、分享砍价、快捷、科技范,帮助广大消费者找到携程&美团等OTA无法提供的低价&可订的旅游产品。

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(1)

一、确定产品要支持的预订渠道

总的预订渠道分为线下和线上两大类。线上预订的主要渠道有APP、小程序、H5网页、web 网页等,线下渠道主要是门店,热线预订等。

考虑到推广方便、开发迭代敏捷、获客成本、潮流趋势、人群属性、业务场景、搭载功能的载体、封杀下的存活等因素,做了如下分享,并最终确定 APP 小程序 H5 的线上预订渠道。

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(2)

二、围绕产品所解决(比价)痛点找数据

要突出产品的比价必须做几件事: 业务数据尽量全; 参与平台尽量多;平台资源覆盖尽量广。

要完成这几件事,进行了如下规划:下面以酒店数据为例。

1. 数据的获取

主要从公开渠道 和 合作方获取(公开渠道其实大家都懂,合作那就更不用说了)。目前已经涵盖的平台数据共20个,酒店数据总量超过1600万条。

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(3)

2. 数据的处理

主要包括几个步骤: 格式标准化&算法去重&去僵尸&合并,最终提炼出一套标准格式的马踏飞燕酒店基础数据。

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(4)

酒店静态数据有了,怎么把城市/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布局,增加必要的快捷筛选功能,增加权威性,又加入了酒店官网数据。

最终多平台比价的页面就打造出来了:

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(5)

四、下单流程的梳理

前面讲到的主要是基础数据展示、接口数据展示、产品痛点的突出等方面的内容。

用户下单过程中的流畅便捷其实更关乎产品是否成功:用户越到流程的末端,对异常和阻塞的容忍就越低,当精心挑选的房型在填写页、支付页出现异常时,没有一个用户不会咆哮和愤怒。

因此这些页面的产品使用情况一定要站在用户角度深刻体会,进行彻底解决或者友善的引导。

如:

I. 资料填写页:增加 常旅客&常用联系人 快捷入口,发票信息的自动带入历史数据等。

II. 支付页:默认选中满足条件的现金券,减少干扰项。

III. 对各API的下单可靠性进行长时间的调研分析,针对分析结果进行重点优化,直至到达预定目标。

IV. 对影响入住的信息进行突出展示,完善通知短信,邮件等用户信息获取渠道。

为了产品的完整性,分步搭建起了:

  • app 小程序 h5预订的格局;
  • 对CRM公用模块 和 后台模块进行了整合;
  • 为了增强用户的互动性,打造了网红酒店、完善点评系统、完善了LBS地图的立体展示等功能模块;
  • 对可能出现的风险点 规划了数据加密、反爬等技术提升;
  • 对数据进行了 持续的定期更新,保证数据的准确性和完整性;
  • 同时启动了唤醒计划。

通过一系列的优化迭代,酒店订单由原来的每天0单、1单,经过近8个月的缓慢增长,攀升到目前的每天120单左右,预订确认失败率控制在2%以内。

目前酒店项目比价页的UV用户达到170W 注册用户56W ,小程序的 DAU 5000 ,MAU 7W ,在没有广告推广的情况下新注册用户以每天3000 左右增加,后续还会在性能,用户体验和细节上继续提升。

给大家展示一下APP的首页,可以试试AI推荐和语音下单了, 下一版再解锁医美产品。

一款从0到1的旅行比价产品是什么(一款从0到1的旅行比价产品)(6)

本文由 @飘雪的南方小城 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

猜您喜欢: