OTA 产品转化率的几个案例

[核心提示] 这 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年的职业生涯就结束了。想做的太多太多了，做出来的又太少了。

【文章摘自：极客公园  ； 作者：哞哞张】