通过两年的更新「SkrShop」已经构成了下面的架构:git
图中紫色的内容就是本编文章的主要内容:营销体系的基础服务「优惠券服务」。可是呢,首先要说的是关于不断被催更的事。github
关于催更?小程序
我给出了以下解释:人逢假日懒🤷♀️(我没错😭)、工做紧、须要保证质量,就酱。可是我必定能保证的是一直会更新下去,但愿获得你们理解。微信小程序
关于下期内容?bash
以前在Github上的Issues你们一致想看关于订单相关的内容,因此更新完本期「优惠券」以后就开始了订单之旅。微信
Issues以下:架构
1. https://github.com/skr-shop/manuals/issues/25
2. https://github.com/skr-shop/manuals/issues/18
复制代码
进入正题,营销体系的基础服务「优惠券服务」。经过以下问题来介绍优惠券:异步
对于获取优惠券的用户而言:关注的是优惠券的优惠能力,因此按优惠能力维度优惠券主要分为下面三类:工具
优惠能力维度 | 描述 |
---|---|
满减券 | 满多少金额(不含邮费)能够减多少金额 |
现金券 | 抵扣多少现金(无门槛) |
抵扣券 | 抵扣某Sku所有金额(一个数量) |
折扣券 | 打折 |
对于发放优惠券的运营人员而言:post
一种是「固定有效期」,优惠券的生效时间戳和过时时间戳,在建立优惠券的时候已经肯定。用户在任意时间领取该券,该券的有效时间都是以前设置的有效时间的开始结束时间。
另外一种是「动态有效期」,建立优惠券设置的是有效时间段,好比7天有效时间、12小时有效时间等。这类优惠券以用户领取优惠券的时间为优惠券的有效时间的开始时间,以以用户领取优惠券的时间+有效时间为有效时间的结束时间。
有效期维度 | 优惠券类型 | 优惠券生效时间 | 优惠券失效时间 | 描述 |
---|---|---|---|---|
固定 | 固定有效期 | 优惠券类型被建立时已肯定 | 优惠券类型被建立时已肯定 | 不管用户什么时间领取该优惠券,优惠券生效的时间都是设置好的统一时间 |
动态 | 动态有效期 | 用户领取优惠券时,当前时间戳 | 用户领取优惠券时,当前时间戳 + N*24*60*60 | 优惠券类型被建立时,只肯定了该优惠券的有效,例如6小时、7天、一个月 |
小结以下:
运营策略 | 描述 |
---|---|
(非)指定Sku | Sku券 |
(非)指定Spu | Spu券 |
(非)指定类别 | 类别券 |
指定店铺 | 店铺券 |
全场通用 | 平台券 |
适用终端(复选框) | 描述 |
---|---|
Android | 安卓端 |
iOS | iOS端 |
PC | 网页电脑端 |
Mobile | 网页手机端 |
微信端 | |
微信小程序 | 微信小程序 |
All | 以上全部 |
适用人群 | 描述 |
---|---|
白名单 | 测试用户 |
会员 | 会员专属 |
小结以下:
领取优惠券场景 | 描述 |
---|---|
活动页面 | 大促、节假日活动页面展现获取优惠券的按钮 |
游戏页面 | 经过游戏获取优惠券 |
店铺首页 | 店铺首页展现领券入口 |
商品详情 | 商品详情页面展现领券入口 |
积分中心 | 积分兑换优惠券 |
展现优惠券场景 | 描述 |
---|---|
活动页面 | 大促、节假日活动页面展现能够领取的优惠券 |
商品详情 | 商品详情页面展现能够领取、能够使用的优惠券列表 |
我的中心-个人优惠券 | 个人优惠券列表 |
订单结算页面 | 结算页面,适用该订单的优惠券列表以及推荐 |
积分中心 | 展现能够兑换的优惠券详情 |
选择优惠券场景 | 描述 |
---|---|
商品详情 | 商品详情页面展现该用户已有的,且适用于该商品的优惠券 |
订单结算页面-优惠券列表 | 选择可用优惠券结算 |
订单结算页面-输入优惠码 | 输入优惠码结算 |
返还优惠券场景 | 描述 |
---|---|
未支付订单取消 | 未支付的订单,用户主动取消返还优惠券,或超时关单返还优惠券 |
已支付订单全款取消 | 已支付的订单,订单部分退款不返还,当整个订单所有退款返还优惠券 |
场景示例 | 描述 |
---|---|
活动页领券 | 大促、节假日活动页面展现获取优惠券的按钮 |
游戏发券 | 游戏奖励 |
商品页领券 | - |
店铺页领券 | - |
购物返券 | 购买某个Sku,订单妥投后发放优惠券 |
新用户发券 | 新用户注册发放优惠券 |
积分兑券 | 积分换取优惠券 |
小结以下:
发放方式 | 描述 |
---|---|
同步发放 | 适用于用户点击领券等实时性要求较高的获取券场景 |
异步发放 | 适用于实时性要求不高的发放券场景,好比新用户注册发券等场景 |
发放能力 | 描述 |
---|---|
单张发放 | 指定一个优惠券类型ID,且指定一个UID只发一张该券 |
批量发放 | 指定一个优惠券类型ID,且指定一批UID,每一个UID只发一张该券 |
发放类型 | 描述 |
---|---|
优惠券类型标识 | 经过该优惠券类型的身份标识发放,好比建立一个优惠券类型时会生成一个16位标识码,用户经过16位标识码 领取优惠券;这里不使用自增ID(避免对外泄露历史建立了的优惠券数量), |
优惠码code | 建立一个优惠券类型时,运营人员会给该券填写一个6位左右的Ascall码,好比SKR6a6 ,用户经过该码领取优惠券 |
撤销能力 | 描述 |
---|---|
单张撤销 | 指定一个优惠券类型ID,且指定一个UID只撤销一张该券 |
批量撤销 | 指定一个优惠券类型ID,且指定一批UID,每一个UID撤销一张该券 |
用户优惠券列表 | 子类 | 描述 |
---|---|---|
所有 | - | 查询该用户全部的优惠券 |
能够使用 | 所有 | 查询该用户全部能够使用的优惠券 |
- | 适用于某个spu或sku | 查询该用户适用于某个spu或sku能够使用的优惠券 |
- | 适用于某个类别 | 查询该用户适用于某个类别能够使用的优惠券 |
- | 适用于某个店铺 | 查询该用户适用于某个店铺能够使用的优惠券 |
无效 | 所有 | 查询该用户全部无效的优惠券 |
- | 过时 | 查询该用户全部过时的优惠券 |
- | 失效 | 查询该用户全部失效的优惠券 |
订单结算页面推荐一张最适合该订单的优惠券
小结以下:
一旦有发生风险的可能则触发风控:
领取 | 描述 |
---|---|
设备ID | 天天领取某优惠券的个数限制 |
UID | 天天领取某优惠券的个数限制 |
IP | 天天领取某优惠券的个数限制 |
使用 | 描述 |
---|---|
设备ID | 天天使用某优惠券的个数限制 |
UID | 天天使用某优惠券的个数限制 |
IP | 天天使用某优惠券的个数限制 |
手机号 | 天天使用某优惠券的个数限制 |
邮编 | 好比注重邮编的海外地区,天天使用某优惠券的个数限制 |
依托用户历史订单数据,获得用户成功完成交易(好比成功妥投15天+)的比率,根据此比率对用户进行等级划分,高等级进入通行Unblock名单,低等级进入Block名单,根据不一样用户级别设置限制策略。等其余大数据分析手段。
根据预算值设置发券总数阈值,当触发阈值时阻断并报警。
优惠券尽可能不要支持虚拟商品以防止可能被利用的不法活动。
[Skr Shop] 项目地址长按进入:github.com/skr-shop/ma…
SkrShop系列更多文章: