编辑导语：积分激励体系的落地节奏设计十分重要，把控着整个积分激励体系的规划等，本篇文章作者列举相关案例，讲解了积分激励体系的落地节奏设计，用户端与后台产品方案及涉及到的一部分交互设计等相关内容，详细地讲述了整个方案从策略到产品落地的全过程，一起来看一下吧。

我们上篇用比较大的篇幅讲述了对于积分激励策略的推算。最终我们利用案例（点评App产品）得出一个积分模型，即预计发放100亿积分，并且整体的发放策略如下。

那么有了具体的激励内容之后，我们就需要落地到实际场景中了。

我们常规的关于落地的的概念，就是把整体的策略落实到怎样的节奏实现，产品上怎么去实现，以及有哪些要注意的点。

所以这篇我们还是以这个点评类网站的案例为例，讲解下积分激励体系的落地节奏设计，用户端与后台产品方案及涉及到的一部分交互设计等相关内容。

一、积分激励体系上限设计与节奏周期

我们的方案中预留了10%的激励给新产品、新内容宣传所用在，这部门激励我们无需规划也难以规划，因此等新业务有需求的时候再进行预算分拨与对应的任务规划即可。

但对于常规可预料的任务上，涉及后续产品细节与整体把控，因此在周期开始前最好就进行有序规划。

1. 为每个单项激励设定上限

这个道理比较简单，假如没有上限设置，用户可以无限获取积分，那么整个积分体系肯定崩盘。

我们可以通过激励次数限制，与激励数值限制两种方式去设定常规任务的激励上限，设计每项任务上限。

回到案例中：我们需要按以往的经验给每个任务设定频率（对应到次数）与激励分值上限，从而制定任务节奏规划。

为了后续交互层设计方便，我们统一以周为单位去做限制：

“新用户注册”、“签到类”任务，我们认为是最常规的任务，根据常见的定义去设定即可。签到即每个自然日可签到一次，上限即为365次（对应周期365天）。“浏览”，“发表评论”，“发表300字内容”这类可高频无上限的操作，由于我们预算的激励次数有限，而用户产出的平均次数可能远大于我们设定的激励次数，因此我们设定这部分激励要把时间间隔拉大，从而达到 限制激励次数的目标。 而“消费”类是平台最希望达到的效果，这部分内容我们希望用户每次购买之后都能获得激励，因此我们在激励频率上不做限制，但是假如整体不控制最终还是可能失控，因此在

激励数值上限上去做设定，如每次最高只激励2000积分。

2. 积分激励节奏图

设定好周期之后，我们的节奏图大概可以出来了。

实际业务场景中不同月份的业务状态是不同的，比如日常的6月、11，12月大促月我们会同步增加激励，因此实际业务场景中我们还需要根据每个月份的具体情况再进行激励内容、数值与上限的调整。

为了让案例简单好理解，我们假设每个月都是平均分配的状态去做激励分解。

二、固定预期与不确定预期相结合的积分发放方案1. 定额任务与非定额任务

根据用户行为所获得的积分数额，我们可以分成定额任务与非定额任务。

1）定额激励

定额激励任务是非常确定预期的激励，对于用户而言我完成了什么动作及可以得到多少数量的积分，用户心理有底——我做了什么可以得到什么，一目了然。

比如注册获得100积分，签到获得10积分，购买1元获得100积分……这些激励数值是固定的，用户的预期也是确定的。

简单意味着好记忆，很容易形成认知和习惯。因此我们建议大部分任务都采用固定数额激励的方式，比较容易培养用户习惯。

但过于简单也容易过于单调。并且后续如果策略调整，需要对发放积分值进行调整，也非常容易被用户知晓从而产生心理落差。

2）非定额激励

基于定额任务较为单调的缺点，我们建议使用非定额激励（保底的概率型激励方式）作为一些特殊任务的补充。

情况1：

为了让整体任务体系变得更有趣味性，增加对未来的不可预知的好奇心，也为未来的策略调整预留一部分空间，我们推荐一些“阶段性任务激励”采用非定额激励；

比如我们的案例中，签到7天这个行为，不是直接给予30积分（日常5积分+额外25积分）奖励，而是调整成20-100积分。让7天奖励的诱惑度直线提升。后台通过概率控制的方式让整体的分值控制在30左右。

情况2:对于像内容产出这类非标准任务，我们导向的是内容质量而非内容数量，如果一视同仁的完成对应数字+图片的内容创作即可获得同样的积分，我们很容易收获一个“灌水”社区。即用户为了得到积分随意填写内容文字导致社区内容质量大大降低。

所以针对这类非标准内容，我们采用的也是非定额激励。

比如写300字以上的评论可以获得50-300的积分，用户完成之后马上获得50积分，然后通过人工审核或者AI审核方式进行内容定级，再一次进行优质内容的积分激励，从而导向“优质内容”等目标。

非定额任务优点在于所对应的宽泛的区间型奖励，可以给用户打造高昂奖品的心理暗示，从而达到四两拨千斤的作用。

但是也有一定的缺点：由于预算有限，多数用户得到的是低于期望值的激励，加上对于不确定的预期也模糊了用户认知，没有清晰的记忆点。

因此小用怡情，大用伤身哦！

三、用户端行为到反馈的闭环交互

我们需要将所有的策略全部呈现至用户可见的功能页面中，用户才能真正参与。所以最表现的内容即是产品的交互设计与视觉呈现。

我们需要根据不同的产品功能以及其界面进行差异化交互设计，完成从行为激励到激励反馈到行为激励的闭环设计。

1. 任务中心——作为所有任务的承载

除了比如注册类任务之后，其他常规的登录后才能去做的任务，我们往往会生成一个任务中心，承载着所有的任务集中引导。任务中心可以是页面形式，也可以是弹窗形式呈现。

很多产品中，产品/设计对于任务的设计都是按照统一任务卡片的方式呈现，事实上，如太多的任务卡片会让用户感觉压力较大，难以完成。

其实可以根据任务类型的不同做差异化的展示。

在我们的案例中，我们用了3种不同的版块呈现方式——周签到区，任务卡片，以及消费引导区块。用不同类型的呈现减少“必须完成任务”的压力感，也丰富产品体验。

2. 反馈与闭环——根据现有功能进行不同行为反馈交互设计

在产品落地的交互设计时，除了产品功能本身的内容外，我们还需要考虑功能前后链路的用户路径的设计与引导，从而实现最高效转化。

任务中心承载着所有任务的出口，而各种功能页面则是最终的用户用户行为落地点，而用户完成任务之后的反馈是最终任务的结果点。因此除了任务中心外，我们也需要考虑与之相关的上下链路的体验提升，进一步提升任务转化漏斗。

这个案例中，我们把关于任务（即积分激励）相关的整体用户路径进行梳理，链路上游争取吸睛入口，下游在原有功能的基础上着重设计积分激励的反馈与引导，将整个积分激励体验上做细致的处理。

我们的点评案例中，我们根据任务功能上下链路原本的交互特性做了区分处理。

值得注意的是，涉及上下游链路的功能内容往往不只是一个部门或者一个岗位所能决定，但上下游链路的设计好坏又极其影响当前负责内容的结果，毕竟互联网时代“酒香也怕巷子深”。

所以在过程中与其他部门（业务模块）的产品、设计、技术相关部门沟通、Push各部门争取资源都非常关键。

对于负责积分激励模块的同学来说，这时候考验的更多是资源、沟通协调能力。需要提前思考怎么说服，以及做好plan B计划。

这部分内容不做赘述，大家见机行事吧！

四、对，激励体系只是催化剂

与同行朋友交换关于积分产品想法的时候，朋友说我说的太好了，但是不是过度放大了积分的价值，说的好像有了个积分任务就能引导用户的所有行为似的。

不不不！燃豆努力规划着、落地着这么一套积分激励策略，并不等于我们认为积分激励体系是万能的。

恰恰相反，燃豆一直认为产品、品牌本身功能才是基础，而积分激励体系属于运营的一部分，是在产品功能基础上起到锦上添花作用的一个工具。

用户行动的动机多数不是因为积分所决定的，积分或者说激励（也可以是其他的激励内容）只是承载催化剂的作用，去催化产生某些行为。

举个笔者个人在生活中的例子：

同样是支付，微信支付与支付宝支付所对应的功能是一样的。但是我一般优先选择支付宝支付，因此支付宝支付会奖励蚂蚁森林的“能量”，让我的小树苗可以更快成长。我自己经常会逛电商网站，比如拼多多，但是我会看中很多商品，不紧急的情况下一般会收藏着。当我玩拼多多果园这类活动时，我需要去赚取“水滴”和“化肥”，这时候拼多多再把我需要的商品推送给我并且告知我购买可得“化肥”，这种情况下原本不那么紧急的商品我也很有可能会提前下单，因为反正需要购买，不如现在买了还能得“化肥”。我们出去吃饭经常会在大众点评上购买团购券并且吃饭过程中会拍比较好看的饭菜照片，但是大部分时间都懒得给餐厅评价。而大众点评鼓励我评价可以获得高额积分，我就顺手整理下手机里的照片，配上简单的文字内容，形成一条高质量评价。

无论是“能量”、“水滴”、“化肥”其实都是虚拟货币，也就是变种的积分。我们不会因为积分而无故去支付，去购买无用的商品。

但是我们有支付需求的时候，就可能会选择更有激励的那个产品。

当我们有购买诉求但并不急于下单的时候，激励也有可能提前触发下单的行为。

当我们有素材但是懒得编辑的时候，激励也有可能让我们花点时间编辑。

所以这也是我们作为互联网从业者花大量时间去设计、去落地激励体系的意义：

当我们的产品与竞品功能很类似的时候，积分激励给予用户更多选择我们的理由；当用户有诉求但不急于行动/懒得行动时，积分激励给用户一个正当的理由落实行动。

五、写在最后

本篇内容我们主要是用了一个案例，详细解释了一个积分激励方案从想法层到产品层的具体转化过程。

本来内容还包括后台功能设计、数据与风险方面的内容，但是燃豆风格就是把东西说的很细致，也就让内容变得太长了。

那就把这部分放下面一篇吧。

作者：燃豆侠；

本文由 @燃豆侠 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。