0°

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

 


 


一、命题介绍


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


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


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


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


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


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


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


二、练习命题


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


要求及补充信息如下:


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 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论