起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據埋點：用戶唯一標識
用戶唯一標識，是用戶唯一的身份ID，相同的身份ID，就會被當做是相同的一個用戶。
01?為什么要建設用戶唯一標識
如何區分某個用戶就是他這個用戶，而不是另一個用戶，在數據埋點中，是一個非常重要的事情。因為如果做不到用戶的唯一識別，那凡是涉及到用戶的數據都將是錯的（比如用戶量、新增用戶數、活躍用戶數等等）。所以建設用戶唯一標識，尤為重要。
02?基本概念
設計埋點字段的時候，有兩個字段是一定要包括的，即設備ID和用戶ID。這兩個字段應該納入通用字段，每個埋點的事件都必須要集成收集。
（1）設備ID
使用相應的算法，生成一個設備ID，以唯一識別用戶的終端設備。不同終端的設備ID，其生成算法規則不一樣，以下列舉不同終端的設備ID的生成規則：
AndroidApp
安卓系統歷經多次升級，對權限控制越來越嚴格，唯一識別手機的方法也在發生變化。下面整理一下安卓系統適合做設備唯一標識符的幾個標識符，以及其特性：
從表格中看出，IMEI是最適合做設備唯一標識的，奈何獲取IMEI需要授予權限且Android 10以后不再開放IMEI的權限。綜合起來，安卓系統中，應該按照IMEI ->OAID -> ANDROID_ID的順序生成設備ID。即先獲取IMEI號，獲取不到IMEI時獲取OAID，獲取不到OAID時，再獲取ANDROID_ID，然后使用相關算法生成設備ID。
IOS App
蘋果系統，可用于識別唯一設備的標識不多，如下圖。綜合起來，蘋果系統生成設備ID的標識符順序應該是IDFA -> IDFV ->UDID，即先獲取IDFA，獲取不到在獲取IDFV，獲取不到IDFV時，再獲取UDID，然后使用相關算法生成一個設備ID。
Web網站
Web網站，使用cookie_id作為設備ID，并存儲在瀏覽器的cookie中。
微信小程序
通常做法使用openid作為設備ID，當然也可以自己生產一個ID，作為設備ID。如果用過openid作為設備ID，需要注意微信小程序的冷啟動問題（獲取 openid 是一個異步的操作，所以會導致數據上報的時候，可能還沒獲取到openid，這就是導致設備ID為空）。
2）用戶ID
用戶ID，即用戶在業務產品注冊的用戶賬號。
收集到設備ID和用戶ID后，就要想辦法將設備ID和用戶ID關聯起來，也即用戶唯一標識建模，詳見下文。
03?用戶唯一標識建設
設計一個字段，比如就叫distinct_id（設備ID命名為device_id，用戶ID命名為user_id）這個字段用于識別唯一用戶。凡是統計用戶相關的數據時，都以distinct_id作為用戶的唯一區別標識。下面，以具體案例進行闡述。
步驟說明：
- 小明在一部手機上啟動了app。該手機的device_id為x1，此時生成一個dsitinct_id為d1；
- 小明在這個手機上用賬號u1進行登錄。此時device_id為x1，user_id為u1，dsitinct_id為d1；
- 小明繼續在這手機上使用app。此時device_id為x1，user_id為u1，dsitinct_id為d1；
- 小明退出自己的賬號，繼續使用app。此時仍然device_id為x1，user_id為u1，dsitinct_id為d1；
- 小明把手機給了小花，小花用自己的賬號u2登錄app。此時u2去關聯x1，因為x1已經與u1關聯，故關聯失敗。所以重新生成一個distinct_id為d2來標識此用戶（u2）；
- 小花繼續使用app。此時device_id為x1，user_id為u2，dsitinct_id為d2；
- 小明換了部新手機，使用app。此時device_id為一個新的x2，后臺生成一個新的dsitinct_id為d3；
- 小明在新手機上，使用賬號u1登錄了app。此時u1去關聯x2，因為x2之前沒有與賬號關聯過，所以關聯成功，但是u1已經有一個dsitinct_id為d1，所以此時的dsitinct_id仍然為d1；
- 小明繼續在新手機上使用app。此時device_id為x2，user_id為u1，dsitinct_id為d1。
此時三個字段的映射關系為：
（1）后續修復
事件字段修復
小明換新手機后，在登錄前，系統給分配的dsitinct_id為d3，不符合實際情況，故要將在新手機上登錄前的dsitinct_id修復為d1。如下：
映射表修復
1）刪除d3與x2的映射關系
2）將x2添加到d1的device_id_list字段
本文由 @如琴留音 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
『新手機上登錄前的dsitinct_id修復為d1』 確實在新的行為中能很好的識別為同一個用戶。但是歷史行為的數據要還要處理（在換新手機且未登錄的情況下產生的行為數據），請問有沒有好的辦法？
請問一下，小明把手機給小紅用了，但是小紅是在沒有登錄的情況下使用，這時候的行為是算誰的行為數據
4、小明退出自己的賬號，繼續使用app。此時仍然device_id為x1，user_id為u1，dsitinct_id為d1；
我理解，同一部設備，原賬號退出，只要在沒有新賬號登錄的情況都是認為是上一個賬號的行為。因為我們沒有手段去確認是否換人了。我感覺可行的是利用行為分析，現在的行為和上個賬號行為存在差異了認為是一個新賬號，但是會誤殺。一個技術的理解。
我請教個問題，按照你的舉例，如果設備登錄小明和小紅的賬號（設備X1被兩個用戶ID都綁定了），此時設備退出了登錄的情況使用，設備是采用d1還是d2？
同問
最后一次的distinct_id吧，因為在最后一次用戶登錄的時候distinct_id已經被修正了；
d1是小明的話
d2是小紅的話
設備退出了 就是d3
請問你們埋點是接的三方服務嗎？
哎，這也不是您的原創。這是神策數據對用戶標示的闡述啊。 你說的distinctid在大部分公司很難解決的。大部分使用的匿名ID和userID。
建設思路是參考神策的，之所以后面的例子也是用的它的例子，是因為人家神策這個例子很好，我沒必要在另外寫一套了。畢竟，最重要的是讓大家知道怎么做嘛
沒明白啊 最終的結果還是用戶ID是唯一的表示啊 跟設備id沒關系啊
表面上看起來，用戶user_id作為唯一標識也沒問題，因為user_id和dsitinct_id是一一對應的
但是如果將user_id作為唯一標識的話，會有什么為題呢？
1、不清楚登錄前和登錄后的行為是否是同一個用戶，因為登錄前的用戶ID為空。而dsitinct_id則不會有這個問題
2、現實業務場景中，很多用戶都不會登錄賬號，這個時候用user_id算用戶量的話，就是不準確的，因為很多user_id為空
而使用device_id作為用戶唯一標識符呢？
使用device_id作為唯一標識符的話，那自己產品的賬號體系就完全失效了，明顯就不符合業務需求了
同一個賬號可登陸多個設備，同一個設備也可登陸多個賬號，登錄賬號前和登錄賬號后，到底用設備ID還是用戶ID作為用戶唯一標識呢，問題就復雜了。而引入了distinct_id的概念后，統一用distinct_id作為用戶標識符，就簡單很多了。
怎么知道是小明換了把手機而不是另一個用戶未登錄使用呢
那請問一下，如果小名換的是一部舊手機，剛好這個舊手機也被其他人未登錄使用過并且產生了使用數據，這時候小明再去進行使用并登錄，那么小明更換后的手機未登錄前的數據算誰的呢？
dsitinct_id 以什么樣的規則生成呢? 應用卸載后，如果沒有用戶的情況下，將如何？
記錄的是用戶數據，即使卸載了，也不影響數據庫里的數據啊
不錯 學到了
您的d1 d2 最后就是u1 u2呢 hhh
記了設備id
您好，方便加一下聯系方式嗎？
能方便透露一下，是什么事嗎？
大概是想擴列吧
擴列，這是00后才懂的交友方式