OTA 产物转化率的几个案例
本文摘要:[核心提示] 这 2 年在 OTA 行业做 PM做了几件事情,没用的事情:订单页改版、概况页改版;有用的事情:支撑国内信用卡支付、10%优惠、查找优化;效果未知的事情:着陆页优化。最近读苏杰的《淘宝十年产品事》,这本书把电商产品层面的各个方面都点到了。我也

[核心提示] 这 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?在这个方面做得比较好。比如,查找素坤逸大街(详细的我记不住了,随意写一个说明下意思)的酒店,掩盖区域远大于真实的行政区划,因为 Booking 知道,有条快轨穿过这个手工画出来的区域,核心区住宿价格贵重,可是只需有快轨,我住远一点也行呀。但这个问题太杂乱了,也需要兄弟部门、很多数据/算法的支撑,所以到我离职之前国际酒店也没有做。

着陆页优化

这个实际上是我们当时的事务主管提出来的(对,他很有 PM Sense 的,第 2、3 个项目都离不开他的支撑),因为电商很多的钱都给了百度,通过查找过来的付费用户当然要最大程度好好保留了。然后我照着 Booking 的城市页“推测”了一下用户意图,觉得假如用户通过百度大查找意图地过来,那 TA 极可能是个不太知道 OTA 网站的初级用户,TA 可能期望的不是各种让人发懵的查找项,而是通知 TA:去这个生疏的海外城市究竟住哪里好呢?这个问题,其实攻略网站有答案,可是十分抵低效,并且和预订流程割裂了,那时分我想,能不能打通这个前后环节?

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

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

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

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

给作者打赏,鼓励TA抓紧创作!

api.qrserver/v1/create-qr-code/?size=300x300&data=