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