【产品分析】微信拼手气红包的贪嗔痴

春节期间火爆的“拼手气”红包，让用户疯狂点击拼手速网速，拼rp看金额，每一个环节都深深戳着用户的G点，高潮迭起。

高潮之后的楼主浅显地对这产品进行若干分析梳理。

注：文章多图，加载较慢，见谅

【用户侧体验】

首先从前向的用户体验下手，一个普通用户，从微信群聊天框功能菜单中使用红包功能即可进入群红包设置界面（更新后，操作简便，过程更流畅），且默认是拼手气玩法（群红包核心玩法，有趣且互动性强），另外可以选择普通红包（金额不随机）。用户填充相应的数字，编写祝福语，完成支付即可发送红包到群里，和朋友拼手气开抢。

拼手气红包玩法主要有三条规则

①拼手气红包数量的区间为：

（0，100]

②单个红包金额的区间为：

[0.01，200]

③单次支付总金额的区间为：

[0.01，5000]

第一条，数量为什么不能自定义而是设置了100的上限呢，其实很简单，和当初微信群的容限一致。基于强关系的微信群，能达到40人互相认识已经是难事，更别说100人。但是迫于次级关系延伸的需求，才开发到500人上限，而且只能手动邀请且开通微信支付。显然微信团队不希望看到太多“伪强关系”出现而破坏其生态平衡。那么基于微信群的电子支付玩法，有着更强的安全性需求，自然要符合这一逻辑。

第二条，为什么要包括几乎没有流通价值的1分钱，陌陌的红包则是0.1元起。楼主猜测，部分原因是为了降低用户的参与门槛，尤其在早期推广时候，知名度不高。电子支付安全性、金钱敏感等问题在前，花几毛钱可以几十个红包给好友抢，好玩之余用户不用过于担心钱包压力，不失为一个妙策。

第三条，更多是第三方支付的“原罪”，涉及到银行利益、储户资金流动等问题，当然也有部分原因是和红包玩法的安全性、实际需求挂钩，作为节日调节气氛，朋友互动的玩法，开通大额度的红包意义不是很强，这样的需求还是留个转账等专业功能为好。

新版的红包UI除了变得更加扁平之外，似乎有意弱化转发的功能？以前是基于H5web，无论是刚生成红包还是群红包未完全领到的时，都会有明显的转发引导。在新版红包UI中，在底部有一行小字说明红包未领完的情况下可以继续分享。包括楼主在内一些同学，找红包转发的按钮找了半天。相比旧的web转发，新的红包产品不需要调用右上角的分享控件。于是楼主猜测：新的群红包UI，倾向引导用户在当前群环境中完成，而非到处分享，稍稍规范红包的传播。

新版红包还有一个小细节比较有趣，就是发红包者可以直接看到领取者的名单。这个功能目前体验最深刻的就是发数量多的群红包，可以看到不断有领取消息弹出，非常酸爽。还可以直观看到最先领取红包的那几位朋友（数量多时，往往没什么耐心看完），红包领取结束标记，除此之外似乎还有轻微的视觉干扰，而且该显示只有发红包者才能看到，红包领取结束的标记功能稍显鸡肋，对于迟来的用户需要逐个点开才可以确定是否被领取完，繁琐，能否将领取结束标记设置为全员可看呢。你是怎么想的呢？

插个题外话，借助这一功能，楼主发现一个”bug“，上述领取名单和实际红包领取目录略有初入，下图栗子。按常理来说，越早领取的用户在红包界面排的越靠后，但是下图的（四个红圈）。因为时间没有精确到秒，看不出实际顺序，只能抛砖引玉。

用户设置好拼手气红包发送到群里之后，便是一顿”腥风血雨“。拼网速、拼手速、拼运气。拼手气玩法和一般红包的最大不同就是手（随）气（机），抢到之后用户往往会对比一下谁拿多谁拿少，甚至还延伸出抢得最多的那位“接龙发红包”的玩法，那为什么会有人抢得多，而且多那么多呢？

【后端侧的random处理】

拼手气的核心体验是：random，对于结果不确定性以及明确的可能性，用户总是乐此不疲，类似赌徒心理。但是不是什么随机概率都可以呢？显然不是。这里涉及到”random“的具体表现形式，楼主归纳如下：

①完全random分布（表现为：完全的随机，没明显的数据聚合）

②正态分布修正的random分布（表现为：大部分人拿到的金额在均值附近，少数人拿到的金额多or少）

③反正态分布修正的random分布（表现为：大部分拿到的金额都比较偏离均值，少数人拿到均值附近的金额）

楼主采访了十来位没有明显的观察和数据分析之前的用户（包括：ITer、普通学生、一般社会人事、长辈，样本极少，仅作栗子），意见都比较统一在认为拼手气的random是正态型，引用一位朋友的话“大家拿差不多的话不会太在意得失，少部分人可以刺激一点”。事实是怎样的呢？数据说话：

1

实验1

总金额：100

数量：41

均值：2.439

频次间隔：均值4分，即0.60975。上标界为2倍均值，下标界为0.

曲线拟合：多项式

图1：红包金额时序分布和升序处理

图1中的上图，是实验1最原始的数据，按时序记录每一个被领取的红包金额。红色线为均值，可以直观看出，领取红包的金额和领取时间没有严格关联性（后文进一步举例说明这点，网传领取时间越靠后金额越大）。单对金额项进行升序处理，得到下图，金额小于均值的红包数量与大于均值的红包数量大致相同（实际为：19：22），且曲线比较线性（低于均值部分的曲线和均值线、坐标轴围成的形状与高于均值的情况比较吻合）。

由图1说明：红包金额可能存在“对偶化”，即误差允许情况下每个低于均值的金额总有一个高于均值相同绝对值的“对偶”金额出现。

(备注：记录操作原因，图1中图表横坐标数字越大表示领取红包时间越早！后文类似图表寓意相同，不在说明）

图2：频次统计直方图

用均值4分的区间去统计金额出现的频次，得到更能体现random概率的图2。出乎意料的是，图2反映出在紧邻均值的两个区间的频次统计居然是最少的，金额从少到多的频次统计大致出现先减后增的情况。

图3：频次统计散点图和多项式曲线拟合

用多项式曲线拟合，顺序值为6，可以得到图3。Totally是一个反正态模型（楼主自己脑补的词，嘿嘿）。有人会好奇尾部的缺陷，那是因为楼主将最后包含2倍均值的区间拆成两部分。如果合起来，整个曲线会更加接近“倒钟型”。

由图2、3说明：可能存在反正态分布的random，让用户抢到大金额、小金额的多，均值金额附近的少。如果是真的设定，也够奇葩了，反正我猜不出来为啥这样做。

2

实验2

总金额：20

数量：80

均值：0.25

频次间隔：均值4分，即0.0625。上标界为2倍均值，下标界为0.

曲线拟合：多项式

图4：红包金额时序分布和升序处理

图4采用图1相同的处理方法，得出来的图形也基本和图1类似。

图5：频次统计直方图

进入频次统计，又是让楼主受jing的节奏，这一眼看去，有几分正态分布的趋势。除了中间有一个偏差较大的凹陷（为紧邻均值的高区间）。

图6：频次统计散点图和多项式曲线拟合

多项式曲线拟合之后，可以看到一个类似有着大σ的正态分布的曲线。（一万头神兽在楼主心中奔跑，→_→）。

图5、6说明：可能有类似正态修正的random分布，还说明可能有着两套截然不同的random模型。

是样本偏差还是真的有两套修正模型?如果有，意义何在？

两个实验却得出相反的结论，在纠结之前，我们不妨先回头拆分一下拼手气红包的可能性以及相关的用户体验。

控制拼手气红包有两个参数：数量和总金额。由两者结合random算法得出每次红包的具体金额。从这两个参数下手，可以归纳出：

①数量多，总金额少：直接导致random均值小，间接导致random范围小。例证：10元5个的拼手气可以出现0.01元的红包，其均值为2元，变化范围1.99。1元5个的拼手气均值为0.2元，变化范围为0.19（这是前者的十分之一）。random范围会影响到整个分布的涨落情况，极端例子是均值为0.01的拼手气，分布涨落为0，所有人拿到的都是0.01。

②数量少，金额多：直接导致random均值大，间接导致random范围大。可以出现更多随机可能性，整个分布的涨落也比较大。楼主曾经看过一个10元5个的拼手气：一个用户单独拿了7+。

③其余两种情况现象不明显，暂且不讨论。

针对①、②种情况和上文两个实验的结论来看，就可以得出一个比较有逻辑的猜想：

对于①情况，如果用类反正态分布，两极化效果难以得到，一旦出现一个多倍甚至十多倍于均值的金额，往往需要大量低于均值的金额出现才能填补空缺。而大量的低价红包肯定会影响用户的体验。所以这类情况，适宜用正态修正。

对于②情况，其实用哪种修正都可以，但是如果用类反正态分布，可能会带来更多的刺激感。

至于什么时候用哪种random修正方案，取决于（总金额）/（数量）的值的大小。

以上是关于random模型的一些分析和猜想，接下来网上还流传一个说法，抢红包的先后会影响金额的大小。为此楼主拿出13个同类型的实验数据来观察：

总金额：10

数量：5

均值：2

次数：13

备注：一小时内发送的拼手气红包，少数为连续发送。

楼主将每次拼手气红包中的最佳手气数据标为白底色，可以明显看出13个实验里面，各个领取时间的最佳手气数量无明显差异，且可以看出似乎每个拼手气的最佳落在哪个时间是有一定变化规律的。反过来想，抢红包的时间普遍在10秒以内，如果用时间来控制最佳手气的产出，那这样做的意义有多大呢？用户掌握之后施行的操作成本又有多高？毕竟微信团队还是信奉“在你身边，为你设计”。

最后补充一个小细节，同等网络情况下（相同局域网但排除手机硬件问题），发包者总是可以抢到红包。而且在抢红包高峰时候依然成立。如果这个现象是确实存在，楼主猜测红包random的过程是在客户端完成。发包者填充好各类信息之后确定发送，客户端执行random算法，配置各类数据然后发送到服务器（服务器直接收总金额、数量和random后的红包list），再转发到其它客户端配置显示相应的红包。而发包者无需后面一步，本地random完直接显示即可点击拆包，自然会比其它用户快一截。如果真的是这样，那能否修改客户端的一些算法，识别出list中哪个红包最大，并默认发包者可以抽到这个。

结束语

分析了这么多逻辑，最终还是要落到“用户体验”四字上面，无论前端的如何优化，后台random是否有多套修正法则，都是为了提供更好的用户体验，让用户简单、安全地体验到刺激的拼手气玩法，相信这也是这个拼手气红包产品团队的目标吧。

本文章所有数据源自于楼主亲测所得（不说了，剁手吧 TT），但可以发现数据样本的总金额（均值）依然较小，非常可能会出现误差，以及分析不够全面，不妥当之处希望看官及时指正。

最后的最后：

觉得文章数据对你有帮助，可以长按下图打赏楼主1毛钱。射射_(:зゝ∠)_

关我毛事

点击屏幕右上角查看公众号或者复制：guanwomaoshi

可以关注本人，查看更多有趣的文章

原创·分享·关注你所想

IT圈内人，积极上进，偶尔说说产品、聊聊电商、谈谈游戏，我是一个很严肃的人！