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

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

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

前提:今天先说同一个系统内的账号问题,后面有机会再说内部和外部(即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端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。

本文

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部