业务介绍
探探的主要盈利方式为会员售卖， 目前在售的会员有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的变现效率。深度模型帮助业务实现了以下两点
- 购买意愿的筛选， 哪些人群会有会员的购买意愿， 哪些人群没有
- 购买能力的筛选， 哪些人群是高净值用户， 可以获取更高的客单价， 哪些人群通过低价能撬动转化。
系统不足
更多是偏向于后端的抽象， 客户端的开发成本并没有降低。 如果配合一套客户端的描述方案或者动态化策略， 可能会有更大的收益。 因为端上对于购买弹窗的改动还是比较频繁的。 业务上收益最大化的方案是购买弹窗弱化续费、弱化总价的概念突出单价， 但由于监管风险的存在，需要进一步调整 以一个相对对收入影响比较小的方案突出续费及总价 。 这块客户端的动态化做的探索偏少。