美文网首页产品经理@IT·互联网@产品
营销系统的抽奖活动产品实践案例

营销系统的抽奖活动产品实践案例

作者: 做产品经理 | 来源:发表于2020-03-29 14:21 被阅读0次

    最近做的一个营销系统的产品,做了一些思考和总结。

    一、产品整体分析

    原始需求:

    1、希望引导用户多充值、少提现,引导用户交易某个产品,引导用户交易更多

    2、希望引导用户一步步参与更高难度的活动,实现更高的转化率

    3、可以配置不同奖品的概率

    4、不同用户等级,有不同的中奖概率

    5、限制用户中奖的次数

    需求分析:

    1、①计算指标:多充值少提现——净充值(充值-提现)、交易某个产品——交易产品、交易数量——交易更多(交易数量与交易金额成正比)这些条件

    ②为了方便运营可以创建不同的活动,引入多指标(多条件)组合的形式来统计用户完成情况(多维度计算)

    2、引导用户一步步完成更高难度的条件,即条件的值从小到大形成阶梯,实现阶梯条件功能

    3、提供奖品管理和概率配置功能

    4、不同等级可配置差异化概率

    5、提供中奖次数总上限的配置,并且限制每个奖品的单日上限和总上限

    确定整体需求之后,继续细化。

    抽奖活动的主流程是:报名参加活动→完成获得抽奖机会的条件→获得抽奖机会→抽奖→领取/兑换奖励。

    通过上面的流程,我们先把这几个步骤进行拆分和分析。

    报名参加活动,在产品设计中,需要设计一个报名系统,要考虑参与用户的前后台展示;从技术角度看,对应的是要做一个报名功能和参与用户数据表。

    完成获得抽奖机会的条件,从产品的角度看,需要考虑后台的条件配置以及完成条件的规则计算。对产品来说,逻辑/规则是非常重要,也是特别容易忽略的问题,也是极容易问题的难点。而本文主要想说的也是抽奖系统的逻辑/规则。从技术的角度看,需要对用户的行为进行记录和统计,然后通过产品所指定的逻辑/规则进行计算;对应的数据表是用户行为表、条件表。

    另外,还有一个步骤也是比较重要的,那就是“抽奖”。在抽奖这个步骤中,我们需要考虑的是中奖概率的计算问题。从产品的角度去看,抽奖的前端展示,从运营的角度去思考,让用户对抽奖感兴趣,让用户实时感受到自己离想要的奖品很近,让用户清楚地感受到自己中奖了。从技术的角度看,需要做一个抽奖的功能,需要计算中奖的概率,对应的也需要一张中奖用户的数据表。

    最后一个步骤是领取/兑换奖励。如果奖品是虚拟奖品,如优惠券之类的奖品,则可以设计成即时得到奖品,也可以设计成抽奖成功后,点击领取奖品;如果是实物奖品,还需要考虑填写邮寄地址、姓名、电话之类的内容。

    二、产品设计

    通过上面的分析,接下来我们做一下产品的设计。

    报名参加活动。前端的产品设计,需要做的是【立即报名】这样一个按钮;后台的产品设计,我们需要有一个页面来查看报名的用户。主要字段有:ID、用户账号、用户名称(姓名/昵称)、参与时间。除了这几个关键字段之外,可根据具体需求,可以显示用户的一些主要信息(如,注册时间)。

    完成获得抽奖机会的条件。主要在于后台的条件配置以及完成条件的规则计算。在后台的条件配置方面,为了方便更灵活地开展运营活动,我做了多条件组合的方式,同时做了完成条件的时间限制。这部分对产品、技术、测试来说,都是非常重要,也是非常麻烦的一部分。需要考虑多条件组的组合问题,也需要考虑多条件组合的问题。

    抽奖设计,前端方面,做了中奖的滚动播报,给用户的感知是“这么多用户都中奖了,没准下一个就是我了”,同时也让用户知道这个活动是有很多人参与并且中奖的,而不是一个无人参与、废弃已久的活动。

    (抽奖前端页面)

    后台方面,因为这个营销系统是用于长期性运营的,因此,后台的奖品是灵活可配置的。后台做了奖品设置以及中奖概率设置,关键字段有:奖项(一等奖、二等奖之类的命名)、奖品、中奖概率。另外,为了限制用户得到奖品的次数,避免用户每次都是获得同一奖品,还需要增加“总上限”的限制;为了避免用户一天之内频繁抽到同一个奖品,还可以增加“单日上限”的限制。

    为了针对不同等级的用户进行刺激,在概率的设置方面,对不同等级的用户做了差异化概率配置。

    领取/兑换奖励。在领取/兑换奖励方面,我们做得较轻,抽奖成功,直接获得奖励。后台方面,需要一个中奖记录的页面,展示所有中奖的用户以及奖品,主要字段有:ID、账号、用户名、参与时间、奖项、奖品、抽奖时间、领奖时间。

    三、产品逻辑/规则

    产品的逻辑逻是整个抽奖活动的关键,也是最容易出问题的一部分。这里主要讲一下获得抽奖机会以及抽奖概率计算的逻辑。

    1、条件组和条件的逻辑

    条件组的设计,主要是为了满足阶梯条件的需求,是为了让不同的用户群体,都能够参与到活动中来,并获得抽奖机会,阶梯的设计,还能够刺激用户为达成更高的层级,得到更多的抽奖机会,而完成更高的条件,进而促活以及提高转化率。

    因为是阶梯关系,条件组之间是【或】的关系,也就是只要用户满足了其中任意条件,都可以得到所获得的条件中对应的抽奖次数。

    条件的设计,是为了促使用户参与更多的操作,提高用户的活跃率和转化率。因为想要用户做更多操作,条件之间是【与】的关系,也就是用户需要同时满足多个条件,才能够获得抽奖机会。

    2、满足条件的逻辑

    怎样才算满足条件?这里主要有几种方式:

    1)按单笔计算

    线下场景:某超市搞周年庆活动,只要一次性消费满100元,就能够兑换1张抽奖券;一次性消费满300元,就能够兑换2张抽奖券;一次性消费满800元,就能够兑换5张抽奖券。

    这种方式最简单直接,很多的抽奖活动也是这么设计的。用户单笔达到条件,即可兑换相应的抽奖机会,已兑换抽奖机会的交易会被清除,不会再次纳入到下一次的统计。这种方式能够满足阶梯活动的需求,用户交易越多,可以达到越高的阶梯。

    2)按累计计算

    由于有些业务的特殊性,单笔的效果并不是很好,所以需要通过累计的方式,促进用户持续活跃,持续转换,这是可能是一个循序渐进的过程。所以通过累计计算的方式,一步步将用户从低阶梯引导到高阶梯,持续投入,既增加了用户的活跃度,也能逐渐提高转化率。

    线下场景:某超市搞周年庆活动,累计消费满100元,就能够兑换1张抽奖券;累计消费满300元,就能够兑换2张抽奖券;累计消费满800元,就能够兑换5张抽奖券。

    累计的方式相对复杂一些,也容易出现问题。按照上面的例子,如果用户第一次消费了100元,得到了1张抽奖券。第二次消费了200元,用户的心理可能是暂时选择不兑换,等待第三次消费,即使没有继续消费了,也可以在活动结束前去兑换抽奖券;如果用户第三次消费了150元,那他的累计消费金额就是200+150=350元,可以再兑换2张抽奖券。

    线下可以由用户自行选择是否兑换,但是如果是程序的话,程序需要有一个触发时机,如果将用户满足条件作为触发兑换的时机的话,当用户第二次消费200元的时候,就已经触发满足100元的这个条件,并自动兑换1张抽奖券了,也就是说,用户必须一次性满足条件,或者自行设计先交易低于第一个阶梯,再交易累计达到第二个阶梯,才能够达到第二个阶梯。否则,无法满足用户按阶梯参与活动的需求。

    3)累计计算,用户选择性兑换

    有的朋友可能会说,那为什么不按照类似线下的这种方式,让用户自己选择是否兑换呢?

    是的,这的确也是一种方式,这就需要在原来的流程中,加入“兑换抽奖机会”的流程。那产品逻辑就可以这样定义:用户满足条件后,给用户发放兑换抽奖机会的资格,用户可以自行选择是否兑换。

    但是,每增加一个步骤,路径就会深一层,流失率也会高一些。

    4)累计计算,程序自动兑换

    还有另外一种方式是:在程序层面增加一个步骤,增加一个中间层,也就是用户满足条件后,用户得到一个中间层的抽奖机会,如果用户使用这个抽奖机会去抽奖的话,这时候触发正式兑换抽奖机会并抽奖的操作;如果用户不抽奖的话,这个中间层的抽奖机会没有触发兑换真实抽奖机会的操作,一旦用户继续交易,达到下一个阶梯的时候,累计原来的金额,按照更高的阶梯得到一个中间层的抽奖机会,直到用户抽奖的时候,才正式兑换抽奖机会并抽奖。

    例如,以预抽奖机会和实抽奖机会来区分。用户第一次消费100元,得到1次预抽奖机会,用户用这个预抽奖机会去抽奖,触发将预抽奖机会兑换成实抽奖机会,并进行了抽奖。用户第二次消费200元,得到1次预抽奖机会,但是用户没有用这个预抽奖的机会去抽奖;第三次消费了150元,这时候累计消费金额达到200+150=350元,得到2次预抽奖机会,用户没有抽奖,继续消费,第四次消费450元,这时候累计消费金额达到200+150+300+450=800元,得到了5次预抽奖机会,这时候用户进行抽奖了,抽奖时,触发了将预抽奖机会兑换成实抽奖机会,下次再消费时,重新开始累加。

    这个这样的话,用户层面就觉察不到这个兑换抽奖机会的流程,降低流失率。但是,或许有的朋友看了这个规则之后,已经绕晕了。这样做就很复杂了,开发做起来很麻烦,而且也极容易出问题。

    5)累计计算,限制阶梯兑换次数

    其实,逻辑设计的关键点在于“触发时机”,我们需要给程序制定一个合理的“触发时机”。触发的时机可以是事件,也可以是时间,还可以是制定的规则。单笔计算的方式,其触发时机是:消费的金额达到条件组的条件金额时,触发兑换。上面第二种方式的累计计算,其触发时机也是:消费的金额达到条件组的条件金额时,触发兑换。上面第三种方式的用户选择性兑换,其触发时机是:用户选择兑换时,触发兑换。上面第四种方式的程序自动兑换,其触发时机是:用户进行抽奖时,触发兑换。

    除了上面提到四种产品方案,是否还有其他方案?

    如果程序的触发时机是:消费的金额达到条件组的条件金额,且阶梯不可重复。这也是一种方案。

    线下场景:某超市搞周年庆活动,只要一次性消费满100元,就能够兑换1张抽奖券,只能获得一次;一次性消费满300元,就能够兑换2张抽奖券,只能获得一次;一次性消费满800元,就能够兑换5张抽奖券,只能获得一次。

    举个栗子:用户第一次消费了150元,兑换了1张抽奖券,兑换完之后,不再累计到下一次兑换;用户第二次消费了100元,因为已经兑换了第一个阶梯了,所以不能继续兑换第一个阶梯的抽奖券;用户第三次消费了260元,这时候累计100+26=360,满足第二个阶梯,兑换了2张抽奖券,兑换完之后,不再累计到下一次兑换。用户第四次消费了350,因为前两个阶梯都已经兑换过了,不能重复兑换;用户第五次消费了600元,这时候累计消费了350+600=950,满足第三个阶梯,可以再兑换5张抽奖券;所有的阶梯都已经兑换过之后,即使满足了条件也不能继续兑换。

    3、概率的计算逻辑

    常见的概率计算,是所有奖品(含不中奖)的概率加起来等于100%,那想要实现多等级差异概率,要怎么计算?

    其实和上面的概率是差不多的,同一等级的所有奖品,概率加起来小于等于100%,不满100%的部分为不中奖的概率。奖品的单日上限或总上限达到之后,继续抽奖将不再中奖。

    运营在设置中奖概率的时候,怎么设置更合理?预估某个用户等级的参与人数来预估概率,即:中奖概率=奖品数/某个等级的预估参与人数*100%。

    除了抽奖系统,很多营销类型的产品也类似。

    以上的产品案例为做营销系统项目过程中的一些感悟,仅供参考,具体的产品方案,需根据实际的场景和需求来选择。

    如果你有更好的产品方案或者想法,欢迎在文章后面评论留言。

    作者丨风笛

    来源丨做产品经理

    相关文章

      网友评论

        本文标题:营销系统的抽奖活动产品实践案例

        本文链接:https://www.haomeiwen.com/subject/kktuuhtx.html