作为房东,你该向房客收多少钱?作为租住民宿的房客,该向房东付多少钱?一次计划中的度假,或一场说走就走的旅行,你愿意为哪个付更多的钱?

回答这些问题并不容易。而我们发现,这个问题已经成为公司的“生死问题”——Airbnb,是一家在可用的房间、公寓和独立住宅与潜在房客之间牵线搭桥的公司。

用户在挂房子上网的时候,会在填写定价区间时卡住。很多人都会去查看邻居的收费,并选择相近的价格;其间,他们会在浏览器中打开大量的页面,试图找到与自己类似的房源。

有人在注册前就有一个目标:为了赚点外快贴补房贷或支付度假开支。所以他们在定价时只考虑这个目标,全然不顾房真正的市场价位。

更糟糕的是,还有一些人干脆填到价格表的时候就放弃了,因为他们也不知道该定多少价格。

Airbnb需要为人们提供更好的工具——一个自动的定价信息源帮助房东做决定。(编者按:事实上这成为这家公司的核心竞争力)也正因此,我们从2012年开始构建定价工具,并持之以恒地加以完善。今年6月,我们发布了最新版本。

我们用动态定价,根据市场动态价格提供每日价格建议。进一步,我们希望机器不仅可以从自身经验中学习,必要时还可以借鉴一点人类直觉。

在网络世界中,很多公司都使用算法来设定或建议价格。就比如eBay,它告诉你同类产品的售价,不管卖家和买家身处何地,交易时间是今天或下周,这些都对价格没有影响。

在打车公司Uber和Lyft的定价会受到地域和时间的影响——但这两家公司干脆直接设定价格;用户对价格没有选择权,也不需要定价透明度。

Airbnb则面临一个非同寻常的复杂问题。网站上一百多万个房源,个个都有不同的地址、面积和装修情况。

有的房东愿意担当门房、厨师或导游,有的不愿意。各类事件又让情况进一步复杂化,有普通的季节性天气变化,也有特殊的大型本地活动等。如何定价?

三年前,我们开始构建一款为潜在房东提供定价建议的工具,它以一个房源的最重要特征为基础,如房间数、床数、附近房源以及停车位甚至游泳池等特定设施。这款工具于2013年投放使用,基本运行良好,但也有一定的局限性。

例如,定价算法是一成不变的。打比方说,我们给俄勒冈州波特兰的珍珠区(Pearl District)设定一条边界,或者设定河边的房源永远比距河一个街区外的房源贵上一倍,那么算法就会永远应用这些指标,除非我们手动加以修改。我们的定价工具也不是动态的——定价建议不会根据订房时间和市场紧俏程度作出调整。



(全球视野:Airbnb的定价工具在很多国家经手各类住宿,包括图中伦敦的一间毡房、爱尔兰的一座城堡和夏威夷的一个树屋。7月份进行的一场快速抽样调查显示,城堡内一间双人房的定价为147美元,可住四人的两床毡房定价159美元,可住两人的树屋定价275美元。)

自2014年中期以来,我们就试图改变这一局面。我们希望构建一款能从错误中学习、在与用户交互中不断改进的工具。我们也希望这款工具能视市场需求而作出调整,必要时调低定价以避免房间空置,需求上涨时则调高价格。

我们逐渐开始摸着门道,并于6月份向房东们开放这一工具。我们将在下文,介绍这些工具的演化历程、如今的运作方式,以及为什么说我们的工具Aerosolve的用武之地将不仅限于出租民宿的定价。也正因此,我们现将其面向开源社区开放。

想要理解我们所面临的问题有多么复杂,请考虑以下三种情况。

试想上一场世界杯足球赛期间,你住在东道国巴西。世界各地的人们因为这场全球最盛大的足球赛事联合起来,你的家乡将迎来一股巨大的游客潮。你的房子里恰好有个空余的房间,你也想见见其他足球爱好者,顺便赚点外快。

我们的工具要帮你计算出一个价钱,就得考虑这样几个因素。

首先,这是该国几十年一遇的一场盛事,因此Airbnb完全没有历史数据可以参考。其次,每一家酒店都订满了,所以很明显存在巨大的供需失衡。再次,前来观赛的人们已经为门票和国际旅行花了一大笔钱,所以也不怕为住宿再破费一点。

除了房源面积、房间数量和地理位置外,以上都是需要考虑的额外因素。


或者,试想你继承了苏格兰高地的一座城堡,为了支付清理护城河、运营酒厂和喂养猎鹰的开销,你决定把角楼做成“住宿加早餐”旅馆。

不同于上述世界杯情形,这一次你有附近城堡的一些对比数据可以参考。其中一些数据可能跨越多年时间,提供旅游淡旺季层面的信息。而且,从该区域内其他几处可选住宿来看,目前的游客房源供需相对平衡。

然而,它是苏格兰唯一一座具有双护城河这一独特设计的城堡。至于这一独具特色的罕见设计价值几何,系统又该如何计算呢?


最后一个例子,试想你在巴黎拥有一套典型的两卧公寓。8月份你要南下去蒙彼利埃度假数周。

同等房源有很多,因此定价相对简单。但比如说,你第一次挂单就收到大量租房请求,于是你决定逐渐提高定价,以实现收入最大化。

但——万一价钱太高,或者拖到离预订日期太近,最终错失良机就不好了。或者相反:以较低的价格接受了第一个询价的顾客,结果好几个月都后悔当初没能大胆一点。

我们如何才能帮助房东获得更加全面的信息?

我们想要构建一款简单易用的工具,为房东在定价时提供有益的信息,同时列明各条定价建议的原因。

工具整体架构的构思简单得出人意料:当新房东开始在Airbnb网站添加房源时,他会看到该区域内具有相同或类似属性的其他房源,系统会找到那些成功预订出去的房源,考虑需求与淡旺季因素,并以中位价为基础,给出一个定价建议。

但难点在于如何确定确切的房源关键属性。

没有哪两个房源在设计或布局上是完全相同的,各种房源分布在城市的每一个角落,而且不仅仅有公寓或独立住宅,还有城堡和雪屋。

我们决定,这款工具在定价时采用三大类数据:相似性、时间远近和地理位置。

对于数据相似性,我们从一个房源的已知可量化属性着手,看哪个属性与房客心理价位相关度最高。最后得出是这样几个属性:可住宿人数,整租还是单间,房产类型(公寓、城堡、毡房),以及评论数。

最出人意料的一项也许要属评论数了。原来,人们是愿意为评论数多的房产支付一笔溢价的。虽然亚马逊(Amazon)和eBay等都靠评论来帮助用户选择商品或卖家,至于评论数是否对价格造成重大应影响,我们就不甚清楚了。对我们而言,一个房源哪怕只有一条评论,也比没有评论强多了。

我们将时间远近纳入考量,是因为市场波动频繁,尤其是在旅游行业。除此之外,旅游业季节性极强,在考察行情时,要么看当天,要么看去年同期,反而上个月的行情可能并不是很具参考价值。

在像伦敦或巴黎等高度成熟的市场,获取此类市场数据就很简便了——网站上可供对照的已预订房源成千上万。

对新兴市场和新市场,Airbnb按照规模大小、旅游业发达程度和发展阶段进行归类。这样一来,我们对房源的对比就不仅仅依据房源所在城市,而且还可参照拥有类似特点的其他市场。

所以,如果一名日本房东在Airbnb上挂出了京都最早的一批公寓之一,我们就可能会参照东京或冈山最早期的Airbnb房源数据,抑或是参照阿姆斯特丹,那里的Airbnb市场相对较为成熟,但规模和旅游业发达程度都与京都相近。

最后,我们还需要考虑地理位置,这个方面我们跟酒店大不相同。酒店通常聚集在几个主要区位,而我们在城市每一个角落几乎都有房源。

早期版本的算法以房源为中心,划出不断扩大的同心圆,考虑不同半径同心圆内的类似房产。这个方法奏效了一段时间,直到我们发现一个重大缺陷。

设想公寓在巴黎。如果房源地处中心地段,比如说就在卢浮宫和杜乐丽花园(Jardin des Tuileries)以南的新桥(Pont Neuf),那么我们的同心圆很快就开始囊括河两岸迥异的居民区。在巴黎,尽管塞纳河两岸都比较安全,但对这两个相隔仅百米的地区,人们愿意支付的住宿费是相当不同的。

其他城市的分界甚至更加明显。比如在伦敦,备受推崇的格林威治区的价位可以达到伦敦码头区的两倍,而两地只隔着一条泰晤士河。

价格波动:季节性需求变化和本地事件会导致价格剧烈波动。在德州奥斯汀(如图所示),在西南偏南音乐节(South by Southwest;SXSW)和奥斯汀城市极限音乐节(Austin City Limits)期间,价格就出现暴涨。

于是,我们找了一名制图师,把世界各地顶级城市每一个居民区的边界画了出来。这一信息给出了极度精确且相关度极高的地理空间界限,使我们得以围绕主要地理和结构特征,如河流、公路和交通站点等,精确划分房源集群

举例而言,10月份的第一周,伦敦泰晤士河格林威治这边一个基本双人单间的定价建议是每晚130美元;河对岸类似属性的房间,定价建议则为60美元一晚。

我们对自己的算法非常满意,不过那是在修复一个重大漏洞之后。这个漏洞导致系统对大量不同特点的新房源给出了99美元的定价建议。这个漏洞并没有存在太长时间,也没有出现在所有地区,但我们意识到,一旦发生,它可能导致人们对这些定价工具的效用产生疑问。

我们不断改善算法,直到可以将数千个不同的因素纳入考量,并能对地理位置作出详细的区分。

但这款工具仍有两个弱点:它给出的建议是静态的——它能理解本地事件和旅游高峰期,所以可在一年不同时间内对同一房源给出不同的定价建议。但不会像航空公司那样,因为日期的临近而修改定价;不会在预订清淡时降价、市场走俏时提价。

而工具本身也是静态的。建议的确会随着可用历史数据的增多而日渐改善,但算法本身并不会自我完善。

去年夏天,我们启动了一个项目来解决这两方面的问题。

动态定价方面我们的目标是,对于房源可供预订的未来每一个日期,每天都给房东一个新的定价建议。

动态定价并不是新鲜事。航空公司几十年前就开始用它来调整价格——通常是实时调整,以期保障满座率和每座营收最大化。酒店也纷纷效仿,由于兼并整合使大型连锁愈加庞大,业务数据也越来越多,在酒店营销搬到线上之后,酒店连锁可以实现每天多次变价。

因此,及至我们有了涵盖大量房源、纵跨数年的历史数据可供挖掘时,投资于动态定价对我们而言就变得相当有意义,尽管它需要更多的计算资源。

让算法逐步自我提升则相对更有难度,我们选择了一个名为“分类器”的机器学习模型它依据房源的所有属性和现行市场需求,试图将房源归为“会被预定”和“不会被预定”两类

系统在计算定价建议时要参照数百项属性,如是否含早餐,以及房客是否享有专用浴室等。随后,我们开始对系统进行训练,让它将定价建议与最终结果进行比对。

查验房源在某个特定价位能否预订出去,可以帮助系统校准定价建议,并估算价位被接受的机率。房东自然可以选择与定价建议存在出入的价格,我们的系统也会相应调整该价格被接受的预估可能性。

之后,它会回过头来检查该房源的最终预订情况,并据此调整未来的结论建议。

(你会是我的邻居吗?算法按历史定价数据将房产分组,形成详细的微型居民区,如上面的伦敦地图所示。)

这时就轮到“学习”过程登场了。

掌握了自身建议的成功性这一知识,我们的系统便开始调整一个房源各个不同特征的权重——它从特定房产那里收到的“信号”。

我们设置了一些假定,如地理位置极为重要,但热水浴缸配备与否就没那么大关系了。之前定价系统的一些特定属性被保留下来,但也有新的属性加入。一些新信号,如距离订房最截止日还有多少天”等,跟我们的动态定价能力相关。还有一些新信号的加入纯粹是因为对历史数据的分析显示,它们存在重要性。

例如,有些照片更能吸引预订。总体趋势可能会出乎你的意料——虽然专业摄影师可能会青睐的那种时尚、敞亮的房间,但这类房间所能吸引的潜在房客还不到那种暖色调温馨卧房的一半。

假以时日,我们期待对这些信号的持续自动校准能使我们的定价建议得到完善。

我们还可以介入并影响权重。系统会列出每个定价建议所考虑的因素及它们的权重,我们有专人观测这些数据。如果觉得有什么因素未得到充分体现,我们会在模型中手动加入新信号。

例如我们知道,西雅图一个不配宽带Wi-Fi的房源在任何价位都不太可能预订出去,这就不需要系统再去求得。我们自己就能调整这个指标。

系统还会持续调整我们的地图,以反映居民区界限的变动。因此,就以波特兰为例,我们并不用当地地图来确定桑尼赛德(Sunnyside)和里士满(Richmond)在哪里分界,而只需依靠一座城市内的预订情况和价差来划定此类界线。

这一做法也使我们发现了之前没有意识到的微型居民居。这种区域内可能存在大量热门房源,本身却不是以标准的居民区划分呈现在地图上,或者,某个本地特色会令一个大型居民区中的一小块区域特受欢迎。

到目前为止,我们已经使用这些工具创立了一个会创作点彩画的系统。我们急切盼望其他行业创意工程师开始使用它。


翻译 / 雁行

Source: IEEE Spectrum

  • 共享经济
  • Airbnb
  • 算法

造就评论0

造就  发现创造力