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

一、命题介绍

这次逻辑练习，我选择了美团外卖的一个增长功能作为分析对象，这个功能非常常见，相信你也遇见过很多次

下单成功后的送红包功能。

在美团外卖里，每当你支付下单后，会出现送红包功能的入口，你可以将这个红包发给你的微信好友，同时，你也可以发给自己。

相信你对美团外卖的红包一点都不陌生：

站在结果的角度，我们可以发现送红包功能有几个特殊点。比如，一定是订单支付后才出现入口，领红包前就已经知道手气最佳的位置。

既然我们都是这个功能的用户，那么和我一起来完成这次练习吧！

二、练习命题

请绘制美团外卖下单成功后的送红包功能的流程图。

要求及补充信息如下：

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. 逻辑要有闭环，有开始的地方，就要有终点，轻易不要设计“无上限”的产品逻辑，这会留下许多隐患。

比如一些逻辑漏洞，又或者是一些计算路径过长导致的高计算并发。

END