搭建账号体系，需要注意这几个问题

账号体系是所有系统都几乎会面临的一个难题。可以这么说，我所经历过的公司基本都不约而同的遇到过，在业务发展过程中，现有账号体系无法支撑业务而被迫进行改造。

今天就来讲讲账号体系建设中最常遇到的几个棘手的问题。话不多说，直接上干货。

前提：今天先说同一个系统内的账号问题，后面有机会再说内部和外部（即N个系统）的账号打通问题。

01 同一系统内的账号问题

很多公司存在一个问题，因为历史原因，在公司和产品发展初期，没有做好完善的账号体系规划，导致对用户的定义是有问题的，这些问题在后来业务发展中不断的暴露出来，并带来很麻烦的账号体系改造。

比如一些社交电商平台，初期为了用户体验和购物成本最小化，直接通过微信授权登录后，不强制绑定手机号。但是随着业务发展，大家开始意识到，如果不以手机号作为唯一身份标识，那整个平台该如何辨别这个人到底是谁？

比如通过微信openid创建的 uid1 和通过支付宝 user_id 创建的 uid2，可能背后其实是同一个自然人。

这就为平台未来的诸多业务发展带来了巨大的限制，比如我们需要对用户进行风控，要通过用户行为进行算法推荐，要看平台的注册用户数和活跃用户数，我们都无法做到准确，甚至会产生很离谱的偏差。

所以对平台来说，这种不合理的设计一定会在未来某个节点爆发出巨大的瓶颈。

我当初在负责丁香云管家这款产品的时候，也遇到过这个问题，那就是线上的账号不强制绑定手机号，可以进行很多的业务操作，比如预约、获得积分等，但是对于诊所来说，必须要打通线上和线下的服务场景，比如我在线上预约后，可以到诊所进行就诊，所以线上线下两个账号必然面临需要绑定的问题，两个完全不同的用户（uid不同）该如何打通？

最近还遇到一个账号问题，和某大厂旗下一款产品A进行合作，我们提供一个sdk给大厂，涉及双方业务交互，但是A中并没有用户手机号数据，且又不愿意在他们的产品中间环节进行手机号绑定（觉得影响他们的用户体验），只是在最后付款阶段唤起我们的小程序进行付款。

那么这里就会遇到很严重的账号问题，我们想了几个方案，但几乎每个方案都有缺陷，留个悬念看看大家怎么解决这个问题，底部可以留言说说你的解决思路～

02 上述问题的解决思路

对于上述的第一个问题，当未来所有用户都必须绑定手机号的时候，那些老用户该怎么处理？一般可以采用如下2种方式解决。

1. 账号合并

既然老用户（uid=1）没有手机号，那么第一步就是当他去做一些关键行为的时候，强制要求他去绑定手机号，那么这里会有3种情况：

第一种绑定的是一个新手机号（其并没有在平台有uid），那么很显然，绑定成功，且uid依然为1，同时该uid下写入新手机号数据。

第二种绑定的是一个老手机号（uid=2，其在平台之前注册过），那么我们要看该账号（uid=2）下否存在一些业务数据，比如订单、优惠券、积分、余额等，如果没有，那么直接绑定成功，且uid2被注销，手机号写入uid1（主账号）中。

第三种，前面的条件一样，但是uid2下存在一些业务数据，这个时候如果要绑定，就涉及到业务数据合并的问题了。一般来说，uid1下的数据会被洗到uid2下，进行合并，然后合并后剩下uid2（主账号），uid1则被注销。

这里到底是注销uid1还是uid2，其实都可以，看你自己怎么定规则。

2. 账号不合并

我们是否可以让用户在两个账号里2选1，选择一个作为未来他想要用的账号，而注销另一个？

可以当然是可以，但是这样的前提就是损失用户体验，你给用户的选择其实是逼着他抛弃一个，或者让他先把账户中的余额、优惠券、积分尽快使用掉，然后把该账号废弃，以手机号uid2为主账号。

从实现难度和工作量来讲，毫无疑问方案2更简单，有的时候其实就是取舍的问题，到底是用户体验重要，还是研发投入产出比重要，每个人每个公司都有自己的选择。

03 数据合并是下下策

业务数据的合并其实并没那么简单，甚至有点“恶心”。

我们从简单的往复杂的讲：比如2条订单合并，一般按照订单的创建时间进行倒序排列，那么也就是说开发先要把两个用户下的所有订单拉出来，进行时间倒序排序，然后再往uid2的订单中按照顺序依次插入uid1的订单。

再难点，比如2个余额的合并，那么uid2原来有100元，uid1有50元，那么50元归入uid2的资金账户后，是以什么的形式体现呢？除了账户多了50元，你还需要保证账户余额和资金明细能够对上，所以显然需要人工插一条“莫名其妙”的资金入账明细，maybe 可以叫“账户合并入账：50元”？

再难点，比如2边的积分合并，很多平台积分能决定会员等级，假如uid1有100个积分，会员等级是3级，uid2是200个积分，会员等级是2级，那么除了简单的积分合并之外，uid2的会员等级甚至会发生变动。

这就会导致除了合并积分数据之外，还要根据新积分进行判断，自动更新其会员等级，以及会员权益等，带来一系列的“非自然”变动。

所有上述的改动其实都是由开发主导的数据修复，我们常常叫“洗数据”。这种非用户自主触发的业务数据变更，会带来最恶心的一点就是，很多模块数据都要洗，影响范围巨大，且很容易出现洗错的情况（人工做的事总有可能出错），且错误会波及到不少业务。所以很多时候，开发是非常反感做这种事的，万一洗错了，是要背锅的。

04 小结

账号问题的核心其实是账号的唯一标识，如果在系统刚开始设计的时候就能准确的定义好唯一标识，那么后面基本就不会出现太大的问题和改造需求。

#作者#

司马特小队，公众号：司马特小分队。8年+互联网资深产品经验，多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验；主要教授产业互联网产品相关的硬核知识点。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！