家资是何物,积帙列梁梠。这篇文章主要讲述vivo全球商城-营销价格监控方案的探索相关的知识,希望能为你提供帮助。
一、背景现在日常官网商城的运营中有一定概率出现以下两个问题:
1)优惠信息未对齐
官网商城促销优惠的类型越来越多,能影响最终用户实付价的优惠就有抢购、满减、优惠券、代金券等。实际业务操作中存在不同促销优惠由不同运营配置的情况,如果运营间内部没有对齐的情况下,就会出现正常情况下不会同时设置的优惠被用户叠加享受,出现最终实付价低于成本价的可能。
2)优惠价格配错
在日常或大促优惠配置中,存在一定的概率会配错优惠价格(比如一口价少了个0,这就相当于在原来预期的优惠价基础上打了一折),这种情况一旦发生可能会引发用户疯狂下单,造成非常大的损失,这也是我们平时说的“薅羊毛”
文章图片
(引用自英国每日邮报,摄影-AIan Price)
针对前述两种情况,我们希望能够对于出现低于运营所设「底价阈值」的下单购买行为能进行一定预警,必要时能购阻断用户下单行为,及时止损,如果能提前规避这些行为就更好了。
二、营销价格能力矩阵想要解决背景中所遇到的问题,我们先简单了解下营销价格能力矩阵的规划建设。
通过《vivo商城计价中心 - 从容应对复杂场景价格计算》、《vivo全球商城时光机 - 大型促销活动保障利器》,我们了解到官网商城的营销价格服务已经统一收口到促销的计价中心,在计价中心建设的过程中也发现一些问题:
- 计价中心的业务定位是商城购物链路中的下单商品实时价格的计算,而有些接入计价的业务(如官网商品列表)其实对于商品实时价格要求并没有那么高或者准实时的优惠价格在业务上也是能接受的。
- 运营同学在维护相关优惠或配置相关优惠券时,无法方便感知在未来某一时刻某商品所享受的优惠信息或者某一时刻商品的最低价格能到多少,也就会出现了不同运营配置了多重优惠导致实际售卖价格低于预期。
- 商城售卖的商品在某一时间段内的实际优惠后的价格没有历史记录,对于运营回顾历史数据无法提供实质帮助。
- 若后续平台对于大促期间商品价格承诺xx天内保价也无从做起,没有数据作参照比对。
可以通过如下的业务架构图来描述我们的营销价格能力矩阵规划:
【vivo全球商城-营销价格监控方案的探索】
文章图片
三、 价格监控 3.1 目的结合「商城营销价格能力矩阵」规划的能力,希望能达成:
- 提升运营配置优惠活动的准确性 (事前)
- 提供多维度策略供运营决策(事中)
- 提供相关营销价格数据供挖掘(事后)
文章图片
3.2.1 事前
a. 提前规避
- 优惠互斥设置
文章图片
- 设置SKU底价阈值
- 设置活动优惠价时,出现低于底价阈值的进行及时提醒。
文章图片
c. 提前告警
- 定时巡检商品,预警未来时间点的优惠价低于阈值的。
文章图片
如果发现了低于底价阈值的情况,则会通过内部通讯工具立即通知相关人员进行及时处理。
文章图片
3.2.2 事中
a. 优惠生效及时预警
优惠活动生效时第一时间预警低于阈值的信息。
优惠生效及时预警的处理流程如下:
文章图片
如果发现有需要告警的通知,则向运营相关的同学发出如下通知:
文章图片
b. 实时监控下单行为
监控每个SKU实时下单优惠价,根据策略或告警或阻断下单行为。
实时监控下单处理流程如下图所示:
文章图片
实时下单经过计价中心处理时,如果发现低于底价阈值,则会发出如下告警信息:
文章图片
另外价格监控还提供了一系列阻断下单策略,当符合预设条件时,会直接阻断正常下单流程,以减少不必要的损失。另外由于阻断下单这一行为性质很严重,所以针对是否开启阻断下单这一行为专门设置了全局性的阻断下单开关,又运营灵活掌控。
3.2.3 事后
a. 历史营销价分析
- 查询历史优惠价格走势
- 沉淀历史优惠价供运营分析决策
- 承诺低价保证
- 商详页到手价低价提醒
- 结算页低价提醒
在使用的过程中我们也避免”狼来了“这样对告警通知麻木的情况,因此为解决这个问题,我们可以对于告警信息进行一个闭环处理,对于每一个告警信息需要做做处理,哪怕是事后处理,要区分告警原因,是因为系统误报还是确实优惠设置有问题等等,逐渐习惯于对每一个告警信息都能保持关注和及时响应,把所有可能存在的问题都在事前阶段就暴露出来。
推荐阅读
- Linuxyum install 没有可用软件包 解决办法
- 网站windows操作系统使用宝塔来搭建网站的方法
- Java编程之伪共享与缓存行填充
- Kafka性能篇(为何Kafka这么"快"())
- 51单片机linux环境LED数码管开关循环判断演示
- nginx启停脚本
- 还不懂shell脚本核心(这一篇就够了。)
- ROS交叉编译——protobuf/yaml-cpp/opencv
- STM32FreeRTOS 系统配置