編輯導(dǎo)語：ID mapping的建立有助于幫助營銷人員獲得渠道有效性的反饋，進而可以幫助營銷人員進行更加精準(zhǔn)的投放，在獲得用戶畫像反饋之后，也能進一步提升用戶體驗。本篇文章里，作者就B端用戶畫像中的ID mapping做了總結(jié)和梳理，一起來看一下。

一、引言

在《一篇文章讓你掌握企業(yè)畫像》一文中，提到企業(yè)畫像對于“達到一定用戶規(guī)模的面向中小型客戶的SaaS產(chǎn)品公司”是很有必要的。不過，建立企業(yè)畫像的基礎(chǔ)，首先是用戶ID mapping的問題。今天我們就來講講這個話題。

二、為什么要做ID mapping

假設(shè)這樣一個場景：

1. 第一天，客戶張三在公司電腦上看了一下產(chǎn)品詳情頁；
2. 第二天，他在手機上關(guān)注了公司的一個微信公眾號；
3. 第三天，張三在手機上看了三篇微信公眾號文章；
4. 第四天，張三在手機上下載了一個產(chǎn)品說明文檔，下載的時候他輸入了自己的郵箱；
5. 第五天，張三在公司電腦上申請了試用，試用的時候他用的賬戶就是他的郵箱，并且同時輸入了手機號；
6. 第六天，他用手機撥打了客服熱線，咨詢一個產(chǎn)品問題。

如果沒有ID mapping，客服人員就無從知道他已經(jīng)看過產(chǎn)品、公眾號，試用過產(chǎn)品，無法在第一時間準(zhǔn)確獲得張三的購買意向。并且隨著營銷渠道越來越多，如果不去識別碎片化的個人，客戶的行為就被割裂，從客戶角度考慮會影響客戶體驗。

從公司角度，我們也無法知道評估營銷渠道的有效性，即客戶買這個產(chǎn)品到底是因為只是看產(chǎn)品詳情頁，還是看了公眾號，還是二者皆有。

三、如何做B端的ID mapping

既然需要解決，我們或可采取兩個方案并舉。

方案1：在營銷階段盡可能多地捕捉用戶信息，比如在下載產(chǎn)品說明文檔或者試用時，不僅要求客戶填寫郵箱，還需要填入手機號。這也是為什么很多B端產(chǎn)品的下載或者申請demo要求用戶輸入更多信息的原因。當(dāng)然，這個方案的缺點是客戶很可能在這個階段就放棄繼續(xù)探索。

方案2：可參照目前C端的用戶畫像中的解決方案，利用一定的規(guī)則把割裂的行為串聯(lián)起來。仍然以上述用戶張三為例，在不同行為中，張三留下了不同的標(biāo)識，利用不同行為中共同的標(biāo)識，可以很容易地找到行為間的關(guān)聯(lián)關(guān)系，下圖紅色所示：

第一天，獲取了一個用戶，我們把Cookie ID 和設(shè)備ID1 作為用戶標(biāo)識保存起來，創(chuàng)建用戶001。

第二天，又獲取了一個用戶，我們把設(shè)備ID2和微信號作為用戶標(biāo)識保存，創(chuàng)建用戶002。

第三天，我們發(fā)現(xiàn)這個用戶的設(shè)備ID2和微信號和用戶002相同，我們初步判斷兩個行為背后是一個人。于是把這兩個行為關(guān)聯(lián)到一個人上。

第四天，我們發(fā)現(xiàn)這個用戶的設(shè)備ID2和用戶002的設(shè)備ID2相同，我們初步判斷兩個行為背后可能是一個人，于是把第四天留下的郵箱作為用戶002的標(biāo)識保存起來。至此，用戶001 和用戶002 還未建立聯(lián)系。

第五天，我們發(fā)現(xiàn)用戶郵箱和用戶002相同，設(shè)備ID1和cookieID 和用戶001相同。判斷用戶001和用戶002可能是一個人。于是將用戶001 和用戶002 合并。

合并后的用戶擁有以下ID：

• Cookie：Cookie ID；
• 設(shè)備號：設(shè)備ID1，設(shè)備ID2；
• 微信：微信號；
• 郵箱：郵箱；
• 手機：手機號。

第六天，我們發(fā)現(xiàn)，手機號和合并后的用戶一致，于是判斷打電話的行為和過去的行為背后是一個人。

細(xì)心的讀者可能會發(fā)現(xiàn)，你這有漏洞呀，比如第三天和第四天的行為，設(shè)備ID2很可能是被多人使用的，如果是這樣，郵箱和微信號之后無法建立聯(lián)系，在后面也就無法把用戶001 和用戶002 關(guān)聯(lián)起來了呀。

為解決這個問題，就需要我們從業(yè)務(wù)角度建立一些規(guī)則。這里就以筆者曾經(jīng)使用過的Segment 為例說明（Segment號稱是#1 CDP-Customer Data Platform to Manage Customer Data）。

Segment 有一個 three Identity Resolution rules——即三大用戶標(biāo)識識別規(guī)則，分別是：

1）Block Values. 管理員可設(shè)置某些值為無效值，比如公司內(nèi)部用的測試賬戶ID，某些一眼看上去無效的賬戶ID，比如0000@000.com。

2）Limit：即管理員可以設(shè)置某個類型的ID一個用戶最多在多長時間內(nèi)可以擁有幾個。比如cookie ID設(shè)為一天最多可以有10個，我想除非是測試，否則沒有哪個正常的用戶會一天清理緩存重新生成cookie 超過10次。比如設(shè)備ID， 我們估計一下?lián)Q手機換電腦的頻率，一個用戶一年應(yīng)該不會超過2次，可以設(shè)Limit 為2個每年。

這其中當(dāng)然有誤差，所以我們也要看具體業(yè)務(wù)場景。作為用戶畫像工具，我們應(yīng)該允許管理員靈活設(shè)置。

3）Priority：即當(dāng)某類標(biāo)識ID超出Limit規(guī)定的數(shù)量時，priority決定由哪個標(biāo)識留下作為新創(chuàng)建用戶的標(biāo)識。

引用原文例子說明一下，假如系統(tǒng)設(shè)立的limit 和 priority 分別如下：

假設(shè)系統(tǒng)中已有一個用戶， user id為abc，擁有郵箱tom@tom.com。此時又來了一個新用戶，user id是 def， 同樣擁有郵箱tom@tom.com。因為user_id的limit 為1，而user_id的優(yōu)先級高于email，那么我們對email 進行降級，只利用user id def 來查找是否有已有用戶存在，如果沒有，就新建一個用戶，user_id為def。

我們用這三個規(guī)則套路一下張三的例子：

第一天，我們把Cookie ID 和設(shè)備ID1 作為用戶標(biāo)識保存起來，創(chuàng)建用戶001；第二天，我們把設(shè)備ID2和微信號作為用戶標(biāo)識保存，創(chuàng)建用戶002；第三天，我們發(fā)現(xiàn)這個用戶的微信號和用戶002相同，微信號只能有一個，我們把這兩個行為關(guān)聯(lián)到一個人用戶002上。

第四天，我們發(fā)現(xiàn)這個用戶的設(shè)備ID2和用戶002的設(shè)備ID2相同，因為用戶002目前還沒有郵箱，把第四天留下的郵箱作為用戶002的標(biāo)識保存起來。

第五天，我們發(fā)現(xiàn)用戶郵箱和用戶002相同，而郵箱只能有一個，所以把行為關(guān)聯(lián)到002上，同時增加了手機號。并且發(fā)現(xiàn)設(shè)備ID1和cookieID 和用戶001相同。且cookie ID 和設(shè)備ID 的limit可以是多個，于是將用戶001 和用戶002 合并。

第六天，發(fā)現(xiàn)打電話進來的用戶手機號和合并后的用戶一致，于是判斷打電話的行為和過去的行為是一個人。

當(dāng)然，識別碎片化的人還可能會有更多場景，這里我們只是學(xué)習(xí)其中一種，我們還經(jīng)常遇到比如APP彈出一個加密的被識別出來的可能匹配的賬戶，讓用戶確認(rèn)，是否合并兩個用戶，這也是一種方法，這其中要同時考慮信息安全和客戶體驗。

四、總結(jié)

本文講述了B端用戶畫像中ID mapping的必要性，并以Segment為案例，提供了一個相對比較通用的解決方法供大家參考。但實際上ID Mapping的方法還有很多，大家也可以參考《阿里/網(wǎng)易/美團/58用戶畫像中的ID體系建設(shè)》學(xué)習(xí)。如有紕漏，歡迎指正。

參考文章

Segment幫助中心：

https://segment.com/docs/personas/identity-resolution/identity-resolution-settings/

作者：Simba，混跡于國內(nèi)外大廠的B端產(chǎn)品經(jīng)理；IT老兵，終生學(xué)習(xí)者；“數(shù)據(jù)人創(chuàng)作者聯(lián)盟”成員。

本文由@一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議