以美团外卖送红包功能为例,产品经理如何做逻辑练习

人人都是产品经理  ·  2019-09-20 14:30:52

以美团外卖送红包功能为例,产品经理如何做逻辑练习

如何进行逻辑练习并输出流程图?本文笔者给了我们一个很好的示范,以美团外卖下单成功后的送红包功能作为分析对象,深入思考后绘制流程图。

每周进行一次逻辑练习并输出流程图,坚持下去会产生什么变化呢?
我也不确定,希望这些内容,你能喜欢。


一、命题介绍
这次逻辑练习,我选择了美团外卖的一个增长功能作为分析对象,这个功能非常常见,相信你也遇见过很多次——
下单成功后的送红包功能。
在美团外卖里,每当你支付下单后,会出现送红包功能的入口,你可以将这个红包发给你的微信好友,同时,你也可以发给自己。
相信你对美团外卖的红包一点都不陌生:

站在结果的角度,我们可以发现送红包功能有几个特殊点。比如,一定是订单支付后才出现入口,领红包前就已经知道手气最佳的位置。
既然我们都是这个功能的用户,那么和我一起来完成这次练习吧!


二、练习命题
请绘制美团外卖下单成功后的送红包功能的流程图。
要求及补充信息如下:
1. 订单支付成功后,触发送好友红包的功能入口。
2. 使用用户视角构造泳道图
3. 逻辑并不复杂,但在好友领红包环节,至少包含3个判断条件


三、输出流程图
这是我的练习作业,分享给大家,我需要强调的是:这份作业仅仅是我们的练习作品,不代表任何产品的真实逻辑。

我把它分成了四个主要环节,分别是订单校验(发红包),红包金额分配(发红包),账号关联(领红包),逻辑判断(领红包)。
再次强调,输出的流程图仅仅是练习作品,不代表真实逻辑,实际上,真实逻辑过于复杂,并不适合我们日常的逻辑练习。


1. 订单校验
尽管我们每次完成支付订单的操作,都会触发送红包的功能入口,但我仍然在这里加入了订单校验的环节,这是一种简易的风控意识。
牵扯到钱的功能,都应该有风控机制——至少在设计产品时,需要具备风控相关的意识。
对于美团而言,这些送出去的红包都是真金白银。一旦出现异常,将产生极大的损失。
在今天,如果美团停止了该业务,单日即可增加数百万的收入——对于使用红包下单的用户而言,即使没有红包,也有很大概率下单。
对订单进行校验,可以提升我们对支出的控制能力,也可以增加我们的控制手段。
对于一些订单金额比较低的,又或者低质量羊毛党用户,我们就可以实现差异化的处理方式,且不被大众所知晓。
美团送出去的红包都是现金,可以真实抵扣的,是需要代替用户支付给商户的,这表示用较低的金额,可以“刷红包”套现。
具体操作如下:
你需要激活美团外卖商户,将部分商品单价设置的极低,比如做到1元每单,或者0.1元每单。
将部分商铺单价设置的极高,以能够使用优惠券为目标。
准备非常多的用户账户,通过购买低价商品,获得红包,再通过购买高价商品使用红包。
此时,红包对应的金额,便会计为该商户的实际所得收益,可以从平台提走。
<仅为参考案例,相信美团不存在这样的漏洞>
订单校验是一种后置的处理机制,是一种最基础的保障,意思是可以通过后置添加的判断条件,来止损。
比如商户黑名单,用户黑名单都可以在订单校验环节判定为无效订单,不触发红包逻辑。


2. 红包金额分配
用户在分享在微信的链接会显示“第X个红包金额最大”的文案,其中明确告知了用户,手气最佳在第几位红包。
这表示金额分配的方式采用的是前置分配。

也就是生成红包时,已经将每个红包的金额同时生成好了,只有这样才能知晓金额最大的红包在哪个位置。
有的朋友会疑惑:为什么不是在分享完成后生成红包金额,毕竟现在的网络很快,计算速度更快。
实际上,最佳的做法是在分享完成后生成红包金额,这样可以节省很多服务器的计算能力,毕竟有很多红包生成了,但没有被分享。
问题在于 分享时显示的文案 “第11个人红包金额最高”,这里的“11”需要我们先传参给到微信。
换言之,如果分享前没有得到这个参数,那么文案就需要调整了。
也就是说,为了在分享前知晓哪个红包的金额最大,我们需要在订单生成后,同步生成红包,并分配红包的金额。
在这次的练习题里,我将红包金额的分配节点置于订单支付成功之后,这会增加服务器的计算压力,并不是最佳做法,但却是最方便的做法。
还有一种性价比更高的做法,订单生成后,随机生成最大金额红包的位置序号,当产生分享行为后,再生成红包的金额,这个做法比我在练习时提到的做法,性价比更高,将对服务器的计算压力降到了最低。


3. 账号关联
账号关联是指将红包的领取人与美团的用户信息进行关联,由于这个业务横跨了美团和微信两个产品,且两款产品之间数据无法同步,这就成为了必不可少的环节。

这里有几个问题,我们可以一起探讨一下:
a. 是否可以用微信登录代替;
b. 是否可以后置关联,也就是先领红包,再关联账号。
关于第一个问题,是否可以使用微信登录代替手机号码关联,这需要我们从场景思考出发,并不是非A即B的选择,而是找到更合适的做法。
在美团的账号体系里,是以手机号码作为主体,并且大部分业务都需要用户提供手机号码作为联系方式,核销方式等。
因此在这个场景里,手机号码比微信登录更加合适。
站在新用户角度,如果用微信账号领取了红包,在实际使用红包时,仍然需要绑定一个手机号码。
这个逻辑演延长了用户的转化路径,还不如坚守手机号码作为账号主体的核心理念。
关于第二个问题,单纯从用户体验的角度出发,自然是先领红包,再绑定账号更好,但实际情况却不是这样。
一方面,后置账号关联会产生许多无效红包,也就是红包被打开了,但是没有进行账号关联,这会极大的降低红包的作用面积,在账号绑定之前,用户可以开无数次红包,也许相同的1个红包,会被同一个用户打开10多次。
另一方面,也是风险意识,后置关联账号,表示用户拥有了放弃的选项,并且这样的放弃也不会减少开红包的次数,意思是我们可以打开N个红包,只有在红包金额让自己满意时,再进行关联。


4. 逻辑判断
我们在命题里特别要求了 领红包环节至少包含3个判断条件,如果这道题出现在面试或者笔试环节,那就尽量多的思考判断条件吧。
针对领红包环节有太多的判断条件,这里可以充分体现出我们的思维宽度,以及思维的深度。
这里,我提到了4个判断条件:

(1)是否本人领取:
或许在显示层我们无法观察到这个逻辑判断,但在后端逻辑里,是有必要进行判断的,这对我们判定用户的质量显得特别重要,对于后期的微观调控也会有很大的作用。
比如,经常自发自领的用户,拉新能力比较低,他的红包金额就可以小一点,因为没有太大可挖掘的潜力。
(2)是否触发风控:
在生成红包前,我们针对订单进行了有效性校验,用来降低商铺及下单人的风险,而在领红包的环节,也需要针对领红包的用户设置风控机制。
我们可以将失信用户加入黑名单,这些用户将会无法领取红包,或者只能领取最小金额的红包。
(3)是否已领取:
这是比较表面的判断,每个红包每个用户只能领取一次,会被划分到两个状态里,每个状态在UI层面会出现差异,已经领取过的用户,无法重复领取。
若是缺少这个条件,表示用户可以重复领取多次,这个功能也就没有意义了。
(4)是否已达上限:
这里的上限是指用户今日可领取的数量是否已经消耗完毕,如果用户今日已经领取了足够数量的红包,是不允许继续无止境的领取红包的。
上限的设定是一种逻辑闭环,也就是有始有终。
产品向用户发红包是开始,但必须存在一个阀值,能够关闭或中止这个业务。
无上限的设计,在与金钱挂钩的项目里十分危险。
我们已经知晓这些红包的金额是可以被套现的,若是用户账户可以无限制领红包,毫无疑问会增加刷单风险。
而凡事会触发这些阀值的用户,刷单的概率更高。


5. 扩展
除了用户每日可领取的红包存在上限以外,每个红包可被领取的次数同样存在上限。
实际上,在领红包的环节存在许多判断条件,原因很简单,这是向用户发钱的足后一个关卡,这是要将真金白银送给用户。
思考以下几个问题,看看你还能想到其他的判断条件:
1. 什么样的用户拿到的金额应该更低
2. 什么样的用户应该拿到金额比较高的红包
3. 如何让这些赠送出去的现金红包产生更高的价值
4. 如何减少支出的成本,提高最终性价比


四、总结
通过对真实案例进行复盘,我们设计了一个简单的可行的送红包业务流程,在这个过程中,也有不少感悟收获,总结如下:
1. 设计业务流程时,需要考虑到服务器的计算能力,必要时,要围绕降低性能耗损的目的,优化业务逻辑。
2. 与钱挂钩的项目必然需要具备风控意识,并且还需要具备风控机制。
3. 手机号码还是微信授权取决于应用场景,是一个 谁更合适的问题,而不是谁更好的问题。
4. 即使前端不需要某些判断条件,特殊的数据依然可以通过后端判断并进行存储,这些数据在未来能有助于我们进入更精细化的产品设计阶段。
5. 逻辑要有闭环,有开始的地方,就要有终点,轻易不要设计“无上限”的产品逻辑,这会留下许多隐患。
比如一些逻辑漏洞,又或者是一些计算路径过长导致的高计算并发。

分享 :
上一篇下一篇
推荐阅读

参与评论

登录 后参与评论

文章评论(0)
2b635c77c4bce80c4e55022a5fefa6d

人人都是产品经理

产品经理
文章总数

153

更多文章

标签

版权产品 音乐 版权 用户 用户研究 产品设计 逻辑思维 产品扩容 互联网衍生产品 用户增长 用户粘性 产品流程图 精准用户 产品运营 产品感 产品运营案例 产品招聘 产品新人 种子用户 产品营销 用户推广 价值用户 用户转化 产品包装创意 洞察用户需求 逻辑思维能力 产品基础 农副产品生态平台 数学思维产品化课程 用户分析 产品分析 用户运营 用户成长体系 用户裂变 用户成长体系设计 用户激励 谓词逻辑 用户需求 产品需求 产品化 活跃用户 电商新逻辑 商业产品运营 产品运营体系 产品运营干货 产品运营岗 产品运营攻略 app产品运营推广方案 互联网产品运营 产品推广渠道 用户体验渠道 用户管理规则 用户分层和分群 用户需求调研 逻辑回归 分析用户 用户分割 产品经理面试 逻辑学 2018机器翻译产品 产品落地 黑格尔逻辑学 归纳逻辑 模糊逻辑系统 用户思维 用户活跃 用户分级 用户管理 获取用户 产品介绍怎么写 产品定位 产品定价 产品测试 产品测评 产品测试规范 获取用户需求 用户需求获取 产品需求获取 获取产品需求 获取用户需求方法 怎么获取产品需求 获取用户真实需求 用户分析研究 用户访问路径分析 用户行为分析 用户舆情分析 用户行为路径分析 用户行为分析的数据产品 用户场景分析方法 用户分析数据 用户复购分析 精准用户分析 用户研究经验 分析用户标签 分析用户数据 产品数据 产品知识 运营逻辑 产品逻辑 产品商业化 产品开发 产品术语 底层逻辑 产品裂变 内容逻辑 赚钱逻辑 产品价值 B端产品 发现用户需求 多工序多产品排产表 产品介绍 用户建模 产品转化率 产品文案 提高产品转化率 产品需求分析 定义产品需求 提炼产品需求 评估产品需求 产品需求会议 产品评估 SaaS产品 产品测试流程 互联网产品测试 产品活动运营 产品盈利模式 互联网产品 互联网产品分类 移动互联网产品 产品应用 产品灵魂 评估产品 社区产品 社区产品运营 获取新用户 产品规划 产品用户体系 产品数据埋点 用户研究方法 产品需求文档 用户反馈 用户价值 互金产品设计 产品的信息引导 用户预期管理 产品生命周期 产品心理学 用户留存 产品经理方法论 产品流程设计 产品设计原则 用户决策