【产品】功能设计-餐饮app优惠券发放H5

写于入门课程第六周
2018.10.25

你是某餐饮类app的产品经理，由于公司推广需求，现在需要设计一个针对新老用户发送优惠券的H5界面，用于微信里用户自发的分享传播。
要求：
以H5为载体
两种分享模式：微信聊天窗和朋友圈

---

XX餐饮app-优惠券发放H5需求文档

2018.10.19
文档版本 v1.0

索引

1. 项目背景
2. 需求分析
   2.1 竞品功能调研
   2.2 用户-场景-问题-解决
   2.3 需求优先级
3. 本次需求目的与功能列表
4. 流程与所处的模块关系
   4.1 业务逻辑
   4.2 业务流程
   4.3 页面流程
5. 功能详述
   5.1 App后台
   5.2 H5页面
   5.3 App前端
6. 考核指标

1. 项目背景

公司运营部门提出，需要设计一个发放优惠券的H5页面，用以让用户在微信中分享传播，通过优惠券提高app内的转化率，以及吸引更多新用户达到推广目的。

2. 需求分析

2.1 竞品功能调研

本项目的任务不是培养用户的新习惯，我们的用户必然是已经有app点单经验的群体，以下以美团外卖、饿了么两款成熟产品为例调研其优惠券发放功能作为参考。

2.1.1 共同点

美团外卖与饿了么都有以下几种红包，两款产品相应红包的规则和流程大体一致，这些共同点体现了红包功能的基本逻辑。

a. App内部优惠：

• 新人礼包、日常福利包、店铺红包、会员红包套餐、兑换红包……
• 种类繁多，两个app各有特色；
• 因不涉及外部分享，故不做参考；

b. 邀请新人红包：

• 由老用户（已注册即可）发起邀请，新用户接受邀请完成注册获得红包，接受者完成规定的消费后，发起者也可获得红包；
• 所有已登录用户可在【我的】页面找到入口（美团：「邀请有奖」；饿了么：「推荐有礼」）；
• 邀请方式：生成H5链接分享到微信等第三方平台，面对面扫码；
• 受邀方须为新用户且在时限内通过app或小程序成功下单才对发起者发放奖励，同一账号/手机号/设备均视为同一用户（避免被大量薅羊毛）；

竞品-邀请红包发放/领取基本流程

c. 拼手气红包：

• 由刚刚消费过的用户发起，任意获得链接的用户（好友、发起者自己、非好友均可，但人数有上限）参与领取；
• 用户下单支付完成后在订单详情页有发红包入口；
• 发放方式：生成H5链接分享到微信等第三方平台；
• 分享封面显示「第x个领取的人得最大红包」；
• 已关联微信的账号直接领取到账号，尚未关联微信者需先授权登录，允许领自己的红包；
• 领取后H5页面显示自己领到的红包并按时序显示领取者及红包金额；
• 每笔订单发放的红包的可领取人数有限，每个人每天可领取的红包个数有限；
• 若新用户通过拼手气红包注册，领取拼手气红包同时也将获得新人礼包；

竞品-拼手气红包发放/领取基本流程

2.1.2 差异与亮点：

两个竞品间的差异可能即是各自的亮点，分析这些差异的原因可对本产品的功能细节起到重要的参考作用，有以下一些细节值得注意：

竞品差异与亮点：美团外卖 vs. 饿了么

2.1.3 调研结论

• a. App内部红包对推广无明显帮助，非本次目的，不参考；

• b. 邀请奖励红包是以推广为目的红包，但仅限新用户领取，且需消费方能给分享者返利，条件高，周期长，都将打击分享者的积极性，预计效果有限，因此本阶段不予优先开发，可作为下个阶段的任务；

• c. 拼手气红包是兼顾转化与推广双重目的的形式，让利不宜太大，可能吸引力较小，但新老用户均可领取，流程简单，见效迅速，因此本阶段优先开发此项功能，流程及各方面，基本参考美团外卖即可（饿了么在这一块的用户体验略繁琐，很多设计必要性不高），注意不同情形下的提示和引导；

2.2 用户-场景-问题-解决

优惠券发放H5-用户场景问题解决

2.3 需求优先级

根据以上分析梳理出以下功能需求：

• A. app内支付完成后提醒用户分享红包；
• B. app内将发放红包的页面分享到微信、朋友圈；
• C. 微信打开H5页面即自动登录并发放优惠券到相应app账号；
• D. 微信无绑定账号者通过H5输入手机号验证码注册/绑定账号；
• E. H5展示红包领取情况：谁领了什么金额；
• F. H5展示「我」领取的红包，点击可进入app使用；
• G. H5领取异常时的异常状况说明，解决办法引导（如：已领过-去使用，此红包已被领完-找其他朋友索要，您已达到今日领取红包上限-去使用，…）；
• H. 后台管理红包：添加，设置（金额、门槛、时效、领取规则、说明等），上线，下线，删除；
• I. 后台追踪红包状态：已生成（由哪笔订单生成、时间），已领取（金额、由谁领取、时间、领取数目），已使用，已失效；
• J. app内下单前可寻找红包（展示哪些好友现在有可分享红包，选择好友偷红包/索要红包）；
• K. app内下单时可选择使用红包；
• L. app内提醒使用即将过期的红包；
• M. app内查看自己的优惠券汇总列表：优惠券状态、金额、说明、时效，点击去使用；

B,C,D,H,I,K 构成了整个红包发放的最基本的功能，没有其中任一功能，红包发放就无法成立，因此无论开发难度见效快慢如何，都必须最优先开发，其中后台又优先于前端，H5页面的准备优先于app内的引导展示；

A,F,G,L属于引导性质，可帮助用户获得更流畅的使用体验，其中G解决异常情况尤其重要，A将新功能告知用户是使用功能的前提，F展示是必须的，跳转则不是必须但开发简单，L用户大多没那么在乎红包过期；

E,J,M属于辅助功能，E提供透明度可提高用户信任度，其社交话题性可提高用户参与积极性，对推广有帮助，且竞品都有该功能，用户已习惯有此功能，J可提升用户体验但对推广没有帮助，即使没有此功能用户也自有简单的替代方案，而M本身用处不大，但用户习惯在领取后及下单前查看自己的红包；

以下对非必须的A,E,F,G,J,L做排序：

广度-频率

效用-难度

综上，功能需求优先级排序如下：

H, I > C, D > B, K > A > F > G, M > E > L > J

3.本次需求目的与功能列表

本次需求目的与功能列表

4.流程与所处的模块关系

4.1 业务逻辑

运营人员在后台录入优惠券数据、规则并上线 → 老用户在app前端下单后获得发红包机会 → 点击按钮生成H5页面并分享链接到微信好友/朋友圈 → 自己或好友打开H5链接授权登录后获得优惠券 → 点击优惠券跳转回到app → 使用优惠券下单支付

餐饮优惠券业务逻辑

*黄色部分即本项目所需开发的模块

4.2 业务流程

餐饮优惠券业务流程

4.3 页面流程

餐饮优惠券页面流程

5. 功能详述

5.1 App后台

页面原型及功能详述-App后台

5.2 H5页面

页面原型及功能详述-App前端

5.3 App前端

页面原型及功能详述-H5页面

6. 考核指标

发红包弹窗跳出率：

规定时间段内：「取消」按钮的点击次数 ÷ 订单总数 × 100%
另由（100% - 发红包弹窗跳出率）可得 弹窗「发红包」按钮点击率

用以了解弹窗形式的效果，如果跳出率很高（比如超过70%），说明弹窗形式可能更多是招人烦，不如取消弹窗。

红包分享率：

规定时间段内：点击「发红包」而主动生成的H5数目 ÷ 订单总数 × 100%

用以了解分享红包功能的的使用程度

另：红包分享率 - 弹窗「发红包」按钮点击率 = 悬浮「发红包」按钮点击率

由此可对比弹窗和悬浮按钮的使用效果，比如：在弹窗跳出率高的情况下，悬浮按钮点击率仍低于弹窗点击率，说明悬浮按钮的设计可能存在问题。

红包领取率：（不采用）

规定时间段内：已领取的分享红包数 ÷ 已生成的分享红包数 × 100%
其中：已生成的分享红包数 = 订单总数 × 每单分享可领取的红包上限

分享红包是一次分享就批量生成固定个数，而分享者不一定传达给相应的人数，因此这个指标无法有效地反应红包的领取率，但又很难获取实际传达到的人数。

红包使用率：

规定时间段内：已使用的分享红包数 ÷ 已领取的分享红包数 × 100%

红包使用率在一定程度上反应了红包的转化率，可以作为了解红包效果的一个参考。

用户增长率：

单位时间内的用户增量 ÷ 时间起点的用户总量 × 100%
直观的，可以观察总用户数曲线，斜率越大即增长越快（增长率越高）

这是最能反映推广效果的指标，用户增长率显著改变，说明该时间存在影响用户增长的因素，可能的因素不一定是运营推广，但如果在推广时间段上存在持续吻合的增长率提升，可认为运营推广因素与用户增长的相关度较高，大概率可推论推广效果好。

用户的获取价格：

规定时间段内：已使用的分享红包总金额 ÷ （用户增量 - 自然增量）
其中：自然增量的计算较复杂，推广初期可直接将推广开始以前的相同时长内的增量近似地看做自然增量

指标反映：通过「分享红包」的推广形式，每获取一个新用户，平台补贴了多少钱，即推广获取每个新用户的价格，该指标对成本-收益的评估的参考价值最大。