优惠券产品设计攻略:优惠券设计的四个要点

产品经理就业特训营,专门为大学生和准备转型做产品的人量身定制,60天线下培训,包就业!了解详情

对于产品优惠券设计,作者总结了一份详细的设计攻略,其中有很多学习和参考的内容,希望对大家有所帮助。

最近和朋友聊天讨论到那么多种营销工具,哪一种最好用?从产品设计的复杂度和运营的灵活性上,我选优惠券。

优惠券和限时折扣、满减、满返、买赠、加价购、任选、阶梯价……这些最大的不同在于优惠群体的可定制性。对用户来说,试想某个阳光明媚的午后,不经意间抽中一张运营MM为你准备的优惠券,立马感受到尊享待遇,内心泛过一丝小得意有没有~

那么如此灵活的优惠券是如何设计出来的?只要抓住以下几个要点即可:生成、发放、使用、统计。

一、生成优惠券

优惠券批次&单张优惠券

在设计优惠券产品时,首先要弄清楚两个概念:优惠券批次、单张优惠券。

优惠券批次:是指N张同类型优惠券的集合,主要作用是便于针对同一使用条件生成若干张券,发放后可统计整体使用效果。

单张优惠券:指附带了使用条件的可供用户使用的一张优惠券。

生成优惠券批次

添加优惠券批次,需设定以下条件(见图),批次生成后,根据设定的数量自动生成若干张优惠券。

批次名称:即用户看到的优惠券名称,例如“新春有礼满100减20”

描述:可填写优惠券的使用范围、使用方法、运营文案等,在有需要的时候展示给用户查看,比如自动领取的页面里。

投放渠道:程序需针对不同投放渠道定义不同优惠券命名规则。

这个有什么用呢?举个例子,最近运营小A发现某宝上大量在以5毛钱出售本公司优惠券,只需花5毛钱得到一张优惠券,就可查询到是哪个市场渠道流出去的。

数量:自定义数量顾名思义就是限定发放的数量,这样更容易控制活动预算(当然预算还有一个重要的影响因素--使用率);而不限数量,多应用于系统自动发券,比如新用户注册送券,慎重使用。

优惠类型:主要分为两种,一种是优惠在订单中立即生效,比如满x元减x元,满x件减免x件金额,满x元x折,满x元赠x(这里说明一点,很多时候运营MM希望能生成无使用限制的优惠券,这并不是一种新的优惠券类型,只需要将优惠形式设置为满0元减x即可),所产生的优惠在订单中直接纳入计算;另一种是订单结束后生效,比如满x返x,一般是订单支付成功或者过了7天无理由退款申请期后返至账户。

抵扣类别:大部分优惠券是抵扣商品的,也会有专门抵扣运费、关税、分期手续费等的优惠券。

使用限制:主要作用是约定优惠券的使用范围,在使用优惠券时需校验相应逻辑。这里注意一点,使用限制区别于发放条件/领取条件,后者主要用于限制谁可以得到此优惠券,是对账户的限定,而前者更多的是对订单的限制。

二、优惠券的发放

一般情况下优惠券是通过以下三种方式发放的:系统自动触发、运营手动触发、用户自主领取。

发放必然伴随着通知,比如短信、邮件、微信、app push等等,因此营销工具和通知系统的打通也很重要。

系统自动触发

多用于日常运营行为,鼓励用户与平台产生更进一步的互动。触发条件如新用户注册、完成新手任务、连续登录、购买达标等等。规则有效期通常比较长,设定后长久有效。

而针对临时运营活动,比如大促期间连续签到5天即送券、召集8个好友砍价即送券,多数情况下只能拜托程序员GG临时写逻辑了。

运营手动触发

由运营来设定发放人群和发放时机。多用于周期性运营活动,刺激留存用户、唤醒沉睡用户。

设定发放人群的方式有很多种,最原始的方法也是最常见的方式就是运营MM说“我需要最近30天交易次数大于1次的用户名单”然后把excel名单倒入系统,系统跑批插券。再自动化一点的是运营MM直接设定好人群和券,由系统执行。

以上两种方式基本上已经涵盖了70%-80%的使用场景了。但毛病在于人为判定发放人群是否存在决策漏洞?比如,某些具备成为核心用户潜质的用户没有被激励和引导,而某些重要客户反复被各种券轰炸满满产生疲倦心理。

因此,为了提升营销效果引入机器学习定义潜在客户、建模管理用户群(比如最常用的RFM模型)、启用防优惠券骚扰机制,是产品和运营逐渐成熟后,需要进一步思考的方向。

用户自主领取

“得不到的永远在骚动,被偏爱的永远有恃无恐”大概是这样消费心理吧,用户自主领取的优惠券使用率往往会高于自动发放的。自主领取还可以和抽奖功能结合,增强趣味性和参与感。

设置自动领取

上面的脑图里对于如何设置领取条件以及说的挺详细的了,下图是如何设置优惠券抽奖。

生成领取链接

针对不同活动生成不同的领取链接,可以嵌入任意产品页面中,使用时统一调取已封装好的领取逻辑,包括计算抽中概率、返回抽中结果以及向用户账户中发放抽中的优惠券。

以前运营MM经常会在活动里让用户抽奖领券,开发GG类似的逻辑要写好几次,一接到这样的需求就唉声叹气,现在就无需这样的顾虑了。

三、用户使用优惠券

使用的场景基本就是这两种:用户手动输入优惠码,或是优惠券已在账户中。

这里主要要做的是以下几件事:

  1. 校验:校验用户此订单是否有使用这张优惠券的权限,这个涉及到上面生成优惠券时提到的一系列限制逻辑。
  2. 优惠计算:用户选择使用后,将优惠纳入订单金额计算。
  3. 记录使用&金额分摊:订单提交后将优惠金额分摊到每个商品上,以便于财务计算销售成本费用,以及当用户申请部分退款时能够清楚知道应退多少。

例如,某订单购买了A(50元)B(30元)C(30元)三个商品,使用了一张满100减10的优惠券,订单生成时不单单要记录使用的优惠券码是多少,还要能够将10元的优惠分摊到ABC三个商品上,分摊方法是:

  • A优惠=10*50/(50+30+30);
  • B优惠=10*30/(50+30+30);
  • C优惠=10-A优惠-B优惠。

四、效果统计

上面费功夫做了这么一堆事,最后就是看成效的时刻了。

单一批次效果

在时间维度上对使用情况和带来的销售额进行统计。

使用情况包含优惠券的投放数量、领取数量、使用数量、使用率、购买产品的分布情况。

销售额统计包含成交金额、订单数、客单价等。

(下图是截取了一部分图表展示)

多批次对比效果

某个月针对不同用户发了好几批券,一定想要知道哪批效果最出众。所以统计不同批次的效果对比,发现原因、总结经验,也很重要。

总结,以上是经历了多个优惠券产品后的经验总结。不同的产品使用场景也略有不同,只要掌握了最基础的设计思路,必能以不变应万变。

 

本文由 @丢丢聊产品 原创发布于人人都是产品经理。未经许可,禁止转载。

祝给予赞赏的伙伴,2017年发大财!
4人打赏

评论( 5

写下你的想法
  1. 游戏圈混迹5年,一事无成的傻子一个

    想问一个问题,如果平台型产品做得优惠卷,用户端使用的优惠卷需要商户端去核销,这个时候要咋办

    回复
    1. 回复

      首先要商户认可这个事,才有后面的核销一说。

    2. 回复

      可以增加在优惠券上增加一个平台承担比例的字段用以核销

    3. 回复

      商户发起核销申请–平台库检测用户使用权限与优惠券类别是否符合规定–符合则核销成功

    4. 回复

      这个很实用,我们现在就是这么做的

推荐阅读