正文
发放（生成）红包端流程
：
--客户端：用户打开包红包页面，填写本次红包的相关字段（必要字段和非必要字段）；客户端校验字段数据填写是否有效
--红包服务器：响应本次请求；生成唯一的红包id；返回红包信息与相关支付信息给客户端
--客户端：用户确认支付
--银行服务器：完成扣款或扣款异常
--红包服务器：生成红包或提示支付异常信息
领取（拆）红包端流程：
--客户端：用户打开红包消息；请求查询红包是否领完、用户身份有效性
--红包服务器：返回红包剩余数量、用户身份有效性
--客户端：红包被领完；红包未领完但用户身份无效；红包可领，展示红包任务页，完成指定操作（回答问题、上传照片等）
--客户端：完成领红包任务操作（回答问题、上传照片等）
--红包服务器：下发消息通知发红包者进行任务审核；或再次查询红包剩余数量，并执行红包抽奖算法，返回红包中奖信息
--客户端：根据返回结果显示已经领完或者红包金额；钱包余额更新
>>B2C类红包
这类红包的主要差异点：发放端一般为平台方、领取端为个体用户、红包奖励类型多样化（现金、卡券、兑换码、虚拟特权或道具）
因此这里涉及的交互设备包括：用户客户端、红包产品服务器。
发放（生成）红包端流程：
--红包活动系统：填写本次红包相关字段：id（或系统生成）、有效时间范围、参与用户群（或通过用户身份判断接口实现）、红包奖品列表（种类、数量、中奖概率）、奖品数据包（兑换码类奖品）；系统校验字段有效性
--红包服务器：生成红包
B2C类红包的生成端往往由平台方负责完成，对于已经成熟工具话的B2C类红包，红包字段的录入也通常在红包活动系统中填写（简直就是PC版的发红包页）；而一次性或未固化的产品，则需要产品或者运营提前将红包字段确认好后提交给开发写死在红包功能的代码里面（当然并不是完全的写死，只不过每次修改都要重新发版而已，然而开发最不乐意反复发布）
从某种程度来说，该类红包也就是一种“抽奖活动”。
领取（拆）红包端流程：
本流程与C2C类红包比较类似，最大的区别点在于：用户在点击拆红包按钮后，红包服务器判断该红包未领完后，会调用红包抽奖服务，按照该红包生成者设定的概率进行随机抽奖并根据抽奖结果再调用奖品发放服务（不同类型的奖品则有各自的发放逻辑）：
（1）现金类则如C2C类红包，通过内部支付接口对用户钱包余额进行充值相应的金额。
（2）卡券类则调用发券接口进行发放到用户的卡券包中。
（3）兑换码类则稍微有点麻烦，还需要从兑换码数据库中按预设的顺序取一个出来返回给客户端展示。
（4）虚拟特权或道具与卡券和兑换码比较类似，常采用这两者之一来代替实现。
众多类型的奖品导致这种红包需要调用更多额外的服务接口。实际运营上，往往还涉及和第三方企业合作的项目，这时候还会涉及调用一些第三方服务接口。
并且如前文提到，B2C类红包往往和节庆日活动结合，会有更加明显的
“运营节奏”
，不同活动阶段可能还会设置对应的发放逻辑：如定时概率调整、奖品种类上下架、受众群区分等。
这是有别于C2C类红包的功能特色，但往往不一定是开发GG所喜欢的（一个小小的红包，需要那么多这样那样的判断逻辑与分支处理，还能不能愉快玩耍了）。
以上是产品功能逻辑上对两类红包产品进行梳理归纳。
值得一提的是，为了体验的流畅性，大部分红包都采用了
异步发放奖品
的策略，即客户端显示中奖结果时，此时奖品不一定发放到账。当然这对于日常体验来说，几乎不可能发觉。
红包玩法诞生至今以走到第三个年头了，依然有各种企业各类产品在更新提示中著名：上线XX红包功能。说明天朝网民还真的是非常热衷参与“红包大战”的。
第三章：红包的“微创新”：案例浅析
3
.1
微信系
>>拼手气红包
微信系红包中，最容易“上瘾”的玩法应该就是拼手气红包，因为每个子红包金额随机、金额最高的专属标志、极具话题性的红包领取信息列表，深深击中用户的贪嗔痴，让抢与开的每个瞬间都让人肾上腺素爆发。并有“聪明”的网友利用玩法特点，开辟出：接龙、炸弹、大小点、奇偶数等玩法，甚至公然用红包来进行赌博。
早些年，曾有在知乎开题讨论拼手气的随机算法，包括笔者在两年前也做过类似的分析。而坊间流传过：X数一轮手气最佳的说法，足见这个玩法多么让人痴迷。现在也成为红包类产品标配功能之一。至今笔者都认为，拼手气红包是最佳的社交互动玩法，没有之一。
>>春节摇一摇红包
最早进行招商合作的红包产品应该就是微信春节摇一摇红包了。从纯粹的社交互动玩法，蜕变成一个社交营销“神器”，以一己之力强行推动了SNS营销行业的进步。
招商合作的模式
：
（1）引入外部优秀合作伙伴的营销资源，
一起“做大”整个红包的奖金池
，打造行业标杆与营销噱头点
（2）通过品牌元素植入红包页的方式为合作伙伴带来巨额流量曝光
（3）支持发放卡券类奖品，提供有效的流量转化方式
以上模式也几乎成为其他平台红包产品竞相模仿的“标配”。继“双十一”以外，又成功造了新的“营销节日”。
>>朋友圈照片红包
“想看yu照么，先来打赏”，这是2016年春节期间曾经流行过的话题。朋友圈发出的图片被打上马赛克，需要支付一定金额才能“解锁”，又再一次击中大众的“猎奇心”。
笔者以为陌陌上这样的功能还稍显合乎用户群体的偏好。微信来做，而且还是关系链亲密度最高的朋友圈中推出，“我当你是朋友，你连个照片都要先付钱才能看？”。
而实际上，整个功能上线没多久之后又下架了，似乎微信内部也没完全认同这个功能。本质上，这是支付现金购买照片的浏览权。
这个功能，笔者推演出两个需求逻辑：
（1） 这张照片对主人来说比较珍贵，不是轻易分享出来，于是设置了这个支付现金的门槛，过滤出对我真心诚意和愿意为我付出的“好友”。
（2） 这张照片对“部分好友”来说有一定消费价值，主人是在出售照片这个“商品”。支付门槛是保证自己在这桩“买卖”中不吃亏。
很明显，逻辑1是矛盾的，珍贵私密的东西一般不会在朋友圈这种相比于IM更加开发的空间中发出。于是乎，用户都奔着逻辑2去玩了。而逻辑2中，最“吸睛”的自然就是黄色照片。但除了少数非法牟利分子，大部分参与的用户都是打着“擦边球文案”来晒出一些无关痛痒的图片，于是引得无数付费用户骂声一片。
失控，由此而来。
微信红包照片虽然“短命”，但是红包+X的玩法，为其他红包产品提供了很好的借鉴思路。
3.2 QQ系
>>口令红包
如果说到聊天场景中有什么行为让人又爱又恨，“跟队形灌水”大概是最普遍的情况之一，大量无营养统一复制粘贴的内容充斥于正常的聊天信息流，类似线下聚会中的“起哄”，仿佛非常热闹却又十分尴尬。而QQ口令红包则通过金钱刺激加剧了这一现象。
QQ口令红包的本质还是拼手气群红包，额外的玩法是：用户领取红包前需要先回复一条口令消息，该口令文案由发红包者自定义编辑。体验来说就是群成员一边欢快地抢红包，一边自动跟队形灌水，灌水剧烈程度正比于红包个数。
没错，口令红包就是这么粗暴地“插入”信息流中。对于群聊信息流，红包口令犹如一道催化剂。
积极正向的口令文案在某种程度上可以增加群聊的趣味性，常见的节日祝福场景，若是普通群红包，群友不明就里看到红包消息点开抢完可能就匿了，或者发句谢谢老板和表情，但是强制口令消息形成的“刷屏”效果无疑在短时间内营造出一个群活跃小高峰。
但是金钱刺激之下，用户往往来不及细看口令文案就直奔拆红包，带来的恶果就是被别有用心的人坑了一把，“我爱吃翔、请插我”等恶俗口令充斥于聊天信息流，也使那些领了红包上当的用户懊恼不已（详见知乎QQ口令红包话题），当然少不了还有用来发布广告内容的口令等。
红包产品做出新玩法是好事，但是也得找准落地场景，或者反过来说，该场景下增加红包玩法需要注意什么细节。
>>刷一刷红包
手Q刷一刷红包属于在领取入口的交互方式时进行创新的B2C类红包。春节活动期间，在手Q首页下拉刷新，有机会刷出红包。这个玩法有趣的地方就在于将红包作为彩蛋植入到手Q下拉刷新的场景中，刷一刷有机会出现红包并抽中各类奖励。
下拉刷新这个操作是手Q的基础功能，利用用户早已熟悉的场景作为春节红包活动的入口，并将下拉刷新的UI与动效都统一做了节日氛围改造，营造出如同游戏pk中的“combo连击”效果，的确是一个非常有意思的领红包创意。
这应该算是在手Q没有摇一摇功能的“先天缺陷”下，产品设计者用更符合手Q用户操作习惯的玩法方案完成一次漂亮的“逆袭”。
>>空间动态红包
QQ空间动态目前上线了3种“小红包”玩法，分别是：问答红包、口令红包、DIY红包。这3种红包玩法主要是基于拼手气和固定金额的群红包玩法进行的微创新。
（1）
问答红包：
在创建红包过程中，发红包者可以自定义一道问题。领红包时，用户需要回答问题后才能领取红包奖励，回复的内容会作为评论展示在该红包动态下。
空间动态的问答红包将回答问题领红包的做的比较轻量，不强调回答内容的准确性（不支持设置问题答案，也不需要审核回答内容），领红包的参与门槛相对没那么高。但如果仅仅是通过红（金）包（钱）来吸引一波好友来回答问题，似乎也只是营造了针对某一话题的短暂狂欢。而且可能是笔者的关系链基本都迁移到微信，发出的几个空间红包，鲜有互动。可玩性好像差强一点。
（2）
口令红包：
类似QQ的口令红包，在创建红包过程中，发红包者可以自定义一道口令。领红包时，用户需要确认回复口令（只需确认，口令内容由系统自动发出），才能领取红包奖励，回复的口令会作为评论展示在该红包动态下。
（3）
DIY红包：
在创建红包过程中，用户可以自定义红包封面图片和封面装饰物（部分装饰物需要开通黄钻），设计出个性化的动态红包。
这算是QQ系产品一贯的套路吧，
结合黄钻特权的装扮个性化增值服务
。
>>天降红包
AR是近年大热话题，随着PG的火爆，LBS+AR的套路正被越来越多地应用在互动功能上。QQ天降红包也衍生于此。
