案例分享：如何处理领现金券红包时的登录问题

不久前，我负责了一个“现金券红包”的项目，策划过程中的一些思考，我觉得还挺有意思的；所以，今天在这里和大家做个分享，权当抛砖引玉。

01

先简单介绍一下项目的情况。

公司近期要主推某款商品，“现金券红包”是这个推广计划的一部分，大致内容如下：

• 用户可以在首页等多个地方点击红包弹窗，领取现金券。
• 现金券金额随机，仅限购买该商品时使用，24小时内有效。

做这个“现金券红包”，目的主要有以下几个：

• 通过在多个地方显示红包弹窗，吸引用户点击访问该商品详情页，为之引流。
• 通过赠送现金券，提高用户对该商品的兴趣。
• 通过设置现金券的有效期，促使有意向的用户尽快购买。

现金券需要和用户的账号进行关联。那么，自然就会有一个问题：如果用户在没有登录的情况下，点击了红包弹窗，要怎么处理？

今天想和大家分享的，就是围绕这个“登录问题”，我的整个思考过程。

02

首先想到的是，方案一：

访问时，只有携带登录态，才显示红包弹窗。

直接把产生问题的情况给拿掉，非常简单粗暴。

当然，稍微想想就知道，这是不可行的。

因为，访问公司网站的用户，大多数情况下都是没有登录的。

把这部分用户排除掉，活动的效果会大打折扣。

03

那么，换种思路，考虑方案二：

• 访问时，没有携带登录态，也显示红包弹窗。
• 点击红包时，先跳转到通用登录页，登录后返回并刷新页面（登录后，即可按“有登录态”的情况处理）。

当然，可以进一步优化：

• 把“通用登录页”，改成“当前页短信验证码登录弹窗”。
• 登录后自动完成现金券领取，用户不用再点击领取。

这个方案的优点在于，“没有登录态”的支线流程机制简单，且不影响“有登录态”的主线流程。

但是，稍微考虑下，还是有问题。

几块钱的现金券，其实没多大吸引力。现在谁缺这几块钱？

用户感兴趣的，其实是这种“奖励随机”的游戏。

如果用户点击红包后，没有直接“中奖”，而是先跳转登录，很可能就不玩了。

毕竟这类活动，大家已经见得太多了。甚至还有很多打着“领红包”的噱头骗用户点击的情况。

所以，用户的“兴趣”不会很强。用户愿意点击，就很不错了。

04

基于此，再进行优化，方案三如下：

• 访问时，没有携带登录态，也显示红包弹窗。
• 点击红包后，显示抽中金额，同时引导用户短信验证码登录，以查看现金券详情。

1）若用户完成登录，则将该现金券归属到该账号下。

2）若用户不登录直接离开，则该现金券作废。

这个方案，将“中奖”前置了，用户的“获得感”更强，对活动的兴趣应该会高一些，更愿意按流程往下走。

而“离开则作废”的机制，使得每次点击红包，都是与上次无关的独立操作。整个判断机制，会简单许多。

但是，马上，我就发现，这个方案有一个漏洞！

现金券，会按照一定的概率，随机生成10元以内的任意整数金额。

因为各金额的概率固定，所以平均金额期望是固定的、可控的。

但是，如果使用这个方案，用户就可以作弊：如果中奖金额不是最大值，就重新进入，重新领取，直到出现最大值。

这会导致营销成本超出计划；这个现金券，是公司补贴用户的。每一块钱，都是实打实的成本。

所以，这样的方案，肯定是不行的。

05

为了弥补这个漏洞，我又考虑了方案四：

• 访问时，没有携带登录态，也显示红包弹窗。
• 点击红包后，显示抽中金额（并将该金额写入cookie中），同时引导用户短信验证码登录，以查看现金券详情。

1）若用户完成登录，则将该现金券归属到该账号下（并清掉该cookie）。

2）若用户不登录直接离开，则该现金券作废（该cookie不作废，用户再次进入点击红包时，开出来的现金券金额固定为cookie中的数值）。

这里暂时不考虑cookie的安全性问题。

按照这个方案，就可以把上面的漏洞给补上了。

只是，方案开始变得“复杂”了。

这样的方案OK了吗？

我试着在脑中模拟了一下领取流程，发现还是有问题。

从用户的角度来看，会出现一个情况，就是，每次点开的现金券金额都是一样的。

“说好的随机呢？这不是糊弄人吗？”

如果刚好第一次抽到的是最小金额（最小金额出现的概率是最大的），那这种“被套路”的感觉，就更强了。

06

好吧，既然搞复杂了，那就索性一条路走到黑吧。

方案五如下：

• 访问时，没有携带登录态，也显示红包弹窗。
• 点击红包后，显示抽中金额（并将现金券ID写入cookie中，cookie有效期为24小时），页面直接变成“已领到现金券”的状态。
• 当用户点击购买时（购买需要登录），将该现金券归属到该账号下（并清掉该cookie）。

这样，用户完全感知不到“领现金券需要登录”这个问题。

相对其他方案而言，用户体验要好很多。

问题是，这个方案就更“复杂”了；而且，要完善这个方案，还有若干问题需要解决，比如：cookie中已经有现金券ID，用户又使用携带了已领现金券的账号的登录态访问购买，2个冲突的现金券，要怎么处理？

当然，也不是说不能解决。

但是，搞到最后会发现，这个东西变得非常复杂，甚至比“有登录态”的主线流程还要复杂。

真的值得这么做吗？

07

重新审视整个思考过程，能不能找一个相对简单、用户体验也还OK的折中方案呢？

于是，就有了方案六：

• 访问时，没有携带登录态，也显示红包弹窗。
• 点击红包后，显示用户已中奖，但是具体中奖金额模糊处理（其实当前还没有生成现金券），同时引导用户短信验证码登录，以查看现金券详情。

1）若用户完成登录，则自动生成现金券，并将该现金券归属到该账号下。

2）若用户不登录直接离开，无需执行任何操作。

从开发的角度上看，方案六和方案二，其实是一样的。

点击红包后，显示的其实就是个登录弹窗。

只是，这个登录弹窗，做成了“已中奖”的效果。

而因为中奖金额模糊处理了，也就没有“作弊”的问题了。

这个方案，体验上肯定不如方案五，但是也不会太差。

而机制上，判断逻辑非常简单，每次操作都是独立的，且不影响主线流程。

各方权衡之下，我觉得，方案六就是当前的“满意解”。

08

以上，就是我在策划“现金券红包”项目时，关于“登录问题”大致的思考过程。

最终方案是什么，其实并不重要。

这里，我是想和各位朋友交流一下，当我们在进行产品策划时，具体是怎么进行思考的。

不同场景、不同需求下，需要考虑的内容当然不可能一样。

但是，如果非要总结一套规律的话，我一般是按照下面这个流程来思考的：

• 首先考虑能不能直接把产生问题的情况整个拿掉，从根源上解决问题。
• 接着考虑能不能用现有的通用模块cover掉。
• 然后考虑如何新增模块来解决问题，考虑可能出现的各种情况，逐一补上漏洞。
• 最后通盘审视，寻找可以精简的地方，把冗余的地方大刀阔斧地砍掉。

作为产品经理，你在进行产品策划时，是怎么进行思考的？

如果你有更好的思考方式，希望能不吝赐教，很高兴能与各位同行朋友一同交流学习。

作者：简明产品论，个人公众号：简明产品论（ID：JianMingPM）

本文由 @简明产品论 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议