序言:傳統的零售業務進入了瓶頸期,「新零售」的概念層出不窮,看的眼花繚亂:全渠道/無人門店/無人貨櫃/新生態(盒馬鮮生/小米之家/天貓小店)等;各種技術概念更是看的一頭霧水:OneID、數據中臺、用戶中心、統一會員平臺和IDMapping等。本文主要內容是理清什麼是「會員ID打通」及應用場景,幫助企業更好的完成全渠道會員統一,多品牌的會員統一和用戶運營的精準化。數據庫
備註:本文提到的「會員」指泛會員,包含用戶、顧客、潛客或客戶。
對於會員ID打通包含兩大業務場景:微信
傳統業務共享模塊抽象工做,需詳細調研涉及用戶相關操做並抽象爲統一數據結構,如列如下場景和對應細化業務子流程:cookie
下一步須要抽象爲統一數據結構,可能以下:數據結構
會員基本信息:用戶ID、微信號、手機號、消費密碼、姓名、性別、收貨地址、年齡、積分、優惠券、標籤*等架構
註冊記錄表:註冊時間、註冊渠道、註冊詳細地址併發
綁定記錄表:綁定時間、選擇密碼方式、手機號碼、OpenId等app
會員變動記錄:會員帳號、帳戶變動時間、參與活動內容、帳戶變動信息等高併發
會員優惠券信息:會員ID、手機號、券號、券金額、券名稱、券張數、有效期、使用要求等相關的信息大數據
在技術上,以上信息會放入關係型數據庫,並提供高併發的服務接口供上層業務調用:如會員註冊,會員信息查詢/修改、優惠劵發放等,咱們常把這類定義爲用戶中心或統一用戶平臺,同理爲了知足企業更多業務需求,還會有訂單中心,商品中心等 ,傳統企業在架構設計上也會把這層統必定義爲數據中臺。微信支付
首先來認識下會有哪些識別ID,常見基本ID如: 手機號mobile、身份證ID和郵箱email;信息化軟件系統中用戶的惟一ID,如user_id;在PC時代最經常使用的cookie_id;在移動時代,APP的出現引入的各種設備ID,如imei/idfa和mac,微信產生的open_id;最近幾年發展迅猛的人臉識別產生的ID,如face_id。
如今讓咱們從另外一個維度對會員進行分類:可識別會員、可觸達會員和可描述會員,以下圖:
OneID的簡化結構可能以下:
以上的場景的產生有多是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屬於大數據應用建設範疇。
做者簡介:鐵叫獸,10年+數據相關經驗,曾在電信、阿里從事過DBA,數倉,解決方案,主要經歷了阿里去IOE和ONEID的核心coder,目前從事零售行業的解決方案。
【想了解更多內容可訪問數瀾社區——國內首個數據中臺交流社區(https://bbs.dtwave.com/topics...)】