编辑导语：在上一篇文章中，作者带我们了解了帐号换绑的问题，除了换绑以外，账号数据的打通和合并也是经常可见的；本文作者分享了关于账号体系中，账号数据的打通与合并，我们一起来看一下。

一、背景

上一篇说到了账号换绑，下面就再来说一说账号的打通与合并。

先来看看两个场景：

场景一：产品A和产品B同属公司甲；产品B是新业务线的新产品，是位产品小老弟；产品A是成熟业务线的成熟产品，是产品A的老大哥。

考虑到现在流量这么贵，小老弟想求老大哥带一带自己，老大哥答应将用户的部分数据同步给产品A……在此场景下，我们可以延伸出账号打通的需求。

场景二：产品C有微信注册、手机号注册、微博注册等多种注册登录方式；因此一位用户可能有多个账号：账号一、账二、账号三。

有一天，用户突然想将自己所有的账号合并成一个，便于记忆与使用；用户在账号一发起合并，在合并完成后，用户的操作数据将都将在账号一上展示，这就是账号的合并。

从上面的场景不难看出，账号的打通与合并实际上就是账号中数据的打通与合并。

二、概念

1. 账号数据打通

账号数据打通，实际上是指一位用户的数据，可在多个产品间流通共享；通常是由公司业务发展而产生的需求，需用户授权同意产品想要获得的数据，用户不可主动发起。

账号数据的打通可以分为单向打通和双向打通：

1）单向打通

举个特别常见的例子——微信授权。

产品A想要得到用户在微信内的部分数据，产品A申请用户同意数据授权，用户同意，产品A调用微信提供查询接口获得数据；在这一顿操作中，微信不会受产品A中用户数据的影响。

2）双向打通

双向打通的需求一般产生于强强联合的合作关系；例如用户在淘宝新增了一个收货地址，且用户的淘宝与咸鱼的账号相通；当用户打开咸鱼，会发现新增的收货地址从淘宝同步到咸鱼了。

无论数据是单向打通还是双向打通，用户的数据总量是不会变化的，只是用户的数据会在产品间流转。

2. 账号数据合并

账号合并，就是将产品内用户的多个账号合N为1，账号的类型可以相同，也可以不同：

1）相同类型

用户在一个产品中，用两个手机号注册了两个账号，现在希望将其合并为一个账号，这是相同类型账号的合并。

2）不同类型

用户在一个产品中，用手机号和微信分别注册了两个账号，现在希望将其合并为一个账号，这是不同类型账号的合并。

账号是否需要合并也是从业务场景出发考虑的，社交或工具类产品，通常不会处理一人多账号的情况；从保险业务的角度考虑，因投保需实名认证，当账号绑定了实名认证后的用户，再从多个账号中向用户提供投保后的保全、理赔等服务会比较麻烦。

账号数据的打通，用户的数据在产品间流转，总量不变；而账号数据的合并，就会产生用户数据总量的变化。

在账号数据合并后，用户所有的新数据会在新账号下产生，那账号数据合并之前，对于多个账号中历史数据的处理，我们应该怎么操作呢？

三、历史数据的处理

历史数据的合并，并不是简单的1+1=2，对于不同类型的数据，需要进行不同的操作。

总的来说，用户数据分为两类：唯一类和非唯一类，这两类数据的处理逻辑也有所不同，举几个例子简单说下～

1. 用户名

用户有A、B两个账号，两个账号的用户名分别是王小二（A）、王达尔（B），用户在登录王小二（A）的状态下发起账号合并；常规逻辑，一位用户不会有两个用户名的。

如果合并数据时只是简单的相加，用户自己都不知道自己的名字应该是什么了。

那么用户名应该用哪一个呢？在数据合并的时候，应该指定想要保留的数据，覆盖掉其余数据。

2. 浏览记录

用户在A、B两个账号下都浏览过产品，生成了对应的浏览记录。两个账号浏览的产品有重复，现对两个账号发起合并申请。

如果只是简单的数据相加，那浏览记录中就会有数据冗余，导致统计出错。

那应该怎么处理呢？将所有待合并账号的数据累计起来，同时为了避免重复，需去重。

3. 会员等级

用户在A、B两个账号下都有对应的会员等级，两个账号的会员等级分别是“1级”和“3级”，现对两个账号发起合并申请。

会员等级是唯一的，和用户名一样不可以简单相加。

用户到底是1级、3级还是将对应等级换算成分数后再次相加计算出的新等级？可根据具体业务场景做取舍。

4. 聊天记录

用户在A、B两个账号下都有对应的聊天记录，现对两个账号发起合并申请。

聊天记录除用户主观操作删除外，一般不可删除。那么在账号合并时，就要完整保存历史数据，避免丢失。

怎么保存呢？一般使用累计方式进行数据合并。

本文由@404查无此人 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。