让裂变活动成功的6个设计亮点！

最近，一个做运营的朋友向我吐槽，说自己想做一个裂变活动，但是在给产品提需求的时候被diss了半天，说很多环节的设计都不符合逻辑，研发一定会把这个需求给怼回来。为了能通过评审，她按照产品说的逻辑改了4、5版方案，最终才通过。

她很无奈地说：每次想上个新功能的时候都会怀疑一下人生，作为一个技术盲的运营，实在是太痛苦了！

的确，通常我们想做活动的时候，流程基本都是运营给产品提需求，产品给技术提需求，一环又一环的沟通下来，才有了一个又一个的活动上线。不过，从运营的角度提的需求，经常会忽略一些技术上存在的问题，运营-产品-技术这条食物链的撕逼也大多由此产生。

今天，我们就以饿了么最近上线的“邀请好友领现金”为例，来看看一场裂变活动要考虑哪些技术细节，让大家在做类似活动的时候，可以减少一些沟通成本，更高效的完成任务！

一、活动参与流程图

1、点击或扫码进入页面流程图：

亮点：

1）检测浏览器标识符，请求用户授权微信或者直接进入登录状态，这个功能可以减少用户的操作成本，特别是当前大家都在用QQ/微信的情况下，被分享了饿了么链接，如果每次登录都需要一个复杂的注册登录操作，势必会减少实际成果注册的用户；

2）账号异常的图形验证码，这个验证码我理解为防刷的一种方式，通过脚本或者机器可以做到自动登录以及自动操作的情况，但是加上验证码以后对于用户不会有太大影响，对于机器操作会降低效率，提高操作难度(有些需要识别图形验证码)；

3）判断是否为用户自己的邀请链接，这个判断生成的页面一方面可以识别用户情况，另一方面就算是自己生成链接的用户也可以在页面上看到对应自己的内容（页面提示邀请的活动）。

2、进入页面后参与活动及邀请其他人

亮点：

检测浏览器标识符这里还是跟上一个差不多，不过这里的检测主要是为了方便识别用户分享，如果是微信或者QQ内，是可以对应呈现操作的，例如微信内会提示右上角分享给朋友或者分享到朋友圈，而QQ则长按出现分享到朋友及空间等；

二、活动设计亮点

注：以下分析内容均基于个人知识框架，如有疏漏请见谅

被邀请后截图（说实话，看到这一堆券，我是有点心动的，76块钱像是已经白捡到了一样）。

1、邀请双方均可得奖励：

用户A为老用户，用户B为新用户。用户A邀请用户B，分享了链接给B微信，B用户注册，且注册7天内完成实付超过7元的首单，14天内完成实付超过10元的二单，则用户A可获得最高15元现金奖励，B则可获得3元店铺优惠红包，及支付宝红包（需新户注册）；

实现方法：

通过链接带的refer_id也就是邀请用户的ID来判断是谁邀请的，然后监测用户行为（App内用户打开可能还有其他方式促进成单和留存，例如签到、红包等），用户完成了订单，是否是指定时间内，是否满足指定金额的规则；

同时根据用户的进度在用户A即邀请人的后台显示“待下单”、“在路上”等。

2、新用户邀请生效规则：

用户B在指定时间内完成订单，用户A才可拿到奖励。这里有两个订单，时间期限分别为7或14天内，也就是说15块至少买了2次用户支付的完成订单，其中还可能包括用户的7日，14日留存率；

新人的券有78元，例如最多优惠15+10，需要买69的商品，还需要3-6的配送费，也就是实付44左右；如果是15+3，需要买25元，配送费3-6，则需付10左右（暂不考虑满减），一般的店铺新人找个超过7的还是比较简单的；

实现方法：

机器催付+人工催付。

人工催付即邀请人的催付，一般来说邀请人为了避免用户的流失（例如注册后忘记下单），会在注册后第一时间让用户下单；

机器催付即自己的催付系统，包括用户催付未生效或者未催付导致的用户没有第一时间下单（例如没有当天），则系统会以App推送+短信、App内部的弹窗提醒等的方式来提醒用户。

3、老用户优惠券的生成及发放规则：

优惠券的有效期为7天，所以要想省这3元，就需要7天内完成一单。

这里我尝试找了附近的汉堡王门店，点一单最少需要20商品费+6配送费-3优惠券=23元（所以肯定能满足实付7的，就算减去了15元新人红包，也还有8，刚好超过7；二单用户自选店铺，就算有满减，加上优惠一般也很难低于10）；

并且此店铺距离我2.6公里，算中等距离的配送了；所以这里涉及两个，该基于位置给用户送什么店的券，送的券应该是多少钱，并且计算好用户需要付的价格是多少钱应该是最容易引导下单的。

实现方法：

流程图内有呈现，检测用户、定位等然后根据优惠券计算规则发放券即可；

这里可能需要统计用户数据行为，通过算法计算预测用户最容易下单的店铺及金额，然后对应生成；（这里三节课数据分析师P1的课程即有讲解，例如员工离职率分析，单车用户打分预测）

例如这里我计算的首单最贵是23元，最便宜是8元，也就是说一定是大于实付7元的，只需要催付即可。

4、活动页面的获奖推送：

这里的推送提示在一般活动页面都有涉及，主要是告诉用户已有的获奖用户和获奖情况，来促进用户对于活动的参与度，比如推送上会提示当前xx得到了xxx金额现金；

实现方法：

可以做用户名的随机生成（或者从其他地方找）+金额范围的随机（设置不同金额出现的概率，例如大金额概率设置高），然后呈现在活动页面。

5、通讯录权限读取的推荐：

饿了么可能想到用户不确定身边哪些人还没注册过饿了么，毕竟饿了么当前的覆盖量也不少了，所以帮用户想了个办法：App直接读取用户的通讯录。没有注册过的饿了么会给一个列表，用户可根据列表针对性邀请（这里为了清晰可见，我特地做了对比）。

实现方法：

读取通讯录权限，通过API上传通讯录进行匹配，新用户则返回是（例如是新用户则返回True），然后给加入到“我的好友”的可邀请队列；

iOS是邀请发送微信消息之类，安卓我还没尝试，如果App流氓一点，是可以直接点击邀请跳转到发送短信的（安卓可以直接设好内容直接发送）。

6、最低提现额的限制：

饿了么最低限制10元提现，最高提现10元，且每日仅可提现一次，什么概念？

这里我简单邀请了几个用户，前两个为老用户，最后一个为新用户，估算了下，最高15元，很有可能是“5+10”的形式，首单5元，二单10元。也就是说用户想要提现，至少得完成1个新用户的首单+二单，或者4个新用户的首单，或者1个新用户的首单+二单+另一个新用户首单；

同时如果用户第一天邀请了n个用户，n个用户带来的奖励大于50，则会导致用户第二天继续打开App进行提现；

二单的奖励会促使邀请者尽快完成新用户的二次成交，同时剩余的可提现金额也会让邀请人继续邀请用户（沉没成本虽然不是成本，但是依然会让用户继续考虑消耗掉沉默成本带来的影响）。

实现方法：

这里其实是一个任务墙的形式，产品方想要用户留存和成单，也给了邀请人两个指标。

就像是师徒系统，师傅邀请徒弟，徒弟需要完成任务1或者任务1+任务2（例如实名+成单）然后师傅得奖励，也像任务墙为了满足产品方的留存需求，在用户完成第一天的下载激活以后，再给用户基于当前奖励的20%给予二次奖励来让用户第二天继续打开App。

附1：关于赚钱攻略

这里我不太认为是一个亮点，但是觉得又必须得拿出来说明下，它像是邀请被邀请时必备的操作流程说明，是本该设计活动时就有的。

至于这里我拿出来说是因为还有些活动设计时并没有考虑到这一点。

正常设计活动时，非常容易发生产品或者运营觉得简单的事情，但用户无法操作起来的情况。所以有一个图文或者视频的引导告诉用户流程，化简为繁是一件非常必要的事情；况且一般的活动规则为了尽可能避免活动出现意外，都会附有一堆说明规则、解释要素，但用户是不会逐条看完的。

实现方法：

给予一个图文的操作流程说明，步骤简单，对于核心的步骤必须详细说明，例如必须要被邀请人通过二维码或者链接注册等；

同时如果资源到位，也可以通过录屏说明等来具体解释每一步操作的情况，尽可能降低邀请人参与活动的成本，被邀请人与邀请人操作过程中的沟通成本。

附2：关于邀请标题文案及icon

上面呈现的是饿了么朋友圈邀请和好友邀请的示例，均有icon及推广标题，这里也是同附1一样容易被忽略的地方，好的文案标题和icon能提高用户点击链接的转化，有了第一步的点击才可能有后续的转化，特别是朋友圈分享这一动作。

实现方法：

设定好多套转发文案标题及icon，与技术沟通做好A/B测试，得出最优的方案后上线；也可以在线上做时继续优化，提高页面的点击率。

三、关于这个活动的一些延伸思考

最后，来聊聊邀请奖励活动中的反作弊方案。

1.饿了么的请求和返回参数

这里我检查了饿了么页面上的一些参数，下方截图为请求参数截图：

上面这张图是请求链接的参数图，为了方便呈现，我修改了#为&；from参数为来源，这里应该为微信+QQ+链接等，根据链接参数看到是“单个消息”，这个请求链接是我从微信内复制出来的（我点击了其他人分享给我的邀请链接，复制出来的是点击后变更了的）；

isappinstalled参数为是否安装了App，因为涉及到注册以后需要打开App，所以链接上直接做了是否安装App的判断，但是实际判断并不准，我安装了但还是打开了App Store；

refer_id参数是邀请人的ID，用来判断是谁邀请的被邀请人；

refer_channel_code参数是邀请渠道代码，refer_channel_type参数是邀请渠道类型，这里我没做具体的了解，猜测渠道代码是微信/QQ/链接，渠道类型是例如微信的个人邀请/朋友圈邀请；

上面是邀请链接的参数情况，下面是页面请求的参数情况。

页面参数上我截图了一个来源和是否直接打开的判断，请求链接带了用户当前的访问情况、邀请人ID等（截图的是返回参数情况），返回了用户当前是否是App直接打开的等；

2.关于饿了么方案的思考

由于此类方案分享后大多基于web进行操作（注册在web，下单在App），所以统计用户设备上不是那么容易，特别是唯一标识符等，所以通过用户后端行为来进行判断则成了一个较好的方案。

例如饿了么提出的：饿了么新用户是指设备号、手机号、饿了么账户（包含第三方账户）及支付账户均未在饿了么外卖任何平台下过单的用户。

最后，如果要做好非常严格的反作弊，首先在规则上要说明，其次在技术上可以分为以下四个方面：

1. 检测用户ip，设备信息/浏览器标识；判断一个设备注册了多个账号邀请被邀请则为异常情况/判断本身是应该手机端浏览的页面大量出现电脑浏览器访问的则为异常情况，判断一个ip大量出现注册邀请被邀请则判断未异常情况（可以随机抽取用户电话回访）；

2. 类似饿了么的检测用户设备，ip，手机号，第三方账号，支付账号等未出现过的；

3. 检测用户行为，例如用户注册后再也未登录，是否一个渠道或者用户邀请来的都是此类用户（此处更多应用于数据分析建模后）；

4. 芝麻，活体检测（普通实名可以盗用，活体不好破解），用户通讯录检测是否存在欺诈用户，手机号异常（卡商、猫池），ip异常（代理ip，匿名ip），身份冒用等等，这个属于难度最高的了，不过都有现成的接入服务，或者SDK之类的。

作者：三节课

来源：三节课