詳解ID拉通 | CDP 智庫系列文章 ②

企業在日常的經營活動中，會積累大量的數據，這些數據由于來源、格式各異，容易形成一個個「數據孤島」?！笖祿聧u」的存在，會阻礙企業更好地認知客戶、與客戶溝通。因此，企業搭建CDP后，積累了一定的客戶ID后，首先要做的就是ID拉通（ID mapping）。

ID與ID拉通

ID是英文Identity的縮寫，它是一種互聯網身份認證協議，具有唯一性，代表了用戶在企業中可識別的「身份」。通過對ID的管理，能夠發現用戶的個人信息、購物喜好等有助于營銷活動的信息，為用戶提供更好的服務。營銷人員接觸較多的ID有cookie、IDFA、Device ID、Union ID等等。

PC時代，主要的ID是cookie，企業主要依靠cookie mapping做ID拉通，相對較為容易識別客戶；而在移動互聯網時代，ID出現封閉化的趨勢，各大平臺、電商渠道陸續推出自己的ID，搞「封閉式管理」。對企業來說，這些ID都是與用戶相關的數據，卻各不相同，企業也就無法完整地洞察消費者甚至做營銷。因此，企業迫切需要進行ID拉通。ID 拉通是 CDP 里面的一個很重要的功能，是用戶精細化運營的基礎，簡單來說就是將一個用戶在不同觸點的 ID 識別為同一個人。

與ID拉通意義相關聯的一個詞是「數據打通」。悠易互通CDP產品總監吳潔介紹說，ID拉通包括兩個步驟，首先是ID之間的打通，即提取出所采集到的數據里的ID信息，這時候會形成多個ID，再將多個ID下的行為、屬性等數據串在拉通后的ID上面，這個步驟是數據打通。也就是說，ID拉通與數據打通是銜接的過程。

悠易互通CDP數據技術專家李智敏補充說，ID拉通從功能方面來說，分為廣義和狹義的概念。從廣義來說，ID拉通就是一種數據打通，將原本存在于各個「數據孤島」的數據按照某種規則組織起來，它是包括用戶在內的各類數據，例如物品、設備等；從狹義來說，ID拉通則是將原本分散在不同渠道的用戶數據統一匯聚和拼接，形成完整的用戶信息視圖，一般所指的實體只包括用戶。

ID拉通的步驟

ID拉通有強ID拉通、算法拉通等多種方法，其中最為簡單的是基于優先級的強ID拉通，對采集到的用戶屬性、用戶行為等數據直接進行關聯。這種拉通方式對數據量級和ID類型都會有一定限制，ID類型最好不超過10個，若ID類型過多，會嚴重影響計算的效率；

上述方法針對沒有形成ID關系對的數據進行拉通較為困難，所以，更為寬泛的一種拉通方式：基于某些特征數據實現的算法拉通對事實拉通進行了有效補充，算法拉通采用聚類等數學方法和技術進行計算準確率。還有一種拉通方式是第三方ID拉通，例如與騰訊、阿里等平臺方合作，可能會受限于平臺方的規制，這也是企業開始追求第一方數據的重要原因之一。目前，悠易互通采用的主要是圖計算的方式，這種方式大大提升了ID拉通的計算效率，可以就任意的ID進行拉通。這種方式解決了強ID拉通方法受ID數量限制的問題，也保證了準確率，只要拿到了數據，拉通出的結構必然是真實的。

吳潔介紹了幾種ID拉通方案的步驟。強ID拉通的方法，首先確定最高優先級，通常是手機號碼——當然一些行業會采用特殊的ID，如汽車業選擇身份證號或者車架號作為最高優先級——如果ID里有手機號，就通過手機號拉通。還有一種規則是確定各個ID的優先級，例如依次為手機號、郵箱、Union ID等等。這種強ID拉通的方法采用的是「一對多」的形勢，但在有些條件的限制下（如用戶變更手機號），就會基于優先級形成一個新的用戶，則沒有辦法實現真正意義的拉通。

悠易互通所采用的圖計算解決的是多對多的問題。只要所獲取的ID中有兩個能關聯起來，通過這兩個ID之間的關系，就能把其他能得到關系的ID都串聯在一起。即便缺少用戶手機號，沒有郵箱這種強PII的ID，僅僅依靠Open ID、Union ID甚至cookie，都有辦法找到關聯關系并串聯在一起，這些ID之間是沒有優先級的。

吳潔舉例說，悠易互通曾經服務一個汽車客戶，客戶剛上線了系統，用七部手機進行測試。因為有七個手機號碼，通常情況下會被識別為七個人。但在測試過程中發現，有兩個不同的手機號在一次session中登陸了客戶的賬號體系，但是顯示為一個cookie。雖然cookie的優先級較低，但在這個session里只有這一個cookie，形成了較強的邏輯關系，證明這兩個手機號碼所登錄的兩個內部的CRM ID其實是一個ID。通過這樣的方式，這七個手機號都串成了一個人。

圖計算在ID拉通中的應用

圖計算是將各類數據關聯起來，將不同來源、不同類型的用戶 ID 數據融合到同一個圖計算模型中進行分析，得到原本獨立分析難以發現的結果。圖計算與知識圖譜相關聯，可以幫助營銷人員根據地域、社交和職業網絡、產品、品牌和購買力等維度，對復雜的顧客數據進行建模。最初圖計算應用較多的是司法刑偵領域，理清楚犯罪嫌疑人的各種社會關系。圖計算所針對的數據并不考慮它是來自于第一方或第三方數據，而是具體的數據來源。例如營銷人員獲取了客戶的第三方交易信息，包括有贊的會員ID，以及下單時使用的手機號碼，就可以拉通有贊ID、手機號以及內部的Union ID之間的關系。

悠易互通采用圖計算的方式，通過尋找兩兩相關的關系，形成更為穩定的ID關聯，形成用戶ID圖譜。即便用戶更換了手機號碼，只要其他ID之間的關聯關系還存在，就可以繼承兩個手機號之間的關系，可以把他歸為同一個人。圖計算可以讓ID拉通的穩定性極大提升，更加精準識別到同一個客戶。

李智敏介紹說，圖計算描述的其實是不同對象之間的關系。類似于關系數據庫，圖計算本身是一種數據結構，包含了「點」和「邊」兩種形式：「點」指的是研究對象，對象有多個屬性；「邊」是兩點之間的線，用來說明兩者之間的關系。

圖計算的第一步是建模，圍繞對象設計一個基礎的模型，亦即最基礎的數據單元。對于營銷人來說，第一步相當于廣告行為，理解通過廣告獲取的IDFA、OAID等數據。

第二步，設計存儲，即用何種方式存儲數據，一個對象可能涉及多種數據存儲的方式。這一步的目的在于明晰用戶行為，就是除了廣告行為之外，用戶的實際行為，比如說在小程序、官網、App等渠道的行為。這一步獲取較多的是用戶的 Open ID、Union ID、cookie甚至CRM ID等等。

第三步，基于最基礎的數據單元和存儲，設計解決方案，特別是基于圖計算的基礎概念去進行設計，描述不同對象的數據結構，理清楚數據源。這一步是為了搞清楚用戶屬性。吳潔補充說，用戶屬性如性別、年齡等相對來說比較靜態的，不是某個具體時間段發生的事情，而是用來描述用戶具體屬性特征的信息。

第四步，一切就緒之后，開始正式的計算，描述出整個數據結構，形成一個最大聯通圖，可能涉及到成千上萬乃至上億條數據。最終將所有關系都拉通為一個One ID。

公域與私域之間的ID拉通

圖計算是基于事實的ID拉通方法，建立在獲取用戶的手機號碼基礎上；而對于家庭用戶，則是通過算法，算法依賴的條件是一定的數據特征輸入，例如ip、時間戳、UA信息等。例如對于OTT用戶，往往缺乏用戶的登錄信息、或者其他實信息幫助直接拉通，只能預估這些設備有可能屬于同一個家庭。蔡芳具體解釋說，現在每個家庭都有一個固定的WiFi，以此為前提，如果手機登錄了悠易互通所掌握的流量中的一些資源，也就是拿到廣告曝光點擊的日志，日志里會有用戶的IP時間戳，能看到IP和出現的時間，與家中的OTT的IP和時間做匹配，找出這些信息之間的特征，再通過頻次等閾值過濾掉家中訪客等情況，最后形成設備與設備之間的關系，以此來映射家庭中的數據結構。

當然，這種基于算法的ID拉通的準確性，不如基于事實的ID拉通。營銷人往往會在算法拉通與事實拉通之間有一個優先級的判斷。如果一個ID的算法拉通也實現了，事實拉通也實現了實名關系對，肯定會優先選擇事實拉通。

公域與私域之間的拉通，因為媒體平臺的封閉性，也主要是基于算法拉通。吳潔介紹說，為了實現拉通，必然會損失一部分精準度，亦即找到準確性和拉通率中間的平衡點，最終形成一個大家都認為數據可行的值。蔡芳提出，如果ID拉通的目的是為了進行一對一的溝通，對精準度的要求是很高的；但是很多營銷活動的目的是為了做廣告，對于規模的要求大于準確性，不能因為追求準確的匹配，而只有很少的一部分ID拉通，達不到一定規模，廣告也沒有效果。所以廣告是要犧牲一部分精準度，在規模和精準之間取得平衡的。

悠易互通也會遇到客戶的特殊要求，拉通一些特殊的數據，即除了手機號碼、Device ID或者cookie等常用ID之外的系統ID。這時候，悠易互通會在原本基礎上做一些擴展。吳潔介紹說，悠易互通曾經服務某個車企，客戶有非常明確的數據安全要求，在前端做埋點上報的時候，不會提供任何形式的手機號，僅僅提供CRM ID，也就是用戶登錄了官網或者小程序后的信息。但是CRM ID是客戶自己生成的字符串，沒有辦法應用。這時候，需要將CRM ID與業務后端的某個ID拉通，再找出業務后端對應的手機號碼，去做下游的應用。通過這種擴展方式，才能夠支持基于CRM ID的拉通，找出CRM ID對應的手機號碼，并且把號碼輸出給悠易互通的營銷自動化平臺進行其他營銷活動。目前，悠易互通的系統不僅僅針對某個客戶做非定制化開發，任何客戶只要定義ID屬于哪個外部系統，并且在外部系統中唯一可標識用戶的，悠易互通都可以對整個業務實現ID拉通，最終形成應用閉環。

需要強調的是，整個ID拉通過程都是在客戶的第一方數據庫里進行計算，而且在對用戶數據進行處理的時候，需要對手機號碼、open ID等數據進行MD5的32位加密，再進行計算拉通。MD5即MD5消息摘要算法，一種被廣泛使用的密碼散列函數，可以產生出一個128位（16個字符）的散列值（hash value），用于確保信息傳輸完整一致。

吳潔介紹說，悠易互通采取了兩種識別方式：如果上游提供的明文數據，悠易互通會做一層加密處理；如果上游提供了32位加密數據，悠易互通會保持加密結果。而在輸出的時候，如果是MD5的數據，輸出的時候同樣保持MD5；如果上游提供了明文數據，下游可以選擇明文或者MD5。

ID拉通不僅僅是技術問題

ID拉通涉及大量的技術，但不僅僅是一個技術問題，用蔡芳的話說，它其實是一個運營問題。讓用戶通過廣告觸及小程序、H5頁面，甚至授權手機號，最終從匿名實現實名化，都需要一系列的運營方式。特別是客戶需要有ID拉通的意識，知道ID拉通對企業的消費者運營非常重要。

蔡芳介紹說，悠易互通的某些客戶，希望通過不錯的官網流量實現轉化，但是在注冊會員這一步驟，使用的是郵箱注冊，用戶需要回到郵箱收取驗證，再跳轉回來完成注冊，而在公眾號、小程序等渠道，沒有一個地方讓用戶輸入郵箱。這樣做，使得網站的注冊用戶無法與公眾號、小程序打通.

其實對于客戶來說，最好的方式是讓用戶授權手機號，首先是降低門檻，讓用戶通過小程序等比較便捷的方式留下手機號，而不是用填表單、填郵箱地址等用戶較為抵觸甚至會給用戶帶來麻煩的方式；其次是創造一些場景，讓用戶愿意留下手機號碼，如發紅包、注冊有獎等方式。悠易互通的某個快消品客戶，在春節用發紅包的方式，獲取了一個億的手機號碼，實現了手機號與Union ID的拉通。

案例：悠易互通為某車企拉通One ID

某汽車品牌計劃推出一款新能源車型，采用DTC模式，即通過小程序、官網、APP等自有渠道售賣?？蛻粝Ｍ罱繕擞脩舻乃接蛄髁砍?，即將以往的老客戶以及通過廣告、線上注冊等活動搜集的新客戶都引入新用戶平臺，并基于這個平臺發起種草、主題活動等營銷活動，讓用戶對新款車型有深入了解乃至互動。

由于這些用戶在不同系統注冊了不同的賬號，客戶希望把這些用戶識別為One ID。用戶現有的數據量有幾十萬，但是數據維護的工具僅僅是Excel?？蛻粝Ｍㄆ谧鲆恍┗顒?，與老車主互動，但是用Excel顯然無法完成?；谶@樣的背景，客戶委托悠易互通搭建CDP，主要解決私域數據采集的問題。

客戶有專門的數字化部門，但是整體負責CDP項目的其實是市場部，市場部內部有一些數據分析人員、會員營銷人員、活動組織人員。換句話說，市場部是CDP的主要用戶。至于其它APP、小程序等產品開發，有單獨的部門負責設計，以及外包給供應商做開發。市場部希望通過CDP，完成數據分析、人群圈選等工作，并以此為基礎，通過觸點采集到一些優質的leads，在后續的銷售過程中形成轉化。

經過分析，客戶掌握的數據源，主要有老車主的數據（包括車牌號、電話以及其他基礎信息），私域流量數據（包括官網數據）。在埋點過程中，能獲取到官網數據的cookie信息，小程序可以獲取用戶的Open ID，UNI ID，以及授權之后的手機號碼；App端可以獲得一定的Device ID。

值得一提的是，客戶搭建了很強的登錄注冊體系，某一個時間段的KPI就是注冊的新用戶量，而在注冊的過程中，出于數據安全的考慮，前端并不上報任何的實名手機號信息。此前，悠易互通所支持的ID拉通的范圍，主要支持市場上通用的ID類型，包括Open ID，Union ID，手機號，cookie都在拉通范圍之內。但是實名制情況下，如果用戶在前端不上報手機號碼，就意味著這些非實名的ID沒有一個key去進行拉通。

這時，客戶提供了幫助，前端上報的時候會提供CRM ID，也就是上報的用戶在注冊完成之后，后端業務系統里會生成一個CRM ID，這個CRM ID與手機號碼有對應關系，CRM的數據通過業務后端上傳到CDP。也就是在整個前端拉通的過程中，可以拉通cookie與CRM ID的關系，以及CRM ID與Open ID以及Union ID的關系，甚至拉通CRM ID 和MA或者IDFA的關系，最終實現全鏈路的拉通。

在拉通過程中，出現了一些異常ID，需要從系統中剔除，而引發了一些清洗工作，讓這些ID產生的數據不入庫。此外，悠易互通的CDP產品在過程中進行了升級，也能夠支持任意業務后端的ID進入ID拉通的體系之中。

出于數據安全的考慮，客戶要求所有上游數據能夠進行MD5加密，其中涉及到一些歷史數據。悠易互通先行將這些沒有MD5加密的手機號碼先進行了加密處理，再用于拉通，還能反向查出來MD5對應的手機號碼的明文或者密文，也就是傳上來的原值。

數據拉通最終形成的One ID，包括Open ID、Union ID、Device ID、手機號、cookie等不同來源數據的數組，以及不同外部系統自己的ID。例如除了CRM，One ID還與呼叫中心的數據進行打通，呼叫中心生成的用戶的ID也納入ID拉通的范疇。

悠易全域CDP先找到前端用戶行為發生時的CRM ID，拉通之后，用拉通后的OneID再找到后端CRM ID對應的手機號碼，接下來就可以進行短信發送等各項營銷活動。