首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

分区定价:座位上玩转“精细化运营”

分区定价就是将同一个场次的座位分割成不同的区域,以不同的价格进行售卖。不同的座位,不同的价格,在上座率和价格之间求得一个平衡,帮助影院实现收入的最大化。同时,通过异业合作或者绑定会员权益等手段,将权益与座位“对号入座”,实现更加精细化的运营策略。

一、技术挑战-不仅仅是改个价格

  1. “同场同价”-在线选座系统的地基

分区定价要想落地,对于技术来说,并非是改个价格那么简单。

自 2010 年,电影行业出现在线选座业务以来,场次都是定价的最小粒度,影院会根据影厅及放映影片、放映时间等对整个场次的座位进行统一定价,这就是所谓“同场同价”。这个思维定势一直贯穿在在线选座系统的设计实现和升级过程中。在线选座系统的基础数据、交易、网关、营销等核心服务模块,都是基于上述思路进行搭建。

发展到今天,在线选座的业务绝非仅仅是锁座-下单-出票那么简单,如果说 2010 年的系统规模是一栋平房,那如今的规模可以称得上是 500 层的高楼了,那么要改动从系统搭建初期就已定下的规则,就如同重新打造这幢高楼的地基一般,这个挑战可想而知。

  1. 怎么做分区定价,不同系统商有不同的说法

淘票票作为领先的观影购票平台,中国电影市场的很大一部分票房是由淘票票的用户贡献的。然而,淘票票并非电影票的最终出票者,影院才是。淘票票通过对接影院安装的具有售票资质的售票系统,完成出票。

目前,具有售票资质的系统商有七家,如凤凰云智、佳影、鼎新等,在系统商的基础上,还有搭建自己售票能力的电商,如大地、万达等等。上述提到的系统商加电商(下文统称合作商),代表全国近万家影院,定义了影院本地售票系统的接口协议和标准。对于分区定价,他们接口层面有不同的诠释。这就为我们带来了第二个挑战,如何适配众多结构不一的分区定价接口。

  1. 如何快速响应?

时间是个永恒的话题。如何在较短的时间内,面对较大的技术复杂性,去支撑业务的急速变化,这也是我们在实现分区定价过程中遇到的问题。

二、方案-控边界,以不变应万变

  1. 思路

我们从业务建模出发,构建问题空间模型,然后落实到系统上,逐个击破,用系统建模的方式产出解决方案模型,最后用技术手段实现。根据第二章节的阐述,我们抽象出分区定价的两个核心问题:

1)售票的定价维度从场次精确到座位;

2)适配各个合作商不同的分区定价接口。

按照领域建模的沉淀内聚的原则,尽量将变更收敛控制在相关的业务域内。因此接下来我们针对上述两个问题进行抽解、推理:

a)将座位的定价维度精确到座位,分区定价,核心就是价格,价格属性是贯穿整个服务集群的重要属性。基础数据、交易、营销甚至网关系统都依赖价格。然而价格本身并不是一个独立的模型,而是商品模型的一个属性,这里的商品模型也可以认为是场次或者排期模型。基础数据、交易、营销等各个业务域所依赖的是商品模型,并非价格。一个普通场次对应一个商品,而对分区定价场次来说,可能一个场次可能对应多个商品。因此针对这个问题我们的解决思路是:抽象分区定价数据到商品模型,交易、营销等模块依赖商品中的价格属性去实现收单、交易履行等模块,尽量不感知分区细节逻辑;

b)适配各个合作商的分区定价接口,我们的原则是尽量减少其对上层业务的侵入,将其差异屏蔽到底层模块,并对上层提供统一的接口。虽然各个合作商提供的分区定价服务有所差异,但是基本上可以抽象为排期拉取、锁座、解锁座位、出票等模块,而这些底层模块与上层的交互是统一且确定的。因此针对这个问题我们的解决思路是:网关域适配个合作商的分区定价接口,组装统一结构的基础数据,暴露统一标准的锁座、出票等服务,将分区定价的基础服务能力沉淀内聚到网关层。

  1. 架构与实现

综上所述,淘票票对于分区定价的实现方式可总结为以下几点:

1)网关层沉淀封装排期拉取、座位图拉取、锁座、出票、解锁座位等能力,并对外暴露统一标准的基础服务;

2)抽象分区定价的数据到商品及排期模型中,对外提供统一结构的数据模型;

3)上层模块基于底层的基础数据和服务,以通用逻辑进行适配,尽量减少对上层业务的侵入。

具体如下图所示:

  1. 最终答卷

通过上述的解决方案,淘票票在较短的时间内完成了对分区定价业务的支撑,覆盖了行业内多数合作商和影院,同时系统具备一定的可扩展性和复用性,能够以较低成本实现合作商的对接。

四、思考

  1. 快速的业务变化,如何应对,并沉淀技术能力?

快速变化是互联网行业一个无法回避的问题,由于技术人员距离业务前线相对较远,在应对过程中难免显得被动和疲倦。“面向复制-粘贴的编程模式”“先 run 起来”“赶一下进度,后面再重构”、“必须马上上线”等等这些传统应对方式就会大显身手。然而,这些手段纵然能够“快速”支撑业务,也造成了一些恶果。其一,代码的可复用性和可扩展性极差;其二,技术债高垒,影响开发效率,增加变更风险,降低技术竞争力,甚至反过来影响业务和团队。在快速交付的前提下,在分区定价项目的实践过程中,我们总结出以下几点经验:

1)规范技术债的管理机制,对于需要优化的模块,在项目上线之初,就要确定迭代计划。这是最简单却很容易见效的手段;

2)定位核心变更,并将核心模块收敛到尽量少的业务域中,沉淀能力,便于统一管理、复用和扩展。比如在分区定价架构设计中,我们把核心模块落地在基础数据域和网关域,在不影响业务交付的前提下,也使得系统具备一定的扩展和复用能力;

3)拉进业务距离,尽可能多的理解业务诉求、未来规划等等,在设计阶段,把这些信息带入思考,能够使我们在面对变化时更加从容。

  1. 业务技术,做业务还是做技术,技术性体现在哪里?

在业务开发的角色上,面对纷繁的业务需求,很多人会产生困惑,到底是在做技术,还是在做业务,其技术含量体现在哪里?

通过上文所述,一些业务需求的复杂性未必就逊色于底层技术。我们产生困惑的原因,更多的还是面对的问题不一样。业务技术面对的问题变化更快、领域横向上更广;底层技术面对的问题更加稳定,领域纵向上更加深入,但是大家解决问题的能力是共通的,比如编程能力、抽象建模能力、结构化思维能力、落地能力等等。

因此业务开发并不简单,只是大家想“简单”了,或者说在用“简单”的方式做业务开发。我们认为,尊重业务需求,夯实编程、抽象建模、落地等能力,并在项目实践中充分思考和应用,业务一样可以做的很“技术”。

作者简介

阿里文娱开发工程师 暮平

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/V8txAR9UyxUOxebB06Vw
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券