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

16 评论 23292 浏览 183 收藏 15 分钟

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

引言

这是我的第6期逻辑练习的作品。

每周进行一次逻辑练习并输出流程图,坚持下去会产生什么变化呢?

我也不确定,希望这些内容,你能喜欢。

命题介绍

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

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

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

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

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

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

练习命题:

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

要求及补充信息如下:

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

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

如果你觉得这篇文章对你有所帮助,就分享给你的朋友吧。

也希望未来能与你一起进行逻辑练习,我相信,坚持下去,我们的逻辑能力都能有极大的提升。

#专栏作家#

枯叶,微信公众号:产品经理充电站。人人都是产品经理专栏作家。近9年经验的产品经理,擅长社交、社区、细分群体挖掘。

本文为平台独家约稿,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 您好,我有几个问题想和您探讨一下,如果是用泳道方式画流程图,那么是否应该加上“系统”这个角度呢,因为像红包发放、逻辑计算、红包机制、订单效验都是系统运算出来的,如果我是开发看了您的流程图第一感觉像是当前支付的这个用户“配置的红包”,实际上这个用户也只是个转发和领取的动作;
    还有一个问题,有些订单效验是否可以提到支付环节一起做效验,像您说的,如果这个用户是黑名单,那么支付环节系统就阻止其支付,省的先支付完成在做效验,服务器压力又大了,像红包机制是否也可以再支付完成后后台跑一次红包的逻辑呢,相当于支付前判断是否是黑名单等基础判断、支付成功后效验订单的情况和运算红包机制;
    我也是初学者,只是提出了自己的想法,有不对的希望您见谅,我们共同探讨。

    来自北京 回复
  2. 对于红包金额的分配节点置于订单支付成功之后有其他角度的看法:更有利于裂变,在用户有心理预期的时候裂变的效果会更好?

    来自上海 回复
  3. 谢谢分享,我不是做产品的但还是要道声谢

    回复
  4. 1 涉及到钱的事情,要具有风控意识。
    2 轻易不要涉及无上限的产品,会留下许多隐患

    回复
  5. 好棒!自己顺着思路做一遍,再看一下枯叶的,查漏补缺。很有收获👍

    来自北京 回复
  6. 每笔订单美团会从用户支付的金额中抽成的,所以刷红包套现可能最后还是赔钱。

    回复
  7. 服务器的运算能力,这就比较进阶了,用户量如果达不到一个量级,真的很难积累到这方面的经验。

    来自广东 回复
  8. 应该在四个判断条件之后,再判断领取红包顺序,然后根据以上判断结果分配红包金额

    来自浙江 回复
  9. 超级酷,风控意识,学到了

    来自陕西 回复
  10. 入行近一年,最近首次做了涉及账户资金的需求,自己在这方面的意识的确还不足,还有企业经营管理及财务方面也是

    来自广东 回复
    1. 是吧,世界就是这么难

      来自北京 回复
    2. 风控就是当初遗漏的一定,和老大对方案的时候才被指出 😥

      来自广东 回复
  11. 很棒 逻辑很清晰

    来自四川 回复
    1. 嗯嗯 🙂

      来自北京 回复
  12. 考虑的还是很细致的,跟钱有关的产品的风控特别重要….因为一不留神就会赔钱 ➡

    来自北京 回复
  13. 套现问题不存在,因为商户做虚假交易平台会抽成

    回复