一、产品整体分析
抽奖活动的主流程是：报名参加活动→完成获得抽奖机会的条件→获得抽奖机会→抽奖→领取/兑换奖励。
通过上面的流程，我们先把这几个步骤进行拆分和分析。
报名参加活动，在产品设计中，需要设计一个报名系统，要考虑参与用户的前后台展示；从技术角度看，对应的是要做一个报名功能和参与用户数据表。
完成获得抽奖机会的条件，从产品的角度看，需要考虑后台的条件配置以及完成条件的规则计算。对产品来说，逻辑/规则是非常重要，也是特别容易忽略的问题，也是极容易问题的难点。而本文主要想说的也是抽奖系统的逻辑/规则。从技术的角度看，需要对用户的行为进行记录和统计，然后通过产品所指定的逻辑/规则进行计算；对应的数据表是用户行为表、条件表。
另外，还有一个步骤也是比较重要的，那就是“抽奖”。在抽奖这个步骤中，我们需要考虑的是中奖概率的计算问题。从产品的角度去看，抽奖的前端展示，从运营的角度去思考，让用户对抽奖感兴趣，让用户实时感受到自己离想要的奖品很近，让用户清楚地感受到自己中奖了。从技术的角度看，需要做一个抽奖的功能，需要计算中奖的概率，对应的也需要一张中奖用户的数据表。
最后一个步骤是领取/兑换奖励。如果奖品是虚拟奖品，如优惠券之类的奖品，则可以设计成即时得到奖品，也可以设计成抽奖成功后，点击领取奖品；如果是实物奖品，还需要考虑填写邮寄地址、姓名、电话之类的内容。
二、产品设计
通过上面的分析，接下来我们做一下产品的设计。
报名参加活动。前端的产品设计，需要做的是【立即报名】这样一个按钮；后台的产品设计，我们需要有一个页面来查看报名的用户。主要字段有：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%。
除了抽奖系统，很多营销类型的产品也类似。
以上的产品案例为做营销系统项目过程中的一些感悟，仅供参考，具体的产品方案，需根据实际的场景和需求来选择。
如果你有更好的产品方案或者想法，欢迎在文章后面评论留言。
作者丨风笛
来源丨做产品经理
