OTA 产品转化率的几个案例

1 评论 18875 浏览 29 收藏 16 分钟

[核心提示] 这 2 年在 OTA 行业做 PM做了几件事情,没用的事情:订单页改版、详情页改版;有用的事情:支持国内信用卡支付、10%优惠、搜索优化;效果未知的事情:着陆页优化。

最近读苏杰的《淘宝十年产品事》,这本书把电商产品层面的方方面面都点到了。我也曾经在一家 Online Travelling Agency 的国际酒店频道做了 2 年,通过各个团队角色的努力,2 年后转化率提升了 100%。也贡献几个相关案例,时效性至 2013 年 6 月,且出于保密原因,部分数据不一定真实,但大体的方向是真实的。因为案例本身就不系统,也就不按任何维度来划分了。

这 2 年做了几件事情,没用的事情:订单页改版、详情页改版;有用的事情:支持国内信用卡支付、10%优惠、搜索优化;效果未知的事情:着陆页优化。

订单与详情

其中,订单页、详情页改版因为没有解决任何问题而没有效用。改版是我毕业后 4 个月接手国际酒店做的第一件事,可能也是很多新手 PM 会犯的错误(其实真心感谢当时的老大放手让我作-_-b)。一方面,当时我并没有认清 PM 的职责和优化电商网站的关键要素,更多的做一些交互、视觉的工作。另一方面,我能发现一些用户关心的问题,比如国内用户更倾向于在详情页选择“单人间”、“双人间”预订,而不是在首页/列表页的筛选项选择“一人入住”、“两人入住”;在后者的流程里,很多用户因为搞不清楚单人间、双人间干脆就不订了(那时还 12 年呢,出境游刚热起来,很多用户都是初级使用者)。但这个改不了,为什么?一般电商网站都是有自己的后台的,可我们采用一家海外 OTA 的库存,直接调用 API,人家的 API 不支持,我们就做不了。

国内信用卡支付

其实在做 2 个页面改版前,我有分析网站的转化率漏斗,发现和行业平均值差距最大、对结果可能提升最大的是支付成功率。一般电商网站都不会有这个问题,为什么我们会有?为什么不首先解决?

上文提到,我们拿海外 OTA 的库存,全靠调用 API。美国人的信用卡使用率非常高,因此这家海外 OTA 的支付接口也仅支持国际信用卡,但中国人信用卡普及率低,能海外支付的就更少了,很多用户填了支付信息结果返回错误。那我们为什么不把支付本地化呢?这是因为那时国际酒店不是战略重点,资源有限,技术上调用 API,ROI 最佳。

但有了前两次失败,我意识到,我是在“只能调用 API”这个既定前提下想解决方案的,但这个前提可能本身就有问题。如果在这个前提下我们难有作为,为什么不打破这个前提呢?我那时对技术成本没有概念,于是觉得我们得本地化支付流程,把目前中国用户使用率高的支付方式都接入进来。这个方案不是没人提过,但一直落实不了。这次内因、外因加和,包括我也非常坚定(其实是刚出道想的少),算是立项了。

当时公司策略主推信用卡不推支付宝(我居然想都没想就接受了这个策略,也为后来埋下了隐患),我们就先解决国内信用卡支付问题。方案就是我们建立了一张假国际信用卡,加入海外 OTA 的白名单,用户支付给我们,我们再支付给海外 OTA。流程上的坑就不细说了,其实作为一个电商系统,我们也没有兼顾不同的使用者。比如,这个系统不仅需要支持用户、客服,还要支持财务和海外 OTA 结算,所以最小商品单位要一致,因为一开始没有考虑这个问题,后来需求推翻重写。

最终总算上线了,确实对转化率有提升。然后那时很多用户反馈没有信用卡,为什么不支持借记卡、支付宝?我一开始就觉得应该支持,但发现又坑了。

大家知道,预付酒店,实际流程是“信用卡预授权,等入住后再扣款”,体现在支付系统上,就是“预授权–>订单确认–>扣款”。如果在第三方支付上复用这套系统,就变成了“订单确认–>扣款”。很多时候,你看电商网站下单了,只不过是限时锁定订单,等用户去支付;如果用户限定时间内不支付,就释放库存。但由于海外 OTA 的 API 不支持锁定,我们如果复用现有流程就意味着要先替用户支付以下单,而部分酒店库存是不支持退款的(特价),我们肯定要承担损失。由于又要开发一套支付流程,加上各种外因,这个项目就先暂缓了。

10% 优惠带来的改变

做完支付本地化项目,出境游也越来越热,公司也开始考虑如何更好的做好国际酒店。当时虽然没啥资源追加,但是老板看到我们在价格上完全没优势,就允许我们全网降价 10%。结果大幅度的提升了转化率!也就在那个时候,我开始想对于电商网站,什么是最重要的因素,首先还是商品。(当然也感觉产品经理的价值观“崩塌”了,笑)

别看就是降价 10%,其实也要考虑很多因素:究竟是直接在价格中减去好还是采用亚马逊给出优惠码的模式?优惠用直减方式还是返现方式(后来两种都用了,原因下文再说)?等等。其实这是个很好的 AB Testing 的机会,但是一来技术不成熟,二来我们基数实在太小了(后来才知道,其实这也是影响 AB Testing 测试时长原因之一),所以就没做,因此在这方面我也没什么定论。但是决策还是要做,我选择了亚马逊优惠码的方式(小公司的非核心产品线能让你快速试错)。因为直接减去的话,用户很难有直观印象,OTA 的列表页首页结果又不一样,怎样能感受到我们的价格更低呢(其实也有用户多家 OTA 搜索同一个酒店来比较价格,所以策略最好能做到精细化)?不如一来就直接告诉用户全场 10%优惠。

10%优惠之后,用户很高兴,但是发生了我预料不及的问题。品牌酒店总是在各个渠道维护统一的价格,这是出于品牌形象的考虑。虽然我们不跟海外酒店直接签合同,但是一些品牌酒店在我们网站看到他们的库存居然打折销售,就说要关库存。那可不行,品牌酒店在我们的销量排行榜上可是居前的。在此之前,也是因为技术资源有限,我首先考虑用户需求,很多其他利益相关者的需求都不列入排期。但是这件事情让我更加深刻的意识到,我们是有上下游的,需要兼顾供给方和需求方的利益才能可持续。那我们怎样既给用户实惠,又帮助供应商维护品牌形象呢?我们先想和酒店沟通一下,声明不是酒店降价,而是我们公司”出血“,可是酒店也不答应。于是就出返现策略。有些酒店返现都不行,没办法,就只能不折价仅给用户N倍积分了。另外,有一类用户是行政,他们很希望用户公司的钱原价预订,但是返现到自己的腰包里,所以也要求支持返现。虽然经历了返现这个项目的前期种种,但却不是我落实的,因为那时候我已经离职啦。

搜索的优化

很多用户反馈一些目的地搜索不到,于是我们就抓用户搜索的关键字,系统(其实是人工啊,PM 拉一大批抽样数据,在 Excel 里 Ctrl+F 关键字去对比库里数据啊,血泪史!)的分析了一下。无翻译(我们使用海外 OTA 的 API,所以很多数据都是英文的)、多别名都算小问题,目前大热门的目的地都可穷举,哪怕人工解决都可以。真正坑爹的问题有两个,一个是这家海外 OTA 的特殊性问题,另外一个是行业的通用问题。

先说第一个问题。香港的历史比较复杂,这家海外 OTA 在地理上把香港当作一个国家,但是他们的API是不支持以“国家”为搜索维度的。于是,你搜索“香港”,返回的仅仅是香港的某一块区域,而你得搜“沙田”、“九龙”才能返回对应地区的酒店。而香港恰恰是预定量第一的地区,这种地理位置划分策略给用户的直观感受就是“你们香港的酒店真少”(T^T)。有 2 种解决方案,一种是,我们把大香港下的地区都挑出来,在前面加个“香港”2字,这样在关键字“香港”的 suggestion 里,我们也列出了其他区域供用户选择。另外一种是,我们把香港其他区域下的酒店都关联到“香港”关键字下。而无论哪种方案,目前的 API 都不支持,得我们自己做一个本地数据库,把关键字做一次转化再发给 API 接口。然后我们就又立项了,方案 1 成本小,做好了先上,然后又上了方案 2。前面说了,我们的基数小不适合做 AB Testing,所以这次也没做。因此真正的效用很难说,但可以肯定的是,这 2 年中,国际酒店转化率一直呈平缓的上升趋势。

上面的问题,引发我们想到了行业里的通用问题,就是“如何对应地理和酒店的关系”。比如,在城市层面,你搜索”北京“,大兴算不算北京?在地标层面,以地标为中心返回方圆 X 米(而且,X 定为几合适呢?)的酒店呢?还是把地标定义为一个多边形(谁来定义?标准又是什么?)返回其覆盖范围内所有的酒店呢?由于我们之前都是调用 API,所以海外 OTA 给啥我们就展示啥,但经常有用户质疑我们的展示结果(怎么没酒店?酒店离地标太远!等),我们开始想这里是不是有优化的空间?

通过我自己去泰国的感受,我感觉 Booking.com 在这个方面做得比较好。比如,搜索素坤逸大街(具体的我记不住了,随便写一个说明下意思)的酒店,覆盖区域远大于真正的行政区划,因为 Booking.com 知道,有条快轨穿过这个手工画出来的区域,核心区住宿价格昂贵,但是只要有快轨,我住远一点也行呀。但这个问题太复杂了,也需要兄弟部门、大量数据/算法的支持,所以到我离职之前国际酒店也没有做。

着陆页优化

这个其实是我们当时的业务经理提出来的(对,他很有 PM Sense 的,第 2、3 个项目都离不开他的支持),因为电商很多的钱都给了百度,通过搜索过来的付费用户当然要最大程度好好保留了。然后我照着 Booking.com 的城市页“揣测”了一下用户意图,觉得如果用户通过百度大搜索目的地过来,那 TA 很可能是个不太知道 OTA 网站的初级用户,TA 可能希望的不是各种让人发懵的搜索项,而是告诉 TA:去这个陌生的海外城市究竟住哪里好呢?这个问题,其实攻略网站有答案,但是非常抵低效,而且和预订流程割裂了,那时候我想,能不能打通这个前后环节?

其实到现在也没感觉这个方向大做起来,很可能是内容网站数据不够碎片化,而且推荐算法也不成熟吧?攻略网站都希望能通过给预订网站导流赚取佣金,目前看得到的是穷游网和 Booking.com 的合作,但具体成交量我也不知道。但在当时我们是怎样解决的呢?我们选取了10个试点城市,人工(全是眼泪)收集编撰了入住指南,可以直链地标筛选;然给出酒店销量排行榜。

这个着陆页究竟好还是不好,没有定论。因为一些城市的转化率高于普通列表页,另一些却低于;跳出率的降低也是良莠不齐;至于增加了排行榜,对单个酒店的提升和对其他酒店的影响,我们也没有衡量。而且这个页面最大的问题在于难以量产(内容全是人工编撰的么,而且必须要非常准确、实用才有真正的帮助预订的作用),后来也就不了了之了。

然后我2年的职业生涯就结束了。想做的太多太多了,做出来的又太少了。

【文章摘自:极客公园  ; 作者:哞哞张】

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 想做的太多太多了,做出来的又太少了。
    ————————————————————
    太多太多人都是这样,想得太多,做的太少,所以聚焦很重要。

    来自上海 回复