微信用户名是什么（微信账号和用户名是什么）

　　账号体系是平台的底层系统，在此基础上，用户行为、业务发展等因素会引发账号间交互的需求。
　　账户间的交互有＂合并＂＂打通＂＂换绑＂等方式，其中＂合并＂与＂打通＂这俩概念极易混淆，本文将对这两种账户交互进行概念区分及处理方式的讲解。
　　一、合并与打通的区分
　　这部分橘子将会以下图为大纲进行讲解：
　　1.账号合并
　　（1）概念
　　账号合并是指一个系统内，一个用户的多个账号合并成一个账号。
　　账号系统是为用户所做，账号即代表用户身份。在一个系统内部，用户本人为账号的持有者，所以对多个账号的合并只能由账号持有者本人发起。
　　因此账号合并需要从用户的维度思考，合并结果为一个用户在系统内的多个用户身份，合并为一个用户身份。
　　（2）业务场景
　　合并前的多个账号，可以是相同类型的，也可以是不同类型的。
　　在此，先对＂类型＂进行简单定义：注册方式相同的账号，视为相同类型的账号。
　　一个系统内，相同类型的账号合并：
　　e.g：游戏中，同一用户用两个手机号注册了大小号。希望将其合并为一个账号。
　　这些账号是在同一个游戏内，通过相同的方式＂手机号注册＂，用不同的手机号注册的账号，所以为相同类型的账号合并。
　　一个系统内，不同类型的账号合并：
　　e.g：一个平台内有手机号、、微博等多个注册入口，导致一个用户有多个账号，希望将这些账号合并。
　　手机号、、微博等账号是通过不同的注册方式生成的，所以为不同类型的账号合并。
　　（3）目的
　　账号合并的重点在＂并＂，所以账号合并希望达到的效果：
　　账号＂合n为1＂：多个账号聚合后生成一个主体账号，一个用户只有＂一个＂主体账号代表其用户身份。
　　数据取并集：合并后主体账号的数据，为所有账号数据资料的累加并集。
　　在上面相同类型的账号合并的案例中：
　　一个游戏用户希望将小号合并入大号，每个账号都有10枚金币。
　　则最终的合并结果：大号为主体账号，数据为两个账号的累加，金币为10*2=20枚，小号注销无法再次使用。
　　不同类型账号合并案例中：
　　一个用户的手机号、、微博账号要进行合并，系统定义的主体账号为手机号，每个账号都有10个收藏店铺。
　　则最终的合并结果：账号、微博账号作为子账号绑定在手机号上，账号、微博账号的数据并入手机账号中，收藏店铺为10*3=30个。
　　通过任何账号登录，调用的都是所关联的主体账号的信息。
　　2. 账号打通
　　（1）概念
　　账号打通是指同一个用户的数据，在多个系统间进行流转。
　　＂打通＂是多个系统账户体系的交互，用户虽然是账号的持有者，但是涉及到多个系统间的交互，用户是没有＂发起＂权的，仅有＂授权＂权，授权是否同意打通。
　　多系统内账号的打通，为的是实现系统间数据的流转，因此账号打通更准确的说其实是系统间的数据打通，数据的传输纽带为＂同一用户＂。因此在本文后续都以＂数据打通＂来替代＂账号打通＂。
　　数据打通的发起方，为使用打通后数据的业务系统。多个系统间的数据需要做交互，由需要该数据的业务系统来推动。
　　因此数据打通需要从系统、数据的维度思考，通过账号的打通，来实现系统业务的打通，最终实现系统间数据的流转。
　　（2）业务场景
　　多个系统间，系统间数据的打通分为单向与双向。
　　不同系统内，单向的数据打通：
　　e.g，通过等第三方授权方式注册登录知乎后，app用户的初始化用户名为的用户名。
　　此为知乎与两个系统间的数据打通。知乎只需要提供用户数据，所以为单向的数据打通。多用于授权模式的产品。
　　不同系统内，双向的数据打通：
　　e.g.饿了吗与百度外卖整合后，同一个用户用同一个手机在两个平台注册登录，在饿了吗修改送货地址，百度外卖的送货地址会自动进行同步；反之同理。
　　此为饿了吗与百度外卖两个系统间的数据打通。送货地址信息在两个系统内相互流转，所以为双向的数据打通。多用于合作模式的产品。
　　（3）目的
　　数据打通的重点在＂通＂，打通后在系统间流转的就是数据，所以数据打通希望达到的效果：
　　数据流通：一个用户在多个系统内，局部数据流通（单向或双向），数据总量不变。
　　在上面单向数据打通的案例中：知乎需要用户体系内用户的昵称，因此需要提供查询接口，知乎进行调用，查询当前注册的用户在的昵称，实现单向数据流通。
　　在上面双向数据打通的案例中：饿了吗与百度外卖中，同一用户的送货地址需要进行同步，百度外卖整合入饿了吗，因此百度外卖需要相同用户在饿了吗的数据，并且可以写入新的数据。因此由饿了吗提供查询、写入接口，实现双向数据流通。
　　3. 账号合并与打通的区别总结
　　账号合并
　　由用户发起，所以合并的主体为：＂一个＂使用账号的用户本人。需要从用户维度去思考。
　　合并后数据要求：所有账号的数据累加植入合并后的账号。
　　数据打通
　　由业务方发起，所以打通的主体为：使用打通后流转数据的业务系统。需要从系统维度去思考。
　　打通后数据要求：同一个用户的局部数据在多个系统间通过业务流转同步，数据总量不变。
　　通过以上的拆解 ，相信大家能够更准确的区分账号的合并与打通。接下来，就是真正动手实操了，如何处理账号的合并与打通呢？
　　二、合并与打通的方式
　　合并与打通的处理，都分为两个部分，一为账号业务层面的处理，二为旧数据的处理。本文仅详述业务层面的处理，旧数据的处理将在下篇文章进行展开详述。
　　1.账号合并
　　回顾账号合并主体：＂一个＂使用账号的用户本人。
　　账号合并目的：一个用户只有＂一个＂主体账号代表其用户身份。
　　下面会按照不同的场景，对账号合并的处理方式进行讨论。
　　（1）一个系统内，相同类型的账号合并
　　多个账号的类型相同，登录方式相同，相当于多个完全独立的用户个体，要将其合n为1，说明这几个用户其实为一个人，那么只需要保留一个账号代表该用户个体，并且拥有所有账号的数据即可。
　　所以，需要用户在发起合并账号请求时，指定合并后保留的账号，以此为主体账号，将其余账号的数据资料全部累加计入主体账号，然后注销其余账号。
　　e.g.将三个账号abc合并，每个账号都有10枚金币，且主体账号为a。则将bc的金币累加进入a账号，累计后金币数为30，bc账号注销，无法再次登陆。
　　（2）一个系统内，不同类型的账号合并
　　账号的类型不同，登录方式也不同，没有一个统一的判断基准，所以无法判断这些账号间的关系为同一用户所有，还是不同用户所有。
　　所以需要先设置一个统一的判断基准：从哪种方式登录的账号，为用户身份的唯一标志——主体账号。
　　以下为常用的账号合并操作思路：指定可确认用户身份的登录方式；新增主体账号ID，为账号系统内每个人用户身份的唯一ID。仅有通过以第一步指定的的登录方式注册时，才会生成主体账号id；以其余登录方式产生的账号，为主体账号的子账号。同一主体账号ID可对应多个子账号（ps：若非强绑定关系，在用户用子账号登录后，不强制用主账号流程注册，无法生成主体账号ID，就将其置为空，等后期用户发起合并的时候进行填充）。用户在发起账号合并后，提供其需要绑定的主体账号ID，将子账号绑在指定主体账号下，并将子账号的用户数据并入主账号，便完成了账号的合并。
　　通过以上方法，合并后通过用户身份下任意方式登录，都调用的是相同的主账号下的用户数据。
　　这种方式需要修改账号体系的架构，将平行的账号关系修改为主/子账号的母子关系，所以在前期实现账号合并的时候改动大，成本较大。
　　但是在后期解绑/换绑子账号的时候，对用户数据无影响，因为用户数据是储存在主账号ID下的。
　　2.数据打通
　　回顾数据打通主体：使用打通后流转数据的业务系统。
　　数据打通目的：同一个用户的局部数据在多个系统间通过业务流转同步。
　　系统间的数据流转要依赖接口，所以，需要通过设计接口来实现数据打通。
　　系统间需要进行数据流转的为＂同一用户＂，则首先两个系统需要对用户的身份有相同的判断方式，接口通过该用户唯一标示，来进行两个系统间同一用户数据的流转。
　　下面会按照不同的场景，对数据打通的处理方式进行讨论。
　　在此，我将使用打通后流转数据的业务系统主体称为甲方，提供数据的系统称为乙方。
　　（1）不同系统内，单向的数据打通
　　单向数据打通，即甲方需要乙方的用户数据，乙方不受甲方业务影响。所以需要乙方提供数据查询接口，甲方进行调用。
　　市场中常见的、微博、qq等用户数据已经有了成熟的对外接口，仅需进行申请便可进行调用。若乙方无成熟接口，就需要进行定制化的接口开发了。以下为接口的设计思路：
　　1）确定甲乙系统内用户身份的唯一标示
　　方法：列出双方账号系统用户账号的所有可用信息，从中挑取相同的、与业务强相关的、用户不会轻易改变的、最能代表用户身份的字段，作为打通后识别用户的唯一标示；例如手机号。唯一标示为接口的必填查询入参。
　　2）甲方提供所需的用户数据需求，详细到字段，例如用户名称、用户头像；以及是否有批量查询用户数据需求。
　　3）乙方根据甲方需求提供查询接口：接口入参：前期统一的用户唯一标示，来指定查询的用户；查询的用户数据；接口出参：甲方查询用户的指定数据。
　　4）甲方对接后进行调用
　　（2）不同系统内，双向的数据打通
　　双方数据打通，即甲方需要乙方的用户数据，同时也会向乙方插入用户数据。乙方提供数据查询接口、数据写入接口，甲方进行调用。以下为接口设计思路：
　　1）确定系统间的唯一标示，作为打通后识别用户的唯一标示
　　方法同单向打通
　　2）判断唯一标示是否符合乙方账号系统的注册条件，据此保证打通后甲方向乙方写入新用户数据时，可以成功进行注册
　　方法：判断唯一标示为乙方账号的什么信息：为乙方账号注册时的唯一身份标示：不需任何处理为乙方账号关联的字段：判断甲方系统是否有乙方账号注册时的唯一身份标示字段，若有，注册时使用该字段；若无，扩充乙方系统注册方式，或甲方系统要求用户补充该用户信息。
　　3）甲方提供所需的用户信息，以及要写入乙方的数据
　　所需的乙方数据的提供方式，同单向数据打通
　　写入乙方的数据，按照功能模块划分，再详细到字段，例如绑定新用户（唯一标示、用户名称、密码）、填加数据（收货地址）、删除数据（收货地址）。
　　4）乙方根据甲方提供需求，设计相应的查询接口与写入接口
　　查询接口同单向数据打通。写入接口入参：前期统一的用户唯一标示，来指定写入的用户；具体写入数据；写入数据出参：操作结果（成功/失败，及失败理由）
　　5）甲方对接后进行调用
　　以上便为账号＂合并＂与＂打通＂的概念区分及处理方式的讲解，下一篇文章将会继续这个话题，讨论合并 /打通后，旧数据的处理方式后。
　　备注：文章若有思考不完善之处，欢迎各位帮忙指正，共同进步。
　　作者：橘子；公众号：橘子周思录；我是3年产品橘子，每周分享自己对日常工作的总结思考，希望与您一同成长。
　　本文由 @橘子 原创发布于人人都是产品经理，未经作者许可，禁止转载。
　　题图来自Unsplash，基于CC0协议。