編輯導語：在上一篇文章中，作者帶我們了解了帳號換綁的問題，除了換綁以外，賬號數據的打通和合并也是經?？梢姷?；本文作者分享了關于賬號體系中，賬號數據的打通與合并，我們一起來看一下。

一、背景

上一篇說到了賬號換綁，下面就再來說一說賬號的打通與合并。

先來看看兩個場景：

場景一：產品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協議。