通过BUG，分析某APP的产品设计逻辑（通过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协议
