账号体系——账号合并的历史数据处理
之前對合并/打通這兩種賬號的交互做了概念區分及處理方式的講解，接下來會分為兩篇分別對賬號合并、打通后的歷史數據處理方法進行說明。
先回顧賬號合并：
概念：一個系統內，一個用戶的多個賬號合并成一個賬號。
場景：一個系統內，相同類型的賬號合并/不同類型的賬號合并；
要求：一個系統中一個用戶身份只有一個賬號，且所有登錄方式產生的數據都遷移累計在該賬號下。
由上可知，不論是哪種合并場景，其本質都是將多個賬號的同類型數據進行了合并，將所有數據都合并到一個用戶緯度，因此本文將圍繞“歷史數據的合并處理方法”展開討論。以下為本文大綱：
開始的開始，舉個栗子
所有的解決方案是依附具體背景存在的，因此本文依附以下案例展開討論：
你負責一個問答社群平臺的賬號系統，現在接到一個需求：
給用戶提供賬號合并的功能，用戶可以對名下多個賬號發起合并請求，實現對多個賬號名下收藏關注的文章用戶、閱讀簽到等產生的成就權益等數據進行統一管理。
在合并完成后，后續該用戶所有操作產生的數據都會進入合并后的賬號。那么在合并前，幾個待合并賬號內產生的數據呢，這些數據也屬于該用戶，也就是本文所指的歷史數據。歷史數據就是在進行合并之前，系統中已經存在的原始數據。
為了后續該用戶可以通過合并后的賬號順利調用歷史數據，完成指定的業務操作，我們需要將所有賬號的歷史數據合并入最終的賬號內，即要對歷史數據進行合并操作。數據合并就是將同類型的多個入口的輸入數據集合并為新的單個輸出數據集，為數據消費者提供唯一數據出口的數據集成方式。
技術實現合并后，發現幾個問題：
待合并的兩個賬號，關注了相同的用戶。合并后賬號產生了重復關注的用戶，導致總數統計錯誤，數據冗余。
待合并的兩個賬號，成就勛章分別是1級與3級，合并后用戶依據勛章級別開放的權限出現了業務沖突。
可見，歷史數據的合并不是簡單的1+1=2，若是處理不規范，可能會產生類似上述的異常。本文就從合并每種類型歷史數據可能產生的異常入手，分析對應的處理方案。
01
數據有哪些類型
從業務角度入手，筆者將數據拆分為以下五種類型：標示類、定義類、關系類、權限類、業務類。
▋標示類
定義：對身份進行標示定義的唯一數據，例如上例的用戶昵稱、性別。與userid為同一級別，標示用戶身份，一般為存儲在數據庫user表中的用戶數據；
特征：所有賬號的標示類數據格式統一，且該類參數在用戶緯度內唯一。
▋定義類
定義：用戶自己設置或系統對其配置的定義個人屬性的參數。例如上例的用戶簽名、用戶自己配置的系統設置項、電商系統的收貨地址。這類數據是對用戶本人、及操作習慣等的定義；
特征：此類參數在用戶緯度內不唯一，但是不可重復。
▋關系類
定義：由于用戶本人的操作，用戶與系統中本人、非本人數據產生的關系。例如上例的文章收藏夾、關注用戶即為與非本人數據產生的關系；印象筆記中的筆記本與筆記即為與本人數據產生的關系。關聯的數據之間可以產生更多的交互業務。
特征：該類參數在用戶緯度內的限制根據業務決定。
▋權限類
定義：用戶付費、申請或系統賦予的用戶權限，不同的權限對應用戶不同的操作、可視數據。例如上例的用戶成就勛章。
獲取方式：
權限類數據一般有兩種獲取方式：付費購買、系統賦予。
系統授予又分為：主動與被動兩種獲取方式。
主動：由用戶發起的權限申請，例如申請成為專欄作家；
被動：系統根據用戶使用情況授予的權限，例如用戶積分對應的權限；系統根據用戶在系統中所處的角色授予的權限，例如將某用戶配置為管理員、將某用戶配置為試用期。
權限一般分為以下類型：
配置類：直接授予、獲取的角色權限、操作權限、數據權限；
積累類：根據用戶操作經驗產生的積分，對應不同的權限。
權限類數據特征：
權限類數據可能不僅是一個最終結果，也可能是一個未完結的申請流程。該類參數在用戶緯度內限制根據業務決定。
▋業務類
定義：由于用戶操作或使用生成的業務流水/創造的數據。例如上例中用戶發布的文章、用戶設置的收藏文章標簽、消息、后臺的每日使用人數。
特征：該類參數在用戶緯度內的限制根據業務決定。
02
歷史數據合并處理方式
▋標示類
場景：用戶持有A、B兩個賬號，兩個賬號的昵稱分別為小王、小李，現對兩個賬號發起合并，并指定賬號A為主賬號。
問題：數據合并后用戶昵稱有兩個，不知道使用哪個。
案例中的用戶昵稱為標示類數據，標示類數據是對用戶身份的標示，與userID同一級別，因此在一個賬號內有唯一性。在上例沒有正確處理該數據，產生了數據沖突的異常，最終無法精準定位。
所以標示類數據的正確合并方式為：由發起合并的用戶指定保留數據的賬號，覆蓋掉其余待合并賬號的數據。
注意：最終保留的所有標示類數據需都取自同一個賬號，若不同用戶的標示數據拼合在一起，可能影響后續業務數據調用。
▋定義類
場景：用戶持有A、B兩個賬號。分別對某些用戶設置了黑名單，屏蔽他們的消息，兩個賬號設置的內容有重復項。現對兩個賬號發起合并申請。
問題：數據合并后黑名單出現重復項。
案例中的黑名單設置即為定義類數據，該類參數定義個人屬性，因此在個人維度是不可重復的。在上例中沒有正確處理該數據，產生了數據重復的異常，使得最終數據統計錯誤、數據冗余，嚴重的話會引發bug，數據失效。
所以定義類數據的正確合并方式為：由于定義類參數定義個人屬性，因此合并后的賬號需要將所有待合并賬號的定義類數據累計起來；為了避免重復，需要進行去重。
▋關系類
場景：對A、B兩個賬號發起合并，用戶C關注了B賬號。合并處理后僅保留A為代表用戶身份的主賬號，并將所有數據都遷移累計到A賬號下，B賬號作廢。
問題：用戶C無法再訪問關注名單中的B賬號。
案例中的關注關系即為關系類數據，該類數據是用戶與系統中非本人數據產生的關系，因此要求合并后的賬號與歷史其他非本人數據的關系依舊保存。在上例中沒有正確處理該數據，產生了數據失位的異常，導致歷史的關系無法定位追蹤。
場景：一個文章可以打多個不同的標簽。用戶對A、B兩個賬號發起合并，兩個賬號的收藏夾內有相同文章、相同的標簽。合并過程中直接將兩個賬號中這兩個參數進行合并去重，未考慮對應關系。
問題：數據是完完整整都合并入最終賬號內，但是每個文章的標簽是什么呢？
案例中的標簽與文章存在關聯關系，在合并時沒有考慮這部分關系，導致最終的數據錯位，數據間的關聯關系沒辦法恢復。
綜上，關系類數據的正確合并方式為：待合并賬號與系統中本人、非本人數據產生的關系，需要遷移到最終合并后的賬號。
例如第一例中，需要將C賬號收藏夾中的B賬號，切換為A賬號，實現關聯關系的遷移。當然了，處理這類需求時要考慮業務場景。不同的場景可能有不同的處理方法。若為強交互的產品，如社交類產品，需要讓其他用戶及時準確定位到合并后的賬號。因此需要將B賬號切換為A賬號；若為弱交互的產品，如資訊類產品，只需要讓用戶知道將來如何繼續跟蹤B賬號。因此，在用戶主動查詢、點擊B賬號時，再提醒其已經合并作廢，并提供合并后的A賬號路徑即可。
▋權限類
場景：系統規定，用戶成就勛章對于一個賬號是唯一且分等級的，不同的等級對應不同的用戶權益。用戶對A、B兩個賬號發起合并，兩個賬號的勛章分別是“筆桿子10級”與“筆桿子3級”。合并處理后僅保留A為代表用戶身份的主賬號，并將所有數據都遷移累計到A賬號下。
問題：A的勛章為“筆桿子10級”與“筆桿子3級”。現在用戶到底算是10級還是3級？級別相關的權益如何判定？
案例中的勛章即為權限類數據，此類權限類的數據具有唯一性，在上例沒有正確處理該數據，產生了數據沖突的異常，最終無法精準提供后續的服務。
與標示類數據處理方式類似，具有唯一性的權限類數據的合并最終只需保留一個權限，處理方式也是覆蓋。但是具體保留哪個賬號的數據與具體的業務場景相關。
再舉個例子，后臺對帳號A的角色配置為編輯，對帳號B的角色配置為運營，現對兩個帳號發起合并，合并后用戶的角色應該是什么？若系統支持一人多角色，那么合并后用戶的權限為運營+編輯，反之就要去抉擇保留哪個角色。
由此可見，權限類數據對合并規則與業務息息相關，例如從不同獲取方式來看：
付費購買：此類權限是用戶付出金錢成本置換到的權限所有權，因此保留最高權限，維護用戶的利益；
系統賦予：
1）配置類：由具體業務限制決定是去重合并or保留一種權限；
2）積累類：雖然積分是用戶操作積累的，但考慮到合并的開發難度，也可以結合實際業務場景決定是只保留主賬戶積分or進行累計。可以換算成現金的積分需要進行累計，例如信用卡積分。
▋業務類
業務類數據是由于用戶操作或使用生成的業務流水/創造的數據，本著“數據是用戶操作產生的，用戶有對其的使用權及控制權，非用戶本人主觀操作數據不可變動，在操作時要避免歷史數據的丟失”的原則，對此類業務數據使用累計+重新排序的方式進行合并，一般是按照時間順序，例如用戶消息、訂單流水。此處就不對其進行展開描述。
總結
由上述全文可知，在處理合并賬號的歷史數據時，需要保證對所有歷史數據的兼容，保留所有原始數據；也要進行相應的限制，避免數據處理錯誤導致的數據錯誤等風險。
所以，【兼容】【限制】就是歷史數據處理的原則。萬變不離其宗，下一篇對系統打通歷史數據的處理，也會由這兩個原則出發，請大家拭目以待～
↘好文推薦：
王慧文清華產品課
寫給未來產品總監的一封信
菜鳥網絡?|?寄件業務的產品邏輯
點個“在看”吧
總結
以上是生活随笔為你收集整理的账号体系——账号合并的历史数据处理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 作为一名产品经理，我是如何快速做项目计划
- 下一篇： 数据产品必知的4层技术知识