凡此种种，无不是基于“利益”和少许的“情感”刺激，让用户不断地分享传播红包活动，达到“病毒式扩散”的效果，增加红包活动的最终曝光量。可能一个红包由平台导流只有100万初始用户，经过用户自发传播后，最终吸引额外的500万用户来参与。

　　>>红包的引流

　　与C2C类红包强调用户群体之间的“自嗨”不一样，B2C类红包几乎自被PM们设计之初，就植入了营销引流与转化的“使命”。

　　拆红包出现：满XX减XX优惠券、XX7天体验权等字眼是不是相当熟悉。对，没错，分发代金卡券、兑换码是这类红包的常见使命。

　　除此之外，这种红包界面往往还有显眼的按钮，帮你一键跳转消费场景；或是嵌入一个“商品／服务”推荐专区。

　　当然这是又硬又粗暴的引流转化而已，还是会有相对温柔一点的方式，红包页面的关键位置会被巧妙地植入“广告品牌元素”，潜移默化用户心智。

　　2.2 红包的逻辑

　　以上是从红包产品的体验动线场景出发进行功能点的归纳总结，体验动线背后是功能实现逻辑。因为两类红包的产品形态有相对明显的差异，故分开阐述：

　　>>C2C类红包

　　这类红包的主要差异点：收发两端都是个体用户，红包奖励均为现金（钱款）。

　　因此这里涉及的交互设备包括：用户客户端、红包产品服务器、银行服务器。

　　实际中处理红包不同功能服务会有多种服务器协同完成，这里仅作统一简称，下文同。由于不同类型红包产品的功能逻辑有所差异，为简化描述（实际是笔者偷懒），将不同类型红包的功能逻辑合并至统一描述。本文意在归纳总结，并非严格需求文档

　　发放（生成）红包端流程：

　　--客户端：用户打开包红包页面，填写本次红包的相关字段（必要字段和非必要字段）；客户端校验字段数据填写是否有效

　　--红包服务器：响应本次请求；生成唯一的红包id；返回红包信息与相关支付信息给客户端

　　--客户端：用户确认支付

　　--银行服务器：完成扣款或扣款异常

　　--红包服务器：生成红包或提示支付异常信息

　　领取（拆）红包端流程：

　　--客户端：用户打开红包消息；请求查询红包是否领完、用户身份有效性

　　--红包服务器：返回红包剩余数量、用户身份有效性

　　--客户端：红包被领完；红包未领完但用户身份无效；红包可领，展示红包任务页，完成指定操作（回答问题、上传照片等）

　　--客户端：完成领红包任务操作（回答问题、上传照片等）

　　--红包服务器：下发消息通知发红包者进行任务审核；或再次查询红包剩余数量，并执行红包抽奖算法，返回红包中奖信息

　　--客户端：根据返回结果显示已经领完或者红包金额；钱包余额更新

　　>>B2C类红包

　　这类红包的主要差异点：发放端一般为平台方、领取端为个体用户、红包奖励类型多样化（现金、卡券、兑换码、虚拟特权或道具）

　　因此这里涉及的交互设备包括：用户客户端、红包产品服务器。

　　发放（生成）红包端流程：

　　--红包活动系统：填写本次红包相关字段：id（或系统生成）、有效时间范围、参与用户群（或通过用户身份判断接口实现）、红包奖品列表（种类、数量、中奖概率）、奖品数据包（兑换码类奖品）；系统校验字段有效性

　　--红包服务器：生成红包

　　B2C类红包的生成端往往由平台方负责完成，对于已经成熟工具话的B2C类红包，红包字段的录入也通常在红包活动系统中填写（简直就是PC版的发红包页）；而一次性或未固化的产品，则需要产品或者运营提前将红包字段确认好后提交给开发写死在红包功能的代码里面（当然并不是完全的写死，只不过每次修改都要重新发版而已，然而开发最不乐意反复发布）

　　从某种程度来说，该类红包也就是一种“抽奖活动”。

　　领取（拆）红包端流程：