通过BUG,分析某APP的产品设计逻辑
本文结合作者在某APP遇到的bug,以及与APP工作人员方面的沟通处理,分析了这款APP背后的产品设计逻辑。
写这篇文章,主要是前不久,自己在某APP遇到的BUG,为出发点,昨日又在和小伙们,讨论设计后台遇到的那些事,萌生出了一点想法。
事情的经过是这样的:
楼主在某APP是通过QQ进行登陆,才发现上面绑定的手机号,早已不是现在的手机,而是很早之前读大学时期的手机号,于是联系了客服进行换绑。
本来是一件非常小的事情,但是,却发现了这个APP后台的设计可能和我理解的有些不同,然后就遇到了一些问题。
遇到的问题:
- 无法查看原订单,提示当前账号与现在的手机号不符合。
- 订单退款失败,无法原路退还。
- 第二个APP(非同一个APP)出现错误,无法登陆老账号。用现有手机号登陆,则为一个全新的账号。
- 第二个APP修改手机号,竟然需要注销支付和实名认证。
问题1
从问题1,可以看出,此APP在查看订单详情的时候,校验的是【购买该订单的手机号】,而非当前所登陆的账号,因此,也就发生了问题1。
问题2
从图片2,可以看出,当用户在申请退款时,该APP记录的订单支付信息,手机号一栏是动态的,也就是说:后台记录的购买的手机号与账号绑定的手机号一致,当绑定的手机号换绑,记录的用户手机号也跟着换绑,退款时由于手机号错误,则会导致退款失败。
当遇到这两个BUG时,楼主尝试了如下操作:
通过客户端短信验证的方式,将账号从手机号A,换绑到手机号B,再去查看订单详情和申请退款,均能成功。因此,可以从此得出一个结论——用户通过客户端更改手机号,和客服更改手机号,不是数据库的同一个地方!
通过流程图,好像没有发现什么异常,但是,就如我上图所说,同样都是换绑操作,为什么客服那边就引起BUG了呢?
因此,从逻辑上分析,当用户通过更改手机号时,数据库的操作是直接将用户账号所绑定的手机号进行换绑。而客服是将新的手机号创建了一个新的账号,再把老的账号内容完全复制过去。
没看懂?看看下面这个流程图:
综上,也就是说为什么客服换绑过后账号需要重新登录,而用户自己换绑,却不用。也解决了“问题1——为什么会提示当前账号与现在的手机号不符合”,因为账号不是同一个账号,订单校验不通过,就无法查看了。这个操作就相当于用户通过客户端查看不属于自己的订单(通过抓包,修改返回值,也可以达到相同的效果。)同时也解决了问题2,为什么不能原路进行退款。
问题3&问题4
本来事情告一段落了,但是,楼主又出现问题了——第二个APP账号提示异常,重新登录,登录过后是一个全新的账号,而非老的账号。
于是在联系客服过后,客服告知第二个APP账号也是绑定的那个老的手机号,改了第一个APP的手机号,第二个APP的也自动解绑了。于是客服又是和第一个APP一样的操作——注销新账号,将老账号数据复制到新账号。这也解释了问题3和问题4,因为第二个APP的钱包是实名认证,一个身份证只能认证一个账号,于是必须得注销第二个APP的钱包,否则无法绑定到新的账号上去。
那么问题来了,第二个APP和第一个APP,账号互不通,为什么会出现修改了手机号(可以理解为:为什么注销了老账号),第二个APP的账号也会跟着出问题呢?
因此,我们可以大胆地推测第二个APP和APP,账号方面的逻辑:
当用户同时注册第二个APP和APP时,会自动将两个账号进行关联,合并为同一个账号,但是数据不合并,从而有利于运营/产品数据分析,因为这两个账号为同一个人,且第二个APP和APP部分功能相似,有利于分析用户行为。
当注销第二个APP/第一个APP时,等于将这一个账号给注销了,因此相关联的第二个APP/第一个APP的业务也会跟着注销,从而产生了问题。
因为用户是无法主动注销账户的,所以这种问题只有在客服进行手机解绑时,才会出现这种蝴蝶效应。
这点设计,和微信/QQ截然不同了,微信和QQ是两个完全独立的账号,而第二个APP和第一个APP,判断为同一个人过后,则会自动关联。
那么为什么第二个APP客服在操作用户换绑手机时,不是直接像用户一样换手机,而是直接换账号呢?
我这边猜测,因为这样的话,就等于有两个账号了,第二个APP/第一个APP的用户量级就更多了,对于企业来讲也就更有利啦~
结语
不过第二个APP这样的设计,是否合理?这样的设计,背后更深层次的意义在哪?恐怕就只能问APP的架构师或者产品经理。
本文由 @狂暴补师 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
这简直是是在反推他们的业务需求…
这个bug提议的很好,可我看了半天却没看出所表达的意思。建议,去繁为简,给出论证和结果。
有时候没有这么多为什么,就是开发自己怎么简单怎么写的