編輯導讀：當越來越多的產品需要賬號綁定時，很多人會用不常用的手機號或者微信號綁定。如果體驗良好，準備切換成真正想要綁定的手機號或三方賬號時，就產生了一個需求——賬號換綁。本文圍繞賬號換綁展開了四個方面的分析，希望對你有幫助。

平臺想要給用戶提供個性化的服務，就需要有一個可以唯一識別用戶的標識。而賬號，就是這個標識。用戶可以使用手機號、郵箱、各類第三方賬號登錄等方式在平臺註冊賬號，平臺通過用戶的註冊信息，爲用戶創建一個UserID。這樣，賬號慢慢就變成了一根紐帶，維繫着用戶—產品 —企業的良性發展。

一、賬號體系的確認

賬號體系發展至今，大致的賬號類型可歸納爲以下四種：自定義賬號、郵箱賬號、手機號賬號、第三方賬號。各自的特點如下表所示：

不同的產品，由於其自身類型不同，應按照實際使用情境設計對應的賬號體系。最簡單的思考方式是：核心業務以什麼爲基礎，就用它來設計賬號體系。

我們是保險產品，與用戶的溝通方式主要是電話+微信。因此選擇了手機號賬號，同時會將用戶與平臺溝通的微信綁定在用戶賬號體系上。

二、需求背景

現在啊，體驗個啥產品幾乎都要註冊一下。用戶爲了儘可能的避免自己被騷擾，會有兩個很常見的行爲：用不常用的手機小號去註冊賬號授權不常用的微信賬號、微博賬號、支付寶賬號……

一段時間過去了，當用戶發現產品提供的服務不錯，準備切換成真正想要綁定的手機號或三方賬號時，就產生了一個需求——賬號換綁。

我們的產品根據用戶手機號爲其創建UserID，輔以微信號填充用戶的暱稱、頭像等信息。因此，本文的換綁流程以微信號換綁和手機號換綁的流程爲例進行梳理。

三、換綁微信號

最常見的換綁微信號觸發的場景是：用戶最開始在微信小號上登錄了我們的產品，系統將微信號與手機號進行綁定。一段時間後，用戶感覺服務不錯，順手在常用微信號上登錄或註冊我們的產品。

當用戶在微信號內登錄/註冊時，系統檢查手機號與微信賬號的關係。手機號未註冊，未綁定微信：註冊User+綁定手機號與微信手機號已註冊，未綁定數據庫某一User的微信：將手機號與微信綁定手機號已註冊，綁定了本微信：暫時不支持登出，綁定過了會一直在線，此情境不存在手機號已註冊，綁定了數據庫某一User的微信：開啓換綁微信號流程

我們都期望自己的賬號是安全可靠的，那換綁情境下的賬號安全可以靠什麼守護呢？

可以通過用戶的真實信息和一些換綁的規則限制，例如：不能無限制的換綁。給換綁做一個時間限制，例如一年只能換綁一次，用戶2020-08-09更換了微信賬號，那下次可以更換的時間就是2021-08-09後（2021-09-09 00:00:00）。這個時間最好使用配置實現，上線觀察用戶的換綁數據，可根據實際情況進行調整。進行身份信息認證。如果用戶曾經在使用產品時提供過真實的身份信息，那就對這個身份信息進行認證，例如用戶身份證實名認證+OCR校驗+與之前身份信息的對比。如果用戶還未提供過真實的身份信息，那也還是需要做身份認證的，只是這個認證不能和之前的信息做對比，只能是身份證實名認證+OCR校驗。如果有需求的話，可以在用戶未提供過真實的身份信息這種情景下加入人工審覈流程進行校驗

四、換綁手機號

換綁手機號的頁面看起來多了很多，但是驗證的信息與邏輯會比換綁微信號簡單。概括來說就是：用戶最初在產品的個人中心（微信內）找到換綁手機號的入口，然後驗證當前手機號的驗證碼，再輸入想要和當前微信號綁定的手機號+驗證碼。驗證沒有問題，即可換綁成功。

使用手機號做賬號會有兩個比較常見的問題：手機號停用、運營商二次放號。手機號停用。那便接收不到驗證碼信息，自然也不可通過驗證碼自助換綁。我們不能問用戶，爲啥你都停用了纔想起來換綁？我們只能提供一種方式，讓停用的手機號也能換綁。解決這個問題的本質在於：通過身份驗證來確保用戶本人在操作。和換綁微信號時的思路一樣，如果用戶曾經在使用產品時提供過真實的身份信息，那就對這個身份信息進行校驗。如果用戶還未提供過真實的身份信息，那隻能是身份證實名認證+OCR校驗+人工審覈運營商二次放號。當用戶手機號換綁成功後，將用戶原來的手機號註銷掉，如果原來的手機號再來註冊，那就是一位新用戶。

五、小結

不難看出，本次微信號和手機號的換綁都做了一個限制：手機號（微信號）暫未綁定其他微信號（手機號），這是因爲：如果A手機號和B手機號之前分別和A’微信號和B’微信號是綁定關係，且每一對賬號下都有歷史數據。

那換綁操作就不單純是換綁了，還牽扯到賬號的合併，咱們下一篇再討論～

本文由@404查無此人 原創發佈於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基於CC0協議。

相關文章