电商产品 | 再谈促销实现逻辑

电商产品 | 再谈促销实现逻辑

96
菜哥
2017.07.10 16:52* 字数 4047 阅读 2303 评论 5 赞赏 1
webp

京东618大促落下帷幕,伴随着1199亿元的销售业绩令人瞠目,如此庞大的促销活动,是如何做到的?如果一个商品既参与了特价销售、又参与了平台跨万店满减、还参与了店铺内的优惠券减额等等促销活动,那这个商品会不会存在不要钱白送的情况?

当然,你可以认为笔者在杞人忧天,就算亏那也是京东的事情,但是笔者并不是要讨论京东赚了或者亏了多少钱,而是要说这考验的是产品设计者的智慧。

在阅读本文之前,笔者建议你先阅读前一篇文章:“电商促销业务逻辑盘根错节?试试脱离场景从系统计算逻辑上思考” 。在这篇文章中,笔者总结了设计电商促销系统的基本原则:

同类型通过实体进行互斥、不同类型可以相互叠加

如果没有时间看上一篇文章,为更好的理解本文,笔者大致描述这条原则如下:在你设计促销功能时,需要考虑当前促销功能是属于以下哪种促销类型,再使用这条原则通过实体(这里说的实体是商品或者订单)和其他促销功能进行逻辑互斥。

三种促销类型:修改价格类型、修改商品小计金额类型和修改订单金额类型

例如:如果你设计的促销功能是 秒杀,那么这个活动就属于第一种:“修改价格类型” 的促销活动,它需要通过实体(商品)来和 同类型其他促销活动 进行互斥,也就是说:在设计秒杀活动功能时需要考虑到参与秒杀活动的商品不能同时参与其他修改价格类型的促销活动。而,这种类型的促销活动有:拼团、限时折扣、降价拍等等。

以上为背景和回顾,下面正式进入本文内容


就如笔者之前所述:这条原则是没有考虑任何使用场景、完全基于系统计算逻辑总结的规律,但是就连笔者也无法回避电商产品是由运营驱动的残酷现实。这也就决定了,这条原则如果不符合用户使用场景,不能提高运营效率也终将是一个自嗨的结论,没有任何价值可言。那么今天,笔者就将进一步阐述这条原则能否满足实际使用场景的要求。

所谓实际使用场景,无非就是线上和线下两种情况,本文将结合电商购物车这个促销重要载体来对以下五种不同的情况进行逐一分析:

第一种情况:针对线上,如果一个商品能够同时参与两个不同的第一种促销类型,会如何?

第二种情况:针对线上,如果一个商品能够同时参与两个不同的第二种促销类型,会如何?

第三种情况:针对线下,如果一个商品能够同时参与两个不同的第一种促销类型,会如何?

第四种情况:针对线下,如果一个商品能够同时参与两个不同的第二种促销类型,会如何?

如果一个商品同时参与了上述三种促销类型活动,可以吗?

第一种情况

针对线上,如果一个商品能够同时参与两个不同的第一种促销类型,会如何?

常见的第一类促销活动有:拼团/阶梯拼团、团购、秒杀、限时折扣、降价拍等

假如你是产品经理,现在要你设计一个第一种类型促销活动,比如限时折扣。你把玩了各种竞品的前端交互,并开始设计设计自己的限时折扣活动,然而竞品并没有告诉你如果和其他促销冲突时该如何处理,你也没有考虑到如果有其他促销的情况,你的产品也顺利上线了(假设)。好了,运营喵们开心的去策划促销活动,SKU A 先是被一个运营喵参与了秒杀活动,然后另一个运营又选择了这 SKU 参与你设计的限时折扣的活动,结果会如何?

因为同一个SKU 在同一段时间内具备了两个价格(一个秒杀价格,一个折扣价格),这时候系统该选择哪个价格作为这个SKU的价格呢?如果一个用户恰好添加了这个SKU 到购物车,那么购物车的促销怎么展示?画风是这样的,大家感受一下:

webp
同一商品同时参与两个第一种类型促销

很明显,这种可能性即使在线上使用场景下也是不允许发生的,也就是说同一个SKU 不能同时参与第一类促销活动,这是在产品设计之初就需要考虑并告知开发者的。

第二种情况

假如一个SKU 同时参与了两个不同的第二种类型的促销活动,会如何?

我们再来归类一下现在常用的第二类促销活动:指定商品的(品牌、类目、店铺等不同维度)满减、满赠、折扣,N元任选、加价购。

假如一个SKU A既参与了包含SKU A 的 满50减5 活动,又参与了包含SKU A的 99元任选3件 的活动会发生什么呢?

同一商品参与两个第二种类型促销活动

首先,在商品详情页,SKU A 需要标记两个促销活动,对于商品详情页面来说最重要的是提高页面的转化率,过多的促销会不会造成用户犹豫不定?增加用户考虑成本从而降低商详页转化率?

其次,用户即使将SKU A加入了购物车,如何解决同一个SKU的两个以上促销展示问题?不管如何处理,对于第二种促销类型 这个SKU 都只能参与其中一个活动,既然只能参与一个活动,那就必须在所有满足的活动中定一个优先级优先只展示一个给用户,那这个优先级规则又将如何定义?

再者,购物车还需要承担提示用户凑单的重任,也就是说:需要一个确定的促销活动将满足这个活动的所有商品归类到一组提示用户进行凑单,如果一个商品满足多个促销活动可以任意切换,切换之后又需要对切换后的活动商品进行重新组合并再次计算满足的促销条件及凑单金额,这对于系统计算工作量来讲...而且对于用户而言,他们真的不会被购物车同一商品多个促销活动搞懵逼了吗?

基于上述种种考虑,对于第二种类型的促销活动而言,在产品设计时就应做出限制(同一商品不得参与多个第二种类型促销活动)是最明智的选择。

那么,有没有例外? 答案是:有的,比如京东

京东已经把购物车的促销展示做到了极致,更重要的是:它允许同一个SKU参与多个第二种类型促销活动,它是如何处理同一SKU参与多个促销的呢?如下图所示:

同一个 SKU 参与了两种第二类型促销:满减和满赠

如果一个SKU 同时参与了两个第二类促销,提供给用户修改的入口,用户可以自定义选择参与哪个促销,这样处理存在的问题是什么?

1. 数据处理量大,购物车对数据时效性要求极高,用户对购物车商品任意增删改都需要实时计算。同时,如果用户切换商品的促销活动,系统首先需要将切换后同一类型促销活动商品归为一组,再计算本组商品价格与促销活动门槛金额进行比对比做出对应提示,例如:再购多少元满足本优惠。还需要将本组促销活动的其他商品归类到一起,给出凑单入口,并提醒用户去凑单。。。如此巨量的计算任务需要在短时间内做出响应,不是一般的团队能够胜任的。笔者亲测:即使是京东,从满减切换为满赠,购物车页面也等待了两秒多种才完成切换。

2. 用户体验并不佳,从京东的购物车页面可以看到琳琅满目的各种促销条件,任意不同的促销活动商品都会被划分为一组,不同商家的商品会被归类为一组、京东自营的又会与其他商家区分开,一旦用户添加购物车商品过多,会给用户造成很多干扰,笔者问过很多京东的重度用户(包含PLUS会员),当我告诉他们,有些商品下面有个修改的按钮可以改这个商品的促销活动,他们中的大部分人做出的反应都是,啊。。。? 没有注意过啊?

既然是这样,京东为什么还要这样做呢?

所谓:“所有能通过技术解决的问题都不是问题”,所以第一个问题对于京东来讲并不是问题,对于对二个问题,这是产品向运营妥协的结果:一个运营负责不同的店铺、品牌、商品类目,这在平时如果仅仅店铺内促销还行,遇到618这样的大促,平台牵头带领店铺进行跨店铺促销,每个人都希望争取到更多的资源和流量来提高GMV,如果限制一个商品只能参与一个第二类促销,这样不被认可也是情理之中,但是对于大部分电商而言,是否也需要这样处理呢?笔者认为并不可取。

第三种情况/第四种情况

针对线下,如果一个商品能够同时参与两个不同的第一/第二种促销类型,会如何?

既然是线下,我们去实地考察下线下的促销场景就什么都明白了,看下下图:

商场促销

很明显的是:商场促销活动时,会把所有参与同一促销的商品归类到一起,然后插上吊牌:特价xxx,满xx减xx 等等,一个活动就是一个独立的区域不可能一个商品同时存在于两个不同的活动区域的,即使被你看见了,那也是商场工作人员的失误,因为结算时如果你告诉收银员这个商品有多个可以选择的优惠,那么他一定会崩溃的。

第五种情况

一个商品同时参与了上述三种促销类型活动,可以吗?

答案是:逻辑上是没有任何问题的,但是实际场景中并不常见(在业务层面一般不允许这样操作),至少笔者没遇到过这样的好事,如下图所示:

商品同时参与三种类型促销活动

比如:一罐原价200的奶粉,既参与了 特价180 销售,又参与了指定奶粉类型的 满100减10 的活动,还使用了全场通用的 满150减10 的优惠券,最后支付金额为160。

所以

这条原则:

同类型通过实体进行互斥、不同类型可以相互叠加

即使是在实际使用场景中,也仍然具备它的实际价值,笔者再次总结如下:

第一种类型促销:即:商品低价促销,有:拼团/阶梯拼团、团购、秒杀、限时折扣、降价拍等

第二种类型促销:即:商品小计促销,有:指定商品的(品牌、类目、店铺等不同维度)满减、满赠、折扣,N元任选、加价购。

第三种类型促销:即:订单金额促销,有:全场满减、满赠,全场满xx包邮,优惠券等

当你设计促销类产品时,你应该这样做:

首先,你需要先和 架构师/项目经理 从整体上定义好各种促销活动之间的关系(如上所述),搭好架构;

其次,当你实际设计促销产品时,需要判断你设计的促销产品属于哪种类型,归为同一类型的促销活动需要通过商品进行互斥;

例如:同为针对商品的促销,不能同时对同一个商品进行满减和满赠;

针对订单的促销,需要定义优先级,例如:全场满减的促销计算应该在全场满x包邮之前。也就是说计算包邮的金额应该是所有促销计算完成后的金额,也就是用户实付金额。

最后,不同类型之间可以进行叠加,例如:针对商品金额的促销可以和针对同一商品的满减促销进行叠加。

在我们知道这些之后再来看看关于促销的时序图,通过它可以帮助你完成任意形式的促销产品设计:

促销时序图

对该时序图简要描述如下:

1. 当用户打开产品、并把商品加入购物车,然后用户进入购物车进行结算

2. 这时,系统首先需要将购物车商品与促销引擎的商品池进行比对,将所有参与第一类促销的商品全部拿出来并做好标记与没有参与第一类促销的商品区分开;

3. 再次将购物车所有商品与促销引擎的商品池进行匹配,将所有参与第二类促销活动的商品按照促销活动不同进行分组展示,同一促销活动商品归为同一组,不同活动则分为不同的组,没有参加活动的归为一组,每组活动根据促销金额门槛和当前组商品金额提示用户进行凑单;

4. 针对订单的促销活动,作为全局条件在购物车顶部或者底部进行展示(不针对商品所以没有分组),并根据用户购物车勾选的商品进行提示需要再做哪些购买操作才能满足全局优惠条件

5. 将这些结果返回给购物车并显示给用户,引导用户做出选择。

这个冬天有点冷,单身狗穷得只剩裤衩了

赞赏支持
  • 4-3397163ecdb3855a0a4139c34a695885.jpg
产品经理技能
Web note ad 1

转载于:https://www.cnblogs.com/jobs-lgy/p/9552344.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
C语言是一种广泛使用的编程语言,它具有高效、灵活、可移植性强等特点,被广泛应用于操作系统、嵌入式系统、数据库、编译器等领域的开发。C语言的基本语法包括变量、数据类型、运算符、控制结构(如if语句、循环语句等)、函数、指针等。在编写C程序时,需要注意变量的声明和定义、指针的使用、内存的分配与释放等问题。C语言中常用的数据结构包括: 1. 数组:一种存储同类型数据的结构,可以进行索引访问和修改。 2. 链表:一种存储不同类型数据的结构,每个节点包含数据和指向下一个节点的指针。 3. 栈:一种后进先出(LIFO)的数据结构,可以通过压入(push)和弹出(pop)操作进行数据的存储和取出。 4. 队列:一种先进先出(FIFO)的数据结构,可以通过入队(enqueue)和出队(dequeue)操作进行数据的存储和取出。 5. 树:一种存储具有父子关系的数据结构,可以通过中序遍历、前序遍历和后序遍历等方式进行数据的访问和修改。 6. 图:一种存储具有节点和边关系的数据结构,可以通过广度优先搜索、深度优先搜索等方式进行数据的访问和修改。 这些数据结构在C语言中都有相应的实现方式,可以应用于各种不同的场景。C语言中的各种数据结构都有其优缺点,下面列举一些常见的数据结构的优缺点: 数组: 优点:访问和修改元素的速度非常快,适用于需要频繁读取和修改数据的场合。 缺点:数组的长度是固定的,不适合存储大小不固定的动态数据,另外数组在内存中是连续分配的,当数组较大时可能会导致内存碎片化。 链表: 优点:可以方便地插入和删除元素,适用于需要频繁插入和删除数据的场合。 缺点:访问和修改元素的速度相对较慢,因为需要遍历链表找到指定的节点。 栈: 优点:后进先出(LIFO)的特性使得栈在处理递归和括号匹配等问题时非常方便。 缺点:栈的空间有限,当数据量较大时可能会导致栈溢出。 队列: 优点:先进先出(FIFO)的特性使得
该资源内项目源码是个人的课程设计、毕业设计,代码都测试ok,都是运行成功后才上传资源,答辩评审平均分达到96分,放心下载使用! ## 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.md文件(如有),仅供学习参考, 切勿用于商业用途。 该资源内项目源码是个人的课程设计,代码都测试ok,都是运行成功后才上传资源,答辩评审平均分达到96分,放心下载使用! ## 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.md文件(如有),仅供学习参考, 切勿用于商业用途。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值