首先我們要明白產品為什麼需要使用者id？

系統中儲存有各種資料，登入日誌，瀏覽日誌，訂單資訊，發貨資訊，投訴建議等。為了高效獲得使用者及其相關資訊，我們需要一個唯一的標識。

使用這個唯一標識，我們可以一次性得到使用者相關的所有資訊，而不用多次查詢，從而提高相應速度。

既然使用者ID是唯一的 我們就可以使用一些唯一的資料作為使用者的id

1、身份證號（護照號，軍官證）： 能保證唯一性，但是有個人隱私問題，不建議採用；

2、手機號：能保證唯一性，使用者如果換手機，這個就麻煩了；

3、自增長的數字：能保證唯一性，安全性有問題，容易被人踩到使用者id，進行一些攻擊； （當初qq號就是自增長的）

4、當前時間毫秒值：能一定程度保證唯一性，但是如果併發特別大的時候或者系統堵塞的時候，可能發生重複；

5、UUID：一個全球唯一的字串，需要一定的計算，可以接受，儲存需要一定空間長度。

6、唯一裝置資訊：網絡卡mac地址，手機串號，都不一定有許可權能獲得到相關資訊。

上面是已知使用者id產生方式， 比較常用的是2,3,5。 具體怎麼選擇要看產品特點，上述介紹僅供參考吧。

各類技術概念更是看的一頭霧水：OneID、資料中臺、使用者中心、統一會員平臺和IDMapping等。本文主要內容是理清什麼是“會員ID打通”及應用場景，幫助企業更好的完成全渠道會員統一，多品牌的會員統一和使用者運營的精準化。 備註：本文提到的“會員”指泛會員，包含使用者、顧客、潛客或客戶。

一. 什麼是會員ID打通

對於會員ID打通包含兩大業務場景：

1. 打通各業務系統相同識別ID形成會員ID，如透過把品牌A CRM與品牌B CRM中的會員進行打通（透過手機號），形成統一介面服務，再提供通用服務介面供業務系統進行呼叫，如：使用者註冊、使用者資訊修改、積分消耗、優惠劵傳送等。

2. 打通各業務系統不同識別ID形成會員ID，如透過使用者在淘寶的消費行為、微信上的點選瀏覽行為和線下門店消費形成全維度的使用者“全息畫像”，為使用者運營提供提供資料支撐，常見的業務場景有商品推薦、個性化活動推送等，主要用於提高老客復購率或連單率等指標。

二. 業務場景一：打通各業務系統相同識別ID形成會員ID

傳統業務共享模組抽象工作，需詳細調研涉及使用者相關操作並抽象為統一資料結構，如列以下場景和對應細化業務子流程：

下一步需要抽象為統一資料結構，可能如下：

註冊記錄表:註冊時間、註冊渠道、註冊詳細地址

繫結記錄表:繫結時間、選擇密碼方式、手機號碼、OpenId等

會員變更記錄: 會員賬號、賬戶變更時間、參與活動內容、賬戶變更資訊等

會員優惠券資訊: 會員ID、手機號、券號、券金額、券名稱、券張數、有效期、使用要求等相關的資訊

在技術上，以上資訊會放入關係型資料庫，並提供高併發的服務介面供上層業務呼叫：如會員註冊，會員資訊查詢/修改、優惠劵發放等，我們常把這類定義為使用者中心或統一使用者平臺，同理為了滿足企業更多業務需求，還會有訂單中心，商品中心等 ，傳統企業在架構設計上也會把這層統一定義為資料中臺。

三. 業務場景二：打通各業務系統不同識別ID形成會員ID

首先來認識下會有哪些識別ID，常見基本ID如: 手機號mobile、身份證ID和郵箱email；資訊化軟體系統中使用者的唯一ID，如user_id；在PC時代最常用的cookie_id；在移動時代，APP的出現引入的各類裝置ID，如imei/idfa和mac，微信產生的open_id；最近幾年發展迅猛的人臉識別產生的ID，如face_id。

現在讓我們從另一個維度對會員進行分類：可識別會員、可觸達會員和可描述會員，如下圖：

以上的場景的產生有可能是OneID1是線上淘寶消費，OneID2是線下微信支付消費, 兩者透過相同的mobile進行打通，OneID1和OneID2可能是同一個人也可能是一個家庭，透過IDMapping就可以打通OneID1和OneID2背後的標籤，從而讓使用者運營可變的更加真實和立體。

備註：真實業務場景會更加複雜，ID和ID的轉化都需要考慮機率，如mobile1和mobile2都是從收穫地址獲取的手機號，mobile1出現次數機率為70%（10個訂單），mobile2 出現次數機率為30%，那Oneid1轉手機號，機率最高的就為Mobile1，mobile2轉Oneid，機率最高的為Oneid2（機率為1），OneId1僅為30%。

總結：透過以上介紹，相信各位對“會員ID打通”的基本分類和應用場景有了基本理解，在實際專案落地過程中場景1和場景2也並無衝突，場景1屬於傳統資訊化建設範疇，場景2屬於大資料應用建設範疇。