賬號(hào)體系(2):賬號(hào)數(shù)據(jù)的打通與合并
編輯導(dǎo)語(yǔ):在上一篇文章中,作者帶我們了解了帳號(hào)換綁的問(wèn)題,除了換綁以外,賬號(hào)數(shù)據(jù)的打通和合并也是經(jīng)常可見(jiàn)的;本文作者分享了關(guān)于賬號(hào)體系中,賬號(hào)數(shù)據(jù)的打通與合并,我們一起來(lái)看一下。
一、背景
上一篇說(shuō)到了賬號(hào)換綁,下面就再來(lái)說(shuō)一說(shuō)賬號(hào)的打通與合并。
先來(lái)看看兩個(gè)場(chǎng)景:
場(chǎng)景一:產(chǎn)品A和產(chǎn)品B同屬公司甲;產(chǎn)品B是新業(yè)務(wù)線的新產(chǎn)品,是位產(chǎn)品小老弟;產(chǎn)品A是成熟業(yè)務(wù)線的成熟產(chǎn)品,是產(chǎn)品A的老大哥。
考慮到現(xiàn)在流量這么貴,小老弟想求老大哥帶一帶自己,老大哥答應(yīng)將用戶(hù)的部分?jǐn)?shù)據(jù)同步給產(chǎn)品A……在此場(chǎng)景下,我們可以延伸出賬號(hào)打通的需求。
場(chǎng)景二:產(chǎn)品C有微信注冊(cè)、手機(jī)號(hào)注冊(cè)、微博注冊(cè)等多種注冊(cè)登錄方式;因此一位用戶(hù)可能有多個(gè)賬號(hào):賬號(hào)一、賬二、賬號(hào)三。
有一天,用戶(hù)突然想將自己所有的賬號(hào)合并成一個(gè),便于記憶與使用;用戶(hù)在賬號(hào)一發(fā)起合并,在合并完成后,用戶(hù)的操作數(shù)據(jù)將都將在賬號(hào)一上展示,這就是賬號(hào)的合并。
從上面的場(chǎng)景不難看出,賬號(hào)的打通與合并實(shí)際上就是賬號(hào)中數(shù)據(jù)的打通與合并。
二、概念
1.?賬號(hào)數(shù)據(jù)打通
賬號(hào)數(shù)據(jù)打通,實(shí)際上是指一位用戶(hù)的數(shù)據(jù),可在多個(gè)產(chǎn)品間流通共享;通常是由公司業(yè)務(wù)發(fā)展而產(chǎn)生的需求,需用戶(hù)授權(quán)同意產(chǎn)品想要獲得的數(shù)據(jù),用戶(hù)不可主動(dòng)發(fā)起。
賬號(hào)數(shù)據(jù)的打通可以分為單向打通和雙向打通:
1)單向打通
舉個(gè)特別常見(jiàn)的例子——微信授權(quán)。
產(chǎn)品A想要得到用戶(hù)在微信內(nèi)的部分?jǐn)?shù)據(jù),產(chǎn)品A申請(qǐng)用戶(hù)同意數(shù)據(jù)授權(quán),用戶(hù)同意,產(chǎn)品A調(diào)用微信提供查詢(xún)接口獲得數(shù)據(jù);在這一頓操作中,微信不會(huì)受產(chǎn)品A中用戶(hù)數(shù)據(jù)的影響。
2)雙向打通
雙向打通的需求一般產(chǎn)生于強(qiáng)強(qiáng)聯(lián)合的合作關(guān)系;例如用戶(hù)在淘寶新增了一個(gè)收貨地址,且用戶(hù)的淘寶與咸魚(yú)的賬號(hào)相通;當(dāng)用戶(hù)打開(kāi)咸魚(yú),會(huì)發(fā)現(xiàn)新增的收貨地址從淘寶同步到咸魚(yú)了。
無(wú)論數(shù)據(jù)是單向打通還是雙向打通,用戶(hù)的數(shù)據(jù)總量是不會(huì)變化的,只是用戶(hù)的數(shù)據(jù)會(huì)在產(chǎn)品間流轉(zhuǎn)。
2.?賬號(hào)數(shù)據(jù)合并
賬號(hào)合并,就是將產(chǎn)品內(nèi)用戶(hù)的多個(gè)賬號(hào)合N為1,賬號(hào)的類(lèi)型可以相同,也可以不同:
1)相同類(lèi)型
用戶(hù)在一個(gè)產(chǎn)品中,用兩個(gè)手機(jī)號(hào)注冊(cè)了兩個(gè)賬號(hào),現(xiàn)在希望將其合并為一個(gè)賬號(hào),這是相同類(lèi)型賬號(hào)的合并。
2)不同類(lèi)型
用戶(hù)在一個(gè)產(chǎn)品中,用手機(jī)號(hào)和微信分別注冊(cè)了兩個(gè)賬號(hào),現(xiàn)在希望將其合并為一個(gè)賬號(hào),這是不同類(lèi)型賬號(hào)的合并。
賬號(hào)是否需要合并也是從業(yè)務(wù)場(chǎng)景出發(fā)考慮的,社交或工具類(lèi)產(chǎn)品,通常不會(huì)處理一人多賬號(hào)的情況;從保險(xiǎn)業(yè)務(wù)的角度考慮,因投保需實(shí)名認(rèn)證,當(dāng)賬號(hào)綁定了實(shí)名認(rèn)證后的用戶(hù),再?gòu)亩鄠€(gè)賬號(hào)中向用戶(hù)提供投保后的保全、理賠等服務(wù)會(huì)比較麻煩。
賬號(hào)數(shù)據(jù)的打通,用戶(hù)的數(shù)據(jù)在產(chǎn)品間流轉(zhuǎn),總量不變;而賬號(hào)數(shù)據(jù)的合并,就會(huì)產(chǎn)生用戶(hù)數(shù)據(jù)總量的變化。
在賬號(hào)數(shù)據(jù)合并后,用戶(hù)所有的新數(shù)據(jù)會(huì)在新賬號(hào)下產(chǎn)生,那賬號(hào)數(shù)據(jù)合并之前,對(duì)于多個(gè)賬號(hào)中歷史數(shù)據(jù)的處理,我們應(yīng)該怎么操作呢?
三、歷史數(shù)據(jù)的處理
歷史數(shù)據(jù)的合并,并不是簡(jiǎn)單的1+1=2,對(duì)于不同類(lèi)型的數(shù)據(jù),需要進(jìn)行不同的操作。
總的來(lái)說(shuō),用戶(hù)數(shù)據(jù)分為兩類(lèi):唯一類(lèi)和非唯一類(lèi),這兩類(lèi)數(shù)據(jù)的處理邏輯也有所不同,舉幾個(gè)例子簡(jiǎn)單說(shuō)下~
1. 用戶(hù)名
用戶(hù)有A、B兩個(gè)賬號(hào),兩個(gè)賬號(hào)的用戶(hù)名分別是王小二(A)、王達(dá)爾(B),用戶(hù)在登錄王小二(A)的狀態(tài)下發(fā)起賬號(hào)合并;常規(guī)邏輯,一位用戶(hù)不會(huì)有兩個(gè)用戶(hù)名的。
如果合并數(shù)據(jù)時(shí)只是簡(jiǎn)單的相加,用戶(hù)自己都不知道自己的名字應(yīng)該是什么了。
那么用戶(hù)名應(yīng)該用哪一個(gè)呢?在數(shù)據(jù)合并的時(shí)候,應(yīng)該指定想要保留的數(shù)據(jù),覆蓋掉其余數(shù)據(jù)。
2. 瀏覽記錄
用戶(hù)在A、B兩個(gè)賬號(hào)下都瀏覽過(guò)產(chǎn)品,生成了對(duì)應(yīng)的瀏覽記錄。兩個(gè)賬號(hào)瀏覽的產(chǎn)品有重復(fù),現(xiàn)對(duì)兩個(gè)賬號(hào)發(fā)起合并申請(qǐng)。
如果只是簡(jiǎn)單的數(shù)據(jù)相加,那瀏覽記錄中就會(huì)有數(shù)據(jù)冗余,導(dǎo)致統(tǒng)計(jì)出錯(cuò)。
那應(yīng)該怎么處理呢?將所有待合并賬號(hào)的數(shù)據(jù)累計(jì)起來(lái),同時(shí)為了避免重復(fù),需去重。
3. 會(huì)員等級(jí)
用戶(hù)在A、B兩個(gè)賬號(hào)下都有對(duì)應(yīng)的會(huì)員等級(jí),兩個(gè)賬號(hào)的會(huì)員等級(jí)分別是“1級(jí)”和“3級(jí)”,現(xiàn)對(duì)兩個(gè)賬號(hào)發(fā)起合并申請(qǐng)。
會(huì)員等級(jí)是唯一的,和用戶(hù)名一樣不可以簡(jiǎn)單相加。
用戶(hù)到底是1級(jí)、3級(jí)還是將對(duì)應(yīng)等級(jí)換算成分?jǐn)?shù)后再次相加計(jì)算出的新等級(jí)?可根據(jù)具體業(yè)務(wù)場(chǎng)景做取舍。
4.?聊天記錄
用戶(hù)在A、B兩個(gè)賬號(hào)下都有對(duì)應(yīng)的聊天記錄,現(xiàn)對(duì)兩個(gè)賬號(hào)發(fā)起合并申請(qǐng)。
聊天記錄除用戶(hù)主觀操作刪除外,一般不可刪除。那么在賬號(hào)合并時(shí),就要完整保存歷史數(shù)據(jù),避免丟失。
怎么保存呢?一般使用累計(jì)方式進(jìn)行數(shù)據(jù)合并。
本文由@404查無(wú)此人 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash, 基于CC0協(xié)議。
我怎么看前面的老大哥和弟弟就看暈了
如果有交易記錄呢?
有些啟發(fā),贊一個(gè)~
如果不同主體呢