换购复杂的根源
在购物车加购的场景中，超值换购、满赠、免费、超值抢等换购类活动，在整个加购链路中相对复杂，穿插着各种场景，各种关系交织在一起。导致前端、购物车、交易、营销、售后在处理这些场景中全都要考虑对应的场景和关系，使得一个业务方认为简单业务实现起来，遇到各种问题，这些问题包含
- 普通商品与换购品加购、展示、计算逻辑交叉
- 普通商品与换购商品共享库存
- 门槛商品与换购商品参与多个活动要叠加处理
- 加购与交易链路中，以营销门槛商品与换购商品标签来做逻辑判断
这几个问题并不是逻辑走不通，而是逻辑交织在一起，引发系统在处理逻辑上考虑的点太多。最终在用户体验上是个极其糟糕的体验，复杂程度在业务、产品、开发、测试环境是指数级增长。对用户而言，这么复杂的业务，带来的体验一定是莫名其妙。在公司层面，不仅仅是研发成本高居不下，运营也是会产生一堆问题，而且还伤害了用户体验，是个双输的结果。
如何有效的解决这些问题，可以从以下几个面思考
理清楚换购特价商品活动底层逻辑是什么
换购特价商品条件是有一些门槛商品，当用户加购了这些门槛商品后，才能有资格购买/赠送特价的商品。
营销工具场景名词统一
| 营销类型 | 子域类型 | 子域再细分（圈人、圈店、圈品，计算优惠方式不一致导致的各种命名） |
|---|---|---|
| 优惠券 | 券是给商品减价，需要用户领取才能有效 | |
| 单品券 | ||
| 单品优惠券 | ||
| 单品折扣券 | ||
| 单品定价券 | ||
| 多品券 | ||
| 品类券 | ||
| 全场券 | ||
| 阶梯券 | ||
| 时间阶梯券 | ||
| 兴币 | ||
| 店铺多品优惠券 | ||
| 优惠价（促销） | 价是给商品减价，不需要用户领取 | |
| 单品促销 | ||
| 单品促销 | ||
| 单品折扣 | ||
| 新人价 | ||
| 组合套餐 | ||
| 多品促销 | ||
| 满减促销 | ||
| 满件促销 | ||
| 新人促销 | ||
| 会场促销 | ||
| 换购（特价商品） | 特价商品是满足了前置条件后，才能享受的特价商品 | |
| 换购 | 需要用户有加购动作的特价商品 | |
| 超值换购 | ||
| 超值抢 | ||
| 免费菜 | ||
| 首件优惠 | ||
| 满赠 | 系统算出自动加购的特价商品 | |
| 满元 | ||
| 每满元 | ||
| 满件 | ||
| 每满件 | ||
| 余额 | 余额 | |
| 买菜金 | ||
| 积分 | ||
| 积分 | ||
| 小兴兴 |
梳理换购场景
换购场景条件和结果
- 门槛商品
- 换购商品
- 活动类型
| 场景 | 活动 | 门槛商品 | 赠品/换购品 | 预期结果 |
|---|---|---|---|---|
| 同一类型活动 | 活动A | 门槛A | 赠品B | 门槛A，赠品B |
| 活动B | 门槛A，门槛B | 赠品B | 门槛A，门槛B，赠品B | |
| 活动C | 门槛A，门槛B | 赠品A，赠品B | 门槛A，赠品A，门槛B，赠品B | |
| 不同类型活动 | 活动D | 门槛A | 赠品C | 门槛A，赠品C |
| 活动D，活动A | 门槛A | 赠品C | 门槛A，赠品B、赠品C | |
| 活动D，活动B | 门槛A，门槛B | 赠品C | 门槛A，门槛B、赠品B、赠品C | |
| 活动E | 门槛B | 赠品A | 门槛B，赠品A | |
| 活动E，活动A | 门槛A，门槛B | 赠品A，赠品B | 门槛A，赠品A，门槛B，赠品B | |
| 活动F | 门槛A | 赠品B | 门槛A，赠品A | |
| 活动F，活动A | 门槛A | 赠品B | 门槛A，赠品B |
场景已经梳理出来了，可以看到，当出现又买又赠的情况时，门槛品A需要与赠品A区分出来。理论上，这些场景支持起来也容易，接下来，再列些场景，在真实的购物车下单场景中，会有什么问题
- 【活动F，活动A】场景中，赠品B有多个子单，在用户视角，为啥同一个品有2个子单
- 每满赠场景中，如果每加购一个门槛商品A送2个赠品B，当A加购到10时，就会有20个赠品B，在售后不能拆单情况下，就会有20个赠品B的子单，用户体验是莫名奇妙的
通过梳理，再回顾上面的问题
| 问题 | 结论 |
|---|---|
| 普通商品与换购品加购、展示、计算逻辑交叉 | 普通商品与换购商品通过商品上打标签来解决，在加购和展示的时候是分开处理，计算也是各自活动对应的门槛商品算出换购品，没有交叉 |
| 普通商品与换购商品共享库存 | 又买又赠场景确实复杂了，因为公司层面上并未规划赠品库，目前只能通过商品打标的方式区分出加购占用的门槛商品库存和达到门槛后算出的赠品库存数来做这个事 |
| 门槛商品与换购商品参与多个活动要叠加处理 | 目前处理方式就是各自活动算各自的，相互之间不影响，在算赠品库存时，需要统一处理，这是难点且容易出问题的点 |
| 加购与交易链路中，以营销门槛商品与换购商品标签来做逻辑判断 | 早期的超值抢是单独的标签，后面的换购类活动是统一的标签，导致用标签去判断会有误差。通过ticketTypeNo来判断能解决根本问题 |
行业内的买赠场景
行业内部分案例，换购特价商品活动是一种购物车行为，需要在购物车中实现，其中换购的商品是一种特殊的商品，这种商品有自己单独的库存。加购时，如果达到换购标准，将直接推出赠品或换购品
此方案在我们这边方案不可行的几个争论点
- 购物车每次加购时，推出的赠品，在提交订单的时候是没法校验赠品的可靠性的
- 赠品的价格谁来定，这部分钱谁来出，购物车是没有办法承接这部分能力的
以上观点也是争论的焦点，换个思路想，也许这几个点并不成立
- 赠品可靠性是由订单自己判断，如果赠品本身是个单独的商品，那赠品在订单中有自己的一套体系
- 赠品如果是单独的商品，那价格就是本身售卖的价格，至于赠品还参不参与多品或是余额优惠，这种处理方式应该属于商品本身决定的
结束语
换购类活动复杂的原因，个人理解，有几个原因
- 平台并没有建立个特价商品库专门管理这些特价品
- 在又买又赠的场景中，没有管理好业务预期，即商品不能又买又赠，业务是不关心你怎么实现的
- 售后不支持部分商品售后也是系统复杂的根源之一
- 业务方的用户体验与系统研发成本存在冲突时，采用拆单的方式让系统兜底
