|
领取条件的多样化设置，虽然保证了红包发放者足够的娱乐体验收益，但难免会加重了领取端的参与成本。 
红包的领取 领取红包是另外一个核心场景之一，决定了红包的互动娱乐效果。从领取场景来看，可以分为直接领取和条件领取： - 直接领取顾名思义用户无需额外的操作条件;
- 条件领取则要求用户在领取红包前需要完成额外的操作步骤，如：分享链接、回答问题、上传图片等，才能最终领取红包奖励。
例如： - 陌陌的任务红包：领取者需先上传图片，待发放者审核后才能完成最终领取)
- 饿了么订单红包：必须分享先完成分享操作，才能从分享链接中领取自己的红包(卡券);
- 除此之外还：限制领取用户的性别、是否关注(包括领取后默认关注)、领取之后自动回复口令等。
红包的传播 C2C类红包鲜于强调传播，因其往往是基于固定社交圈子的一种互动手段，更重要的是，谁也不希望自己的无缘无故被“传播”出去。 但在大部分B2C类红包玩法中，会侧重于引导用户进行社交传播。常见 3 种引导方式： - 分享红包链接之后才能领取红包内的奖励。分享操作作为一个必要领取条件。此方式常见于各类电商平台购物后，平台赠送的购物红包，需要先进行分享操作后才能领取红包内的优惠券。某年的微信新年摇一摇红包也有类似的分享条件设定。
- 用户在领取种子红包可以选择分享邀请好友“集赞”，集赞数会影响红包金额的增加，以此来刺激用户自发传播。
- 分享红包链接可以获得赠送的额外拆红包机会。
凡此种种，无不是基于“利益”和少许的“情感”刺激，让用户不断地分享传播红包活动，达到“病毒式扩散”的效果，增加红包活动的最终曝光量。可能一个红包由平台导流只有 100 万初始用户，经过用户自发传播后，最终吸引额外的 500 万用户来参与。 
红包的引流 与C2C类红包强调用户群体之间的“自嗨”不一样，B2C类红包几乎自被PM们设计之初，就植入了营销引流与转化的“使命”。 拆红包出现：满XX减XX优惠券、XX7 天体验权等字眼是不是相当熟悉。对，没错，分发代金卡券、兑换码是这类红包的常见使命。 除此之外，这种红包界面往往还有显眼的按钮，帮你一键跳转消费场景;或是嵌入一个“商品/服务”推荐专区。 当然这是又硬又粗暴的引流转化而已，还是会有相对温柔一点的方式，红包页面的关键位置会被巧妙地植入“广告品牌元素”，潜移默化用户心智。 
2.2 红包的逻辑以上是从红包产品的体验动线场景出发进行功能点的归纳总结，体验动线背后是功能实现逻辑。因为两类红包的产品形态有相对明显的差异，故分开阐述： C2C类红包 这类红包的主要差异点：收发两端都是个体用户，红包奖励均为现金(钱款)。 因此这里涉及的交互设备包括：用户客户端、红包产品服务器、银行服务器。 实际中处理红包不同功能服务会有多种服务器协同完成，这里仅作统一简称，下文同。由于不同类型红包产品的功能逻辑有所差异，为简化描述(实际是笔者偷懒)，将不同类型红包的功能逻辑合并至统一描述。本文意在归纳总结，并非严格需求文档。
发放(生成)红包端流程： - 客户端：用户打开包红包页面，填写本次红包的相关字段(必要字段和非必要字段);客户端校验字段数据填写是否有效
- 红包服务器：响应本次请求;生成唯一的红包id;返回红包信息与相关支付信息给客户端
- 客户端：用户确认支付
- 银行服务器：完成扣款或扣款异常
- 红包服务器：生成红包或提示支付异常信息
领取(拆)红包端流程： - 客户端：用户打开红包消息;请求查询红包是否领完、用户身份有效性
- 红包服务器：返回红包剩余数量、用户身份有效性
- 客户端：红包被领完;红包未领完但用户身份无效;红包可领，展示红包任务页，完成指定操作(回答问题、上传照片等)
- 客户端：完成领红包任务操作(回答问题、上传照片等)
- 红包服务器：下发消息通知发红包者进行任务审核;或再次查询红包剩余数量，并执行红包抽奖算法，返回红包中奖信息
- 客户端：根据返回结果显示已经领完或者红包金额;钱包余额更新
B2C类红包 这类红包的主要差异点：发放端一般为平台方、领取端为个体用户、红包奖励类型多样化(现金、卡券、兑换码、虚拟特权或道具) 因此这里涉及的交互设备包括：用户客户端、红包产品服务器。 发放(生成)红包端流程： - 红包活动系统：填写本次红包相关字段：id(或系统生成)、有效时间范围、参与用户群(或通过用户身份判断接口实现)、红包奖品列表(种类、数量、中奖概率)、奖品数据包(兑换码类奖品);系统校验字段有效性
- 红包服务器：生成红包
（编辑：源码门户网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
