促销作为微盟新商业操作系统 WOS 的核心领域,深度介入交易流程,推动交易的达成。原有促销活动采用烟囱式建设模式,业务和促销规则耦合严重,从而导致复用性低、扩展性弱,支撑新玩法成本高昂,集团内部多条产品线存在大量重复建设。随着促销玩法的发展,系统维护已经变得力不从心,因此决定搭建促销中台体系,通过一系列抽象及底层促销模型打磨,沉淀多种促销活动玩法,支撑业务方快速构建不同玩法的促销活动。不仅要满足内部各产品线场景,同时支持对外部租户开放促销搭建能力。促销活动本质上是满足设定的条件规则,给予用户优惠奖励的行为。其深度参与交易流程,主要目的是为了达成交易,通过凑单、复购拉动销售的活动玩法。例如满减折、满赠、加价购、X件Y折、满减邮、限时折扣等。促销活动玩法多变复杂,目前已经包含打折、减钱、一口价、减邮、赠品等超过12种玩法。当前促销活动采用烟囱式建设模式,适合前期快速抢占市场,随着业务的快速发展,公司内部各产品线促销活动已经突破50种,其弊端已经开始凸显。- 烟囱式系统强依赖于活动类型,存在大量隐式产品约定,开发硬编码实现。比如某种促销活动包含哪些要素、限购纬度,开发则通过硬编码实现。
- 传统烟囱式建设模式将业务和玩法规则混杂在一起,使得玩法规则和业务耦合极强,进而导致系统复用性低,可扩展性弱。
- 打通烟囱式系统间交互的集成和协作成本高昂,上游系统希望以通用模型和接口交互促销系统,屏蔽不同促销活动间的结构差异。
- 重复功能建设带来资源和成本浪费。不同产品线存在大量重复建设,但无法复用。新增促销玩法成本高昂,无法快速支持促销业务需求和创新业务。
- 促销底层模型抽象及复用:促销活动主要的差异是优惠规则,如何抽象出统一的优惠规则模型,利用优惠规则模型将优惠行为显式定义清楚,抽象出明确的优惠元数据,支撑优惠能力的复用。
- 弱化业务活动类型,由行为进行流程驱动:微盟电商体系强依赖业务活动类型,根据业务活动类型处理优先级、互斥等逻辑。而对于促销活动后端来说,每种活动的形态由产品隐式约定,只能根据业务活动类型来明确活动形态,比如该类活动支持那些优惠类型、限购纬度等,产品隐式约定存在极大的业务模糊性。因此考虑在促销中台内部排除依赖业务活动类型,而是由促销活动行为进行流程驱动。
- 具备支持混合优惠结果的通用促销能力:支持满足门槛后享受多种优惠行为,比如满100元打8折加包邮并送优惠券、积分等,更加灵活支撑促销活动玩法形态。
- 促销要素组件化:通用促销要素的组件化设计,显式定义组件结构,可以被促销中台后端识别并解析,且可由促销组件行为影响流程驱动。
- 通用泛化设计:不局限于某一产品线或某个行业,需要进行泛化设计,支持扩充到其它业务线及行业的能力。
- 中台维护方向由具体促销业务转向促销底层能力建设:促销中台维护的重点转向促销底层原子能力、流程单元能力、编排工作流能力上转变。
促销的核心是优惠规则,通过走查各业务线抽象出促销规则模型,依赖各种条件能力和结果能力可灵活组成玩法繁多的促销活动。随着中台优惠条件及结果能力的扩充,中台承载范围将指数级增加,所有的能力都是通用且易复用的,因为底层设计中并没有将优惠能力强绑定业务或产品线。从而实现一次建设,可多次复用。
5.2 优惠规则 Schema 设计
当规则的核心模型结构抽象出来后,我们就需要考虑如何将优惠规则组织约束起来。区别于旧版设计强依赖于活动类型,某个活动类型优惠规则具有那些要素由产品隐式约定,开发硬编码实现。存在很大局限性,也限制了其扩展性。因此我们提出了优惠规则 Schema 概念。通过 Schema 将优惠规则显式明确定义,所有涉及到优惠规则形态的地方都会利用优惠规则 Schema 进行处理。优惠规则 Schema 需要将规则形态明确约束清楚,结合微盟产品形态,来抽象需要定义的约束项,总的限制约束项很多,下面仅简要罗列几个考量纬度:5.3促销要素组件化
首先来看微盟商城产品中最常用的限时折扣活动配置页面,囊括了众多促销要素,其中包含大量的强业务属性的要素,像活动时间影响活动的生命周期,且周期时间存在复杂的结构;适用场所可以通过商家组织结构前端组件任意选择各级场所节点,且不同产品版本支持的节点类型不同,比如零售版支持店铺、区域、门店节点类型,商圈版支持商场、楼层、门店节点类型。
可以将每个促销要素都抽象为一个组件,通过定义组件 key 和组件约束结构来显式描述组件形态,从组件要素的结构可以划分为:- 单选类型组件:比如是否展示划线价,需要定义组件候选项,且只允许单选。
- 多选类型组件:比如可用活动、可用抵扣,需要定义组件候选项,支持多选。
- 自定义类型组件:比如优惠规则 Schema,需自定义复杂组件约束结构。
此时构造一个促销活动产品就变成从组件物料库中挑选需要的组件,并定义每个组件的约束值。5.4 七巧板活动模板配置工具
上述模块已经实现对核心的优惠规则及促销组件进行显式配置,此时需要有一个管理工具动态组合各种组件,设置组件形态,支持设计页面展示样式,搭建出一个具体的促销活动产品。七巧板活动模板配置工具应运而生,希望能够和七巧板一样通过几块积木(要素和组件)搭建出种类繁多的促销玩法。促销活动模板包含2部分数据:- 促销活动模板前端页面样式 Schema:动态生成促销活动页面配置信息,确定不同组件的样式,组件候选枚举项等,可在商家后台动态集成。
- 促销活动模板后端 Schema:后端可识别的促销活动模板显式配置数据,促销中台内部流传将完全由后端模板 Schema 来区分不同活动,弱化活动类型的强业务属性。例如在商家后台创建活动时,将利用后端模板约束 Schema 来校验数据的合法性,比如活动允许包含什么优惠行为,允许传递那几个纬度限购类型的数据。
针对大部分组件的变更无需促销中台应用发布,仅需在七巧板活动配置平台编辑模板发布后,即可生效。例如新增组件枚举项,新增优惠结果类型。模板搭建流程:利用抽象出来的促销组件物料可以搭建促销活动模板,促销活动模板包含前端页面样式 Schema 及促销活动后端 Schema。七巧板活动模板配置工具前端需要提供促销组件前端 JS SDK。七巧板活动模板配置工具后端需提供出促销组件前后端数据转换 SDK 并开放模板 Schema 数据查询接口。页面渲染流程:接入方前端通过模板 ID 参数请求七巧板活动模板配置工具后端查询出模板关联促销活动模板前端页面样式 Schema 和促销活动模板后端 Schema 数据,并开放 SPI 扩展点用于业务接入方后端针对模板组件数据进行特殊处理。比如对于商城零售版,不同的登录场所节点适用门店组件形态不一样,如果登录的场所节点是门店,那么需要设置适用门店组件隐藏处理。最后,业务接入方前端利用促销组件前端 JS SDK 解析前端页面样式 Schema 动态渲染出活动配置页面。- 使用七巧板生成页面:业务前端基于促销组件前端 JS SDK 交互业务后端,业务后端通过促销组件前后端数据转换 SDK 将通用中台前端数据转换为标准后端 API 格式数据,之后与促销中台标准 API 交互。
- 使用业务方自有页面:业务前端直接交互业务后端,业务后端将数据转换为促销中台标准 API 格式数据,与促销中台交互。
- 非页面接入:比如商城第三方接入商城 OPEN API,则由商城 OPEN API 将数据转换为促销中台标准 API 格式数据,与促销中台交互。
最终,促销中台执行时,将交互七巧板后端模板 API 获取促销后端模板 Schema 数据,根据 Schema 数据进行流程驱动处理,摆脱强业务含义的活动类型。抽象方向提到的想法最终都是为了实现高度复用,每一项都相互影响、环环相扣,最终实现设计目标:- 优惠规则显式配置化、促销组件显式配置化是为了实现促销活动模板显式配置化,从而实现排除依赖业务活动类型,因为在旧体系里面业务活动类型就是为了区分不同活动的形态而产生的。因此中台内部就可以依靠模板进行流程驱动。
- 抽象出来的促销组件、优惠类型不在局限于某一产品线、行业,从而实现泛化设计。避免不同产品线、行业重复造轮子。
- 根据促销组件、优惠类型进行策略实现各种校验、转换策略,真正实现一次建设多次复用。
- 领域原子能力、流程单元能力的抽象,可以快速支撑编排新工作流,支持复杂多变的业务述求。
而其中流程编排工具极大扩展了促销中台的支撑能力、扩展能力、可插拔能力,因为要实现可编排,需要反推我们抽象领域原子能力、流程单元能力。从而在现有能力无法支撑业务诉求时快速编排出新工作流。下图为一个基于微盟流程编排工具盟链编排出来的促销活动创建工作流样例:比如第一个流程单元:业务活动类型转换模板ID,在促销中台内部已经排除依赖业务活动类型,但是对于微盟电商体系还是强依赖业务活动类型,因此我们抽象了业务活动类型转换模板 ID 流程单元,兼容中台内外部的交互。如果未来外部业务活动类型概念消失,对于促销中台来说仅仅是把该流程单元剔除即可。本文是对微盟 WOS 下玩法灵活的促销活动体系的设计探索,尝试从最本质的角度解决促销中台面临的众多问题。当前已服务微盟集团内部多条产品线近50种促销活动,支撑促销活动诉求的快速灵活搭建。后续也将继续探索更为合理高效的中台体系建设思路。