业务介绍
探探的主要盈利方式为会员售卖, 目前在售的会员有VIP、SVIP 及探币。 但在探探的迭代过程中我们测试过多种多样形式的会员打包方案、测试过多种档位的会员售卖形式 如 1, 3, 6, 12个月的包月, 各种档位的探探币价值, 测试过多种价格的会员售卖。
为了帮助业务实现售卖体系的敏捷测试, 我们搭建了一套支持千人千面分发的商品体系。 该系统的主要难点在于如何实现商品的灵活可配置,将商品测试的研发成本降到最低。
为此我们抽象了一套试用于探探平台的商品领域模型, 并配套的增加了商品管理后台, 规则引擎 方便敏捷的管理
技术实现
系统架构
模型抽象
商品体系的领域模型如下:
- productCategory: 我们定义成货架,客户端每个购买弹窗我们定义成一个货架, 这个货架下一般会展示3-6个同类的商品, 以安卓端的SVIP为例, 要展示VIP 1个月、3个月、6个月的自动及非自动续费商品。
- skuRule: 货架选取一套商品的规则, 一个货架下有多条规则,每条规则下会关联一套商品, 系统会选取当前用户命中的规则的那套商品返回给客户端
- Product 描述的是一种类型的商品及对应的特权
- Item SKU的概念 同一个Product下有多个Item, 每个Item对应不同的单价
用户获取可购买商品列表流程
- 前提:因为商品的数量不多, 因此上述的商品信息会在每次启动的时候加载到内存中, 并定期刷新
- 获取流程:
- 加载系统所有生效的货架ProductCategory及货架下的SKU规则
- 运行对应的SKU规则, 找到权重最高的命中规则,
- 返回该规则下的相应商品
用户购买权限校验
我们采用服务端签名的方式来完成用户购买资格的校验, 每次下发商品的时候会对每个商品用uid+itemId+时间戳 来生成一个服务端签名, 创建订单的时候需要带着这个签名返回才能购买成功,
规则引擎
为了实现sku规则的灵活可配置, 我们基于LISP表达式实现了一套规则引擎。 后台提交相应的规则到DB, 程序运行时加载相应的规则并执行。
规则引擎的实现细节
规则引擎的表达使用的是前缀表达式, 执行过程
- 编译阶段,
- 语法解析成AST树,
- 针对AST树执行各种优化
- Costant Folding 编译阶段 折叠常量计算, 算数计算会前置优化掉
- 减少嵌套层次
- 重排序 优先计算代价小的操作
- 将优化后的结果压入堆栈, 这里我们会使用后缀表达式的方式入栈, 以减少频繁的push
- 执行阶段 后缀表达式的方式执行。
结合用户画像及深度模型的智能营销
规则引擎提供了一套个性化下发商品的框架, 但是针对于哪些人群去下发什么样的价格,展示什么样档位的商品,这块还需要依赖更多精细化运营的方式。
这块我们通过深度模型学习的方式预测用户购买的意愿及能力, 通过规则引擎与深度模型相结合取的了不错的业务效果。
系统的难点及解决方案
讨论
系统优势
- 通过合理的业务模型抽象, 实现了系统的灵活配置, 减少了开发的成本,使得技术同学可以从繁杂的业务细节实现中剥离出来,更关注系统及业务效率
- 与深度模型的结合,真正实现了千人千面的精细化营销, 进一步提升了VAS的变现效率。深度模型帮助业务实现了以下两点
- 购买意愿的筛选, 哪些人群会有会员的购买意愿, 哪些人群没有
- 购买能力的筛选, 哪些人群是高净值用户, 可以获取更高的客单价, 哪些人群通过低价能撬动转化。
系统不足
更多是偏向于后端的抽象, 客户端的开发成本并没有降低。 如果配合一套客户端的描述方案或者动态化策略, 可能会有更大的收益。 因为端上对于购买弹窗的改动还是比较频繁的。 业务上收益最大化的方案是购买弹窗弱化续费、弱化总价的概念突出单价, 但由于监管风险的存在,需要进一步调整 以一个相对对收入影响比较小的方案突出续费及总价 。 这块客户端的动态化做的探索偏少。