筆者從私域流量出發(fā)，論述了不同的業(yè)務(wù)和場(chǎng)景下如何處理微信私域相關(guān)的用戶數(shù)據(jù)，并分享了自己的操作建議。

最近私域流量的概念非?；?，所謂私域流量，就是你可以自由反復(fù)利用，無(wú)需付費(fèi)，又能隨時(shí)觸達(dá)，被沉淀在公眾號(hào)、微信群、個(gè)人微信號(hào)、頭條號(hào)、抖音等自媒體渠道的用戶。相對(duì)淘寶、京東、百度這些公域流量平臺(tái)，它屬于商家「私有資產(chǎn)」。

大家應(yīng)該都在微信內(nèi)用過(guò)小程序或者打開(kāi)過(guò)網(wǎng)頁(yè)，是不是經(jīng)常發(fā)現(xiàn)會(huì)彈個(gè)窗，要求授權(quán)，然后網(wǎng)頁(yè)上面就可以展示自己的微信頭像和昵稱了？這個(gè)其實(shí)就是微信通過(guò)接口給開(kāi)發(fā)者提供的識(shí)別用戶的能力。

做私域流量，就會(huì)不可避免地涉及到一個(gè)問(wèn)題，說(shuō)用戶進(jìn)入了自己的「私域」，但是我們真的能認(rèn)識(shí)用戶嗎？我們能成功地識(shí)別這個(gè)用戶，并且展示該給這個(gè)用戶展示的數(shù)據(jù)嗎？微信的 openid 和 unionid 機(jī)制其中的復(fù)雜內(nèi)容又有多少人知道呢？我們有很好地利用微信給我們提供的這些機(jī)制嗎？抖音到底是怎么利用這些接口拿到用戶的關(guān)系鏈的呢？

我在網(wǎng)絡(luò)上搜了很多相關(guān)的資料，有一些機(jī)制性質(zhì)的描述，但是非常完整的剖析這個(gè)事情，并且做詳細(xì)最佳實(shí)踐分享的文章比較少，而且大部分都是從接口角度去分析這個(gè)東西。正好最近接觸這塊內(nèi)容，就總結(jié)了一下，希望幫助后來(lái)的人少踩幾個(gè)坑。

在寫這篇稿子的時(shí)候，我也考慮到可能不同公司的階段不同，理論上功能開(kāi)發(fā)要求應(yīng)該不太一樣，所以這篇稿子會(huì)論述不同的業(yè)務(wù)和場(chǎng)景下如何處理微信私域相關(guān)的用戶數(shù)據(jù)，希望能拋磚引玉。

一、基礎(chǔ)概念知多少

對(duì)用戶做身份識(shí)別和權(quán)限限制，本質(zhì)上是一個(gè)用戶中心做的事情，計(jì)算機(jī)系統(tǒng)發(fā)展的歷史有很久了，古往今來(lái)，凡是涉及到用戶中心的系統(tǒng)，目的無(wú)外乎兩個(gè)：

一是「身份識(shí)別」，能夠準(zhǔn)確認(rèn)識(shí)這個(gè)用戶是誰(shuí)，不會(huì)出現(xiàn)來(lái)一個(gè)用戶，系統(tǒng)明明應(yīng)該認(rèn)識(shí) TA，但是完全不認(rèn)識(shí)，也不會(huì)認(rèn)錯(cuò)用戶，不會(huì)把這個(gè)用戶當(dāng)成別的人，也不會(huì)把別人當(dāng)成這個(gè)用戶，也不會(huì)允許有人冒充這個(gè)用戶。最好能夠?qū)崿F(xiàn)物理用戶與虛擬賬戶的一一對(duì)應(yīng)的關(guān)系。（在這里不考慮小號(hào)的情況）

二是「限權(quán)」，用戶相關(guān)的數(shù)據(jù)可以全部連帶展示，不會(huì)丟數(shù)據(jù)，也不會(huì)展示不該展示的數(shù)據(jù)，不會(huì)出現(xiàn)越權(quán)的現(xiàn)象。

好的用戶體系主要就是做兩個(gè)事情，身份識(shí)別和限權(quán)。所以下文所有的內(nèi)容，都是圍繞身份識(shí)別和限權(quán)這兩個(gè)底層需要去做的。所有系統(tǒng)做的迭代和改進(jìn)都只有一個(gè)目的——如何讓用戶身份識(shí)別的成本降到最低，如何讓系統(tǒng)限權(quán)做的最準(zhǔn)確。上面這段話是整個(gè)用戶中心設(shè)計(jì)的「核心思想」，如果想要打造一個(gè)靠譜的用戶中心，就務(wù)必牢記這些內(nèi)容。

在正式開(kāi)始進(jìn)行最佳實(shí)踐的探索之旅之前，不妨先簡(jiǎn)單的了解一下如下幾個(gè)接口。

1. 微信網(wǎng)頁(yè)授權(quán)（針對(duì)用戶在微信內(nèi)打開(kāi)對(duì)應(yīng)網(wǎng)頁(yè)）

https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140842

在用戶端的授權(quán)彈窗樣式如下圖所示：

2. 獲取用戶列表（針對(duì)已經(jīng)關(guān)注了公眾號(hào)的用戶）

https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140840

3. 小程序獲取用戶信息接口（針對(duì)訪問(wèn)小程序的場(chǎng)景）

https://developers.weixin.qq.com/miniprogram/dev/api/open-api/user-info/wx.getUserInfo.html

在用戶端的授權(quán)彈窗樣式如下圖所示：

4. 移動(dòng)應(yīng)用微信登錄接口（針對(duì)App內(nèi)利用第三方登錄訪問(wèn)微信的場(chǎng)景）

https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419317851&token=&lang=zh_CN

在用戶端的授權(quán)彈窗樣式如下圖所示：

上述 4 個(gè)接口，分別是微信針對(duì)微信內(nèi)瀏覽網(wǎng)頁(yè)、已經(jīng)關(guān)注公眾號(hào)的用戶、小程序和 App 提供的獲取當(dāng)前用戶的微信相關(guān)信息和唯一標(biāo)識(shí)的接口。

四個(gè)接口（除了第二個(gè)）的流程都會(huì)涉及用戶授權(quán)，用戶也可能會(huì)拒絕授權(quán)，微信的官方文檔經(jīng)常會(huì)說(shuō)一句屁話，就是開(kāi)發(fā)者需要妥善處理用戶拒絕的情況，但是從來(lái)沒(méi)說(shuō)過(guò)怎么妥善處理。

四個(gè)流程的用戶端的交互流程不太一樣（主要是授權(quán)彈窗的樣式和喚起環(huán)境不太一樣，我覺(jué)得各位應(yīng)該都見(jiàn)過(guò)），但是大體都是必須經(jīng)過(guò)用戶的授權(quán)（非靜默），開(kāi)發(fā)者才能拿到比較關(guān)鍵的信息，比如昵稱、頭像、unionid——一個(gè)非常重要的唯一標(biāo)識(shí)。

有的人可能會(huì)問(wèn)，為什么我一個(gè)開(kāi)發(fā)者要搞 4 個(gè)接口？因?yàn)橐粋€(gè)開(kāi)發(fā)者有多個(gè)公眾號(hào)，小程序和 App，在微信看來(lái)都屬于不同的「應(yīng)用」，微信會(huì)給每個(gè)「應(yīng)用」分配一個(gè)專屬的 Appid，不同的應(yīng)用類型，接口自然是不同的。

通過(guò)「微信網(wǎng)頁(yè)授權(quán)」接口文檔我們可以知道，微信會(huì)給我方系統(tǒng)返回如下參數(shù)：

基于文檔可以看到兩個(gè)和 id 有關(guān)的字段，一個(gè)叫 openid，一個(gè)叫 unionid，這兩個(gè) id 是什么概念呢？都是 id，有什么區(qū)別？

微信官方的解釋是這樣的：unionid 機(jī)制的作用說(shuō)明：如果開(kāi)發(fā)者擁有多個(gè)移動(dòng)應(yīng)用、網(wǎng)站應(yīng)用和公眾帳號(hào)，可通過(guò)獲取用戶基本信息中的 unionid 來(lái)區(qū)分用戶的唯一性，因?yàn)橥挥脩簦瑢?duì)同一個(gè)微信開(kāi)放平臺(tái)下的不同應(yīng)用（移動(dòng)應(yīng)用、網(wǎng)站應(yīng)用和公眾帳號(hào)），unionid 是相同的。

也就是說(shuō)，一個(gè)公司如果有一個(gè)小程序矩陣，同一個(gè)用戶使用了這 3 個(gè)小程序，開(kāi)發(fā)者能夠從微信的接口獲得到的數(shù)據(jù)一共有 3 條，3 條數(shù)據(jù)用戶的 openid 是不一致的，但是 unionid 是一致的，openid 和 unionid 都是用戶的唯一標(biāo)示，但是二者唯一性的生成條件是不一致的。

• openid 的唯一性=用戶微信號(hào)+應(yīng)用的 appid（不同的公眾號(hào)，小程序，appid 都是不同的）；
• unionid 的唯一性=用戶微信號(hào)+開(kāi)發(fā)者主體（一般是公司）。

值得一提的是，微信內(nèi)的網(wǎng)頁(yè)必須要掛靠一個(gè)公眾號(hào)，所以微信網(wǎng)頁(yè)授權(quán)獲得的 openid 和對(duì)應(yīng)掛靠公眾號(hào)粉絲的 openid 是一致的。開(kāi)發(fā)者可以選擇將所有的網(wǎng)頁(yè)都掛靠在一個(gè)公眾號(hào)下面，這樣可以減少授權(quán)彈窗的次數(shù)。

總的來(lái)說(shuō)，微信提供了很全面的生態(tài)系統(tǒng)，但是由于微信體系比較龐大，加上其設(shè)計(jì)理念比較保守，極端重視用戶隱私（甚至有些偏執(zhí)），會(huì)給開(kāi)發(fā)者帶來(lái)比較大的麻煩，所以想要正確地使用其實(shí)并不簡(jiǎn)單。

此外，在下方的具體內(nèi)容中，會(huì)涉及比較多的系統(tǒng)模塊的描述，如果讀者自己所在的公司還沒(méi)有實(shí)施類似于「微服務(wù)」的架構(gòu)，那么可能還需要對(duì)基礎(chǔ)設(shè)施進(jìn)行一些改造，但是核心思想也是可以套用的。

二、單Appid場(chǎng)景的微信賬戶體系建設(shè)

假設(shè)現(xiàn)在我們加入了一家初創(chuàng)公司，公司的業(yè)務(wù)非常簡(jiǎn)單，暫時(shí)不涉及到付費(fèi)業(yè)務(wù)，只有一個(gè)小型的社區(qū)，提供一些評(píng)論，點(diǎn)贊和收藏的功能。目前只開(kāi)通了一個(gè)公眾號(hào)，那我們應(yīng)該怎么設(shè)計(jì)針對(duì)微信的賬戶體系呢？我們?cè)撊绾螒?yīng)用 openid 和 unionid 呢？

基于上文提到的“用戶體系的核心思想”——既能夠?qū)崿F(xiàn)對(duì)于用戶身份的精確識(shí)別，以及能夠識(shí)別準(zhǔn)確地讀取該用戶對(duì)應(yīng)的數(shù)據(jù)，要做的事情就比較清晰了。一般在系統(tǒng)內(nèi)都會(huì)生成一個(gè) userid，用來(lái)作為用戶在系統(tǒng)內(nèi)的唯一標(biāo)示，同時(shí)業(yè)務(wù)方基于這個(gè)字段將用戶和業(yè)務(wù)數(shù)據(jù)關(guān)聯(lián)起來(lái)，實(shí)現(xiàn)限權(quán)。

在微信體系內(nèi)，unionid 這個(gè)字段是可以被認(rèn)定為識(shí)別用戶的核心key，所以需要把 userid 和 unionid 做一個(gè)關(guān)聯(lián)關(guān)系，總結(jié)下來(lái)，其實(shí)是要做如下幾件事：

1. 「快速精確身份識(shí)別」——要能夠快速的辨識(shí)用戶，用戶識(shí)別要準(zhǔn)確，不能出現(xiàn)把用戶識(shí)別錯(cuò)誤的情況，也不能出現(xiàn)明明應(yīng)該認(rèn)識(shí)但是卻不認(rèn)識(shí)的情況。交互層面，最好用戶操作成本超級(jí)低，點(diǎn)一下，甚至不點(diǎn)就能識(shí)別；
2. 「準(zhǔn)確限權(quán)」——用戶相關(guān)的數(shù)據(jù)可以全部連帶展示，不會(huì)丟數(shù)據(jù)，也不會(huì)展示不該展示的數(shù)據(jù)。

結(jié)合微信提供的接口能力，將上述目標(biāo)進(jìn)行翻譯，其實(shí)要做的事情是這樣的：

• 核心機(jī)制一，「將 unionid 和 userid 綁定實(shí)現(xiàn)限權(quán)」——把微信的unionid和自有系統(tǒng)的 userid 綁定起來(lái)，通常需要基于登錄行為實(shí)現(xiàn)；
• 核心機(jī)制二，「利用 openid 進(jìn)行快速身份識(shí)別」——由于微信內(nèi)網(wǎng)頁(yè)可以直接識(shí)別用戶的 openid，所以需要將 openid 和 unionid 做關(guān)聯(lián)，來(lái)實(shí)現(xiàn)一種“長(zhǎng)效并且精準(zhǔn)的 cookie”的效果，這樣用戶即使更換手機(jī)，只要不更改微信號(hào)，系統(tǒng)就永遠(yuǎn)能夠以最低成本直接對(duì)其進(jìn)行身份識(shí)別；
• 核心機(jī)制三，「交互層面處理用戶拒絕授權(quán)」——妥善處理用戶拒絕授權(quán)，所以拿不到 unionid 的情況。

雖然我很討厭微信這個(gè)“妥善處理”的說(shuō)辭，但是在這種情況下，我真的不知道該怎么總結(jié)這項(xiàng)工作。

核心機(jī)制一——「將unionid和userid綁定實(shí)現(xiàn)限權(quán)」的邏輯比較簡(jiǎn)單，用戶在微信內(nèi)訪問(wèn)系統(tǒng)的頁(yè)面，觸發(fā)了「微信網(wǎng)頁(yè)授權(quán)」的彈窗，用戶同意授權(quán)后，系統(tǒng)拿到了該用戶（該微信號(hào)）對(duì)應(yīng)的 unionid，然后把這個(gè) unionid 和系統(tǒng)本身的的 userid 關(guān)聯(lián)起來(lái)（比如先彈窗，然后要求用戶基于手機(jī)號(hào)和短信驗(yàn)證碼登錄，也可以做靜默注冊(cè)，看具體業(yè)務(wù)），然后系統(tǒng)就會(huì)有一個(gè)【unionid-userid】的數(shù)據(jù)，兩者一一對(duì)應(yīng)。

從此以后，用戶只要通過(guò)微信環(huán)境訪問(wèn)系統(tǒng)系統(tǒng)，就自動(dòng)種上數(shù)據(jù)庫(kù)已經(jīng)關(guān)聯(lián)的對(duì)應(yīng) userid 的 cookie，同時(shí)限制用戶在別的微信號(hào)環(huán)境內(nèi)再用這個(gè) userid 進(jìn)行登錄操作。（場(chǎng)景舉例：換個(gè)微信用相同的手機(jī)號(hào)嘗試登錄）

核心機(jī)制二——「利用 openid 進(jìn)行快速身份識(shí)別」實(shí)現(xiàn)起來(lái)也不復(fù)雜，「微信網(wǎng)頁(yè)授權(quán)」有一種機(jī)制叫做「snsapi_base 為 scope 發(fā)起的網(wǎng)頁(yè)授權(quán)」，可以獲取進(jìn)入頁(yè)面的用戶的 openid 的，并且是靜默授權(quán)。同時(shí)由于用戶已經(jīng)允許授權(quán)，所以系統(tǒng)拿到了【openid-unionid】的關(guān)聯(lián)關(guān)系，系統(tǒng)內(nèi)的數(shù)據(jù)就變成了【openid（公眾號(hào)A）-unionid-userid】結(jié)構(gòu)的數(shù)據(jù)。

借助數(shù)據(jù)庫(kù)里面的數(shù)據(jù)和「snsapi_base 為 scope 發(fā)起的網(wǎng)頁(yè)授權(quán)」的機(jī)制，這個(gè)用戶日后無(wú)論在天涯還是海角，只要在微信內(nèi)打開(kāi)網(wǎng)頁(yè)，系統(tǒng)都能認(rèn)識(shí)他。

核心機(jī)制三——「交互層面處理用戶拒絕授權(quán)」，這個(gè)事情要處理起來(lái)會(huì)比較玄學(xué)，比較常用的做法是設(shè)定一個(gè)攔截機(jī)制。一般來(lái)說(shuō)可以把強(qiáng)制要求授權(quán)彈窗的界面和強(qiáng)制要求登錄的流程做在一起的，畢竟這兩個(gè)性質(zhì)是很相似的，說(shuō)穿了就是兩種不同的身份識(shí)別形式。

哪些操作是必須是登錄用戶才能做的（比如下單購(gòu)買、收藏、點(diǎn)贊、評(píng)論），就在對(duì)應(yīng)的流程前面加上彈窗。微信網(wǎng)頁(yè)授權(quán)彈窗是可以反復(fù)觸發(fā)的，就和公司自己的開(kāi)發(fā)寫的原生登錄彈窗一樣，也可以在一進(jìn)入頁(yè)面的時(shí)候判斷數(shù)據(jù)庫(kù)內(nèi)有沒(méi)有對(duì)應(yīng)的數(shù)據(jù)記錄（openid 相同的數(shù)據(jù)），如果沒(méi)有就彈窗。

如何具體地設(shè)計(jì)這些機(jī)制，需要產(chǎn)品經(jīng)理根據(jù)自身業(yè)務(wù)和對(duì)轉(zhuǎn)化率的敏感程度自行決定，如果老板覺(jué)得下單前攔截用戶要求登錄很蠢，也可以考慮去掉，但是這樣就需要設(shè)計(jì)「游客身份」的機(jī)制，這個(gè)在下文會(huì)有更加詳細(xì)的描述。

上面三個(gè)核心機(jī)制就是做好公眾號(hào)登錄（微信網(wǎng)頁(yè)授權(quán)）的核心邏輯，請(qǐng)各位同學(xué)如果要實(shí)踐的話務(wù)必牢記。

在數(shù)據(jù)存儲(chǔ)方面，其實(shí)可以選擇先存儲(chǔ) openid-unionid 的關(guān)聯(lián)信息，再根據(jù)用戶后續(xù)登錄的情況，存儲(chǔ) unionid-userid 的關(guān)聯(lián)信息，具體的邏輯順序會(huì)在下一小節(jié)的流程圖之中描述中展現(xiàn)。

當(dāng)然有同學(xué)會(huì)問(wèn)，為什么不可以通過(guò)「snsapi_base 為 scope 發(fā)起的網(wǎng)頁(yè)授權(quán)」直接獲取 openid，然后和 userid 關(guān)聯(lián)，為什么要因?yàn)楂@取不到 unionid 就做攔截呢？原因很簡(jiǎn)單，因?yàn)楣緯?huì)發(fā)展，遲早會(huì)做小程序，做更多地業(yè)務(wù)，到時(shí)候回過(guò)頭來(lái)再填這個(gè)坑，得不償失。

在拿不到 unionid 的情況下獲取到的 openid，只能作為前端用來(lái)給游客用戶種 cookie 的手段，可以落庫(kù)，給前端當(dāng) cookie 標(biāo)識(shí)位使，但是不要落庫(kù)到「用戶中心」的數(shù)據(jù)庫(kù)，否則后面填坑真的是火葬場(chǎng)，雖然會(huì)有兩個(gè)填坑的小技巧就在下面，但是有條件不這么做的同學(xué)請(qǐng)務(wù)必不要這么搞。

上面所有的設(shè)計(jì)都是理想情況，在現(xiàn)實(shí)生活中，我們還會(huì)遇到一些不理想的情況，比如程序員大哥忘記存 unionid 這個(gè)字段了。

那怎么辦？通過(guò)如下接口可以基于用戶的 openid 再把 unionid 拿回來(lái)。

接口地址：https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140839

理論上來(lái)說(shuō)，這個(gè)接口能夠拿回來(lái)數(shù)據(jù)的，一定是因?yàn)橛脩糇隽讼旅鎺准虑椋?/p>

1. 開(kāi)發(fā)者帳號(hào)下存在同主體的公眾號(hào)，并且該用戶已經(jīng)關(guān)注了該公眾號(hào)。
2. 開(kāi)發(fā)者帳號(hào)下存在同主體的公眾號(hào)或移動(dòng)應(yīng)用，并且該用戶已經(jīng)授權(quán)登錄過(guò)該公眾號(hào)或移動(dòng)應(yīng)用。

上面說(shuō)的授權(quán)登錄過(guò)該公眾號(hào)其實(shí)就是指「微信網(wǎng)頁(yè)授權(quán)」，這點(diǎn)要噴一下微信官方的文檔，一個(gè)行為搞兩個(gè)名詞，其實(shí)挺煩人的。那么如果用戶授權(quán)過(guò)同主體的小程序會(huì)是什么效果呢？官方文檔沒(méi)寫，我也不敢亂說(shuō)。

這個(gè)方法不是萬(wàn)能的，假如用戶已經(jīng)把公眾號(hào)取關(guān)了（備注：取關(guān)了再關(guān)注，openid 和 unionid 不變），系統(tǒng)就拿不回信息了，然后數(shù)據(jù)庫(kù)里面就會(huì)出現(xiàn)一堆 unionid 字段為空的數(shù)據(jù)，其實(shí)很蛋疼，所以說(shuō)系統(tǒng)搭建這個(gè)事情，有的時(shí)候是一步錯(cuò)步步錯(cuò)。但是往往是業(yè)務(wù)初期，產(chǎn)品經(jīng)理和開(kāi)發(fā)都不是很在意，給后面人會(huì)造成很大的困擾，我會(huì)對(duì)這個(gè)機(jī)制如此了解，相信各位讀者已經(jīng)知道我之前踩了多少坑。

如果用戶已經(jīng)取關(guān)，為了下次和用戶再次相遇時(shí)可以拿回?cái)?shù)據(jù)，就需要前端層面代碼在做授權(quán)彈窗是否要彈的判斷機(jī)制里面加上一條，該條 openid 對(duì)應(yīng)的用戶數(shù)據(jù)的 unionid 字段是否為空，如果為空，需要彈窗授權(quán)，拿回對(duì)應(yīng)的 unionid。

三、多Appid場(chǎng)景的微信賬戶體系建設(shè)

隨著公司業(yè)務(wù)發(fā)展，之前的公眾號(hào)做的不錯(cuò)，最近小程序風(fēng)口正勝，公司也希望做一些變現(xiàn)的工作。老板說(shuō)我們來(lái)做個(gè)小程序吧，然后再把咱們的電商給做起來(lái)，面對(duì)新的業(yè)務(wù)要求，用戶中心該做出什么樣的改進(jìn)和變化呢？

在這個(gè)情況下，我們肯定要先結(jié)構(gòu)目標(biāo)，如何在新增小程序的情況下做好系統(tǒng)的用戶體系呢？其實(shí)說(shuō)到底，還是要牢記設(shè)計(jì)用戶中心時(shí)的核心思想，抽象下來(lái)就是要實(shí)現(xiàn)下面幾個(gè)目標(biāo)：

1. 「快速精確身份識(shí)別」——要能夠快速的辨識(shí)用戶，用戶識(shí)別要準(zhǔn)確，不能出現(xiàn)把用戶識(shí)別錯(cuò)誤的情況，也不能出現(xiàn)明明應(yīng)該認(rèn)識(shí)但是卻不認(rèn)識(shí)的情況。交互層面，最好用戶操作成本超級(jí)低，點(diǎn)一下，甚至不點(diǎn)就能識(shí)別。
2. 「準(zhǔn)確限權(quán)」——用戶相關(guān)的數(shù)據(jù)可以全部連帶展示，不會(huì)丟數(shù)據(jù)，也不會(huì)展示不該展示的數(shù)據(jù)。
3. 「快速識(shí)別自動(dòng)綁定」——由于有兩個(gè)軟件環(huán)境（微信網(wǎng)頁(yè)和小程序），會(huì)涉及到兩個(gè)環(huán)境下的用戶數(shù)據(jù)的綁定與統(tǒng)一，由于會(huì)做電商，用戶會(huì)對(duì)“數(shù)據(jù)丟失”非常敏感，所以用戶數(shù)據(jù)的綁定就格外重要了。

上面三點(diǎn)，一、二兩點(diǎn)是固有的要求，第三點(diǎn)是涉及到了多Appid的情況之后新增的要求。

結(jié)合微信提供的結(jié)果，把上面的目標(biāo)翻譯過(guò)來(lái)，就是下面幾個(gè)核心要點(diǎn)：

• 核心機(jī)制一，「將 unionid 和 userid 綁定實(shí)現(xiàn)限權(quán)」——把微信的unionid和自有系統(tǒng)的userid綁定起來(lái)，通常需要基于登錄行為實(shí)現(xiàn)
• 核心機(jī)制二，「利用 openid 進(jìn)行快速身份識(shí)別」——由于微信網(wǎng)頁(yè)可以直接識(shí)別用戶的openid，所以需要將 openid 和 unionid 做關(guān)聯(lián)，來(lái)實(shí)現(xiàn)一種“長(zhǎng)效并且精準(zhǔn)的cookie”的效果。
• 核心機(jī)制三，「利用 openid 進(jìn)行快速身份識(shí)別」（小程序場(chǎng)景）——小程序也可以直接獲取用戶的openid，所以需要將 openid 和 unionid 做關(guān)聯(lián)，來(lái)實(shí)現(xiàn)一種“長(zhǎng)效并且精準(zhǔn)的 cookie”的效果。
• 核心機(jī)制四，「利用 unionid 與 userid 的綁定關(guān)系，實(shí)現(xiàn)快捷登錄」——從小程序內(nèi)獲得的 unionid 和在微信網(wǎng)頁(yè)內(nèi)獲得的 unionid 是一致的，所以二者其一如果在數(shù)據(jù)庫(kù)已經(jīng)建立了 unionid 和 userid 的關(guān)聯(lián)數(shù)據(jù)，另一方應(yīng)該可以借助數(shù)據(jù)庫(kù)內(nèi)的數(shù)據(jù)自動(dòng)建立聯(lián)系而不需要用戶在做任何類似于「手機(jī)號(hào)驗(yàn)證碼登錄」的身份識(shí)別操作。
• 核心機(jī)制五，「利用 unionid 與 userid 的綁定關(guān)系，實(shí)現(xiàn)靜默登錄」——在某些特定情況下，小程序可以不通過(guò)用戶授權(quán)直接獲取 unionid，所以應(yīng)該要借助這個(gè)機(jī)制，幫助用戶實(shí)現(xiàn)無(wú)需任何操作即可直接登錄的效果。
• 核心機(jī)制六，「交互層面處理用戶拒絕授權(quán)」——妥善處理用戶拒絕授權(quán)，所以拿不到 unionid 的情況。

「核心機(jī)制一」、「二」、「三」、「六」在上面一小節(jié)已經(jīng)詳細(xì)描述過(guò)就不多說(shuō)了，我們就來(lái)著重說(shuō)說(shuō)上面「核心機(jī)制四」的和「核心機(jī)制五」。

「核心機(jī)制四」和「核心機(jī)制五」的本質(zhì)是一樣的，本質(zhì)上都是如下的流程：

一定要說(shuō)的話，「核心機(jī)制四」和「核心機(jī)制五」的最大區(qū)別就在上述流程圖中的黃色區(qū)域部分。

在一般情況下，我們需要彈窗請(qǐng)求用戶的授權(quán)，才能從用戶處獲得openid和unionid的關(guān)聯(lián)關(guān)系，否則就只能得到openid這一數(shù)據(jù)。特殊情況下，小程序環(huán)境內(nèi)，可以通過(guò)接口直接獲得用戶的unionid和openid的關(guān)聯(lián)關(guān)系，具體的描述見(jiàn)文檔-unionid獲取途徑：

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/union-id.html

反過(guò)來(lái)說(shuō)，如果用戶是先在小程序做了登錄，再訪問(wèn)微信內(nèi)網(wǎng)頁(yè)，也要做上面流程圖內(nèi)的操作，這樣才可以最大成本的降低用戶十分識(shí)別的成本，畢竟很多用戶根本分不清小程序和微信內(nèi)網(wǎng)頁(yè)的區(qū)別是什么，在他們的認(rèn)知里面，這個(gè)服務(wù)都是同一個(gè)公司提供的，理論上就應(yīng)該可以自動(dòng)可用，數(shù)據(jù)不能丟。

說(shuō)完了「核心機(jī)制四」和「核心機(jī)制五」，我再回過(guò)頭來(lái)說(shuō)「核心機(jī)制一」，雖然存在了2條數(shù)據(jù)，但是其實(shí)事情沒(méi)有變復(fù)雜，只要自己不作死。

在上面的一個(gè)小節(jié)里面，我們是如此描述綁定的邏輯的：

用戶在微信內(nèi)訪問(wèn)系統(tǒng)的頁(yè)面，觸發(fā)了「微信網(wǎng)頁(yè)授權(quán)」的彈窗，用戶同意授權(quán)后，系統(tǒng)拿到了該用戶（該微信號(hào)）對(duì)應(yīng)的 unionid，然后把這個(gè) unionid 和系統(tǒng)本身的的 userid 關(guān)聯(lián)起來(lái)（比如先彈窗，然后要求用戶基于手機(jī)號(hào)和短信驗(yàn)證碼登錄，也可以做靜默注冊(cè)，看具體業(yè)務(wù)），然后我們就有一個(gè)【unionid-userid】的數(shù)據(jù)，兩者一一對(duì)應(yīng)。

從此以后，用戶只要通過(guò)微信環(huán)境訪問(wèn)系統(tǒng)系統(tǒng)，就自動(dòng)種上數(shù)據(jù)庫(kù)已經(jīng)關(guān)聯(lián)的對(duì)應(yīng) userid 的 cookie，同時(shí)限制用戶在別的微信號(hào)環(huán)境內(nèi)再用這個(gè) userid 進(jìn)行登錄操作。（場(chǎng)景舉例：換個(gè)微信用相同的手機(jī)號(hào)嘗試登錄）

其實(shí)這個(gè)邏輯核心做的事情是兩個(gè)，第一個(gè)是把【unionid-userid】的這個(gè)關(guān)聯(lián)關(guān)系數(shù)據(jù)存下來(lái)，二是做限制邏輯，保證二者是一一對(duì)應(yīng)的關(guān)系。

在加入了小程序之后，這個(gè)場(chǎng)景就產(chǎn)生了一些變化，因?yàn)?unionid-userid 這樣的數(shù)據(jù)會(huì)出現(xiàn)兩條，而且一定有先有后，所以后來(lái)的一條其實(shí)完全可以直接把先前一條的 userid 的數(shù)據(jù)填過(guò)來(lái)，就是上面流程圖所描述的邏輯。即使一條數(shù)據(jù)變兩條，事情本質(zhì)是沒(méi)有什么變化的。

這里面就要格外強(qiáng)調(diào)，上面一個(gè)小節(jié)曾經(jīng)提到過(guò)這樣一個(gè)觀點(diǎn)：

在拿不到 unionid 的情況下獲取到的 openid，只能作為前端用來(lái)給游客用戶種 cookie 的手段，可以落庫(kù)，給前端當(dāng) cookie 標(biāo)識(shí)位使，但是不要落庫(kù)到【用戶中心】的數(shù)據(jù)庫(kù)。

如果我們把 unionid 字段為空的數(shù)據(jù)落庫(kù)到了「用戶中心」的數(shù)據(jù)庫(kù)會(huì)造成什么問(wèn)題？不妨舉個(gè)例子來(lái)說(shuō)明。試下一下這樣的場(chǎng)景：一個(gè)用戶進(jìn)入小程序，拒絕授權(quán)但是登錄了手機(jī)號(hào) A，然后進(jìn)入微信網(wǎng)頁(yè)，也拒絕授權(quán)但是登錄了手機(jī)號(hào) B，我們就會(huì)有如下數(shù)據(jù)。

【openidA-unionid 為空-useridA】

【openidB-unionid 為空-useridB】

假如用戶再來(lái)訪問(wèn)，在兩個(gè)環(huán)境都允許授權(quán)了，會(huì)怎么樣呢？數(shù)據(jù)庫(kù)里面的數(shù)據(jù)就會(huì)被補(bǔ)全，變成如下的樣子。

【openidA-unionidA-useridA】

【openidB-unionidA-useridB】

問(wèn)題來(lái)了，如果這個(gè)時(shí)候公司又開(kāi)發(fā)了一個(gè)小程序，這個(gè)用戶過(guò)來(lái)訪問(wèn)，允許授權(quán)，系統(tǒng)拿到了 openidC 和 unionidA，那該把用戶關(guān)聯(lián)到哪個(gè) userid 上面呢？所以我們可以看出來(lái)，如果 unionid 字段為空的數(shù)據(jù)落入了【用戶中心】的數(shù)據(jù)是多么的麻煩，一旦牽扯到兩個(gè) appid 系統(tǒng)就立馬歇菜了，非常容易出差錯(cuò)，但是如果 unionid 是不允許為空的，那么其實(shí)系統(tǒng)的邏輯依舊比較簡(jiǎn)單，而且很干凈。

如果有人不信邪覺(jué)得可以通過(guò) appid 或者別的手段去關(guān)聯(lián)，不妨可以試試，在線上運(yùn)行一段時(shí)間，再去 mysql 里面跑數(shù)看看，百分百會(huì)遇到一個(gè)微信號(hào)關(guān)聯(lián)兩個(gè) userid 的情況，這種時(shí)候用戶再投訴「訂單丟失」的問(wèn)題，真的是跳進(jìn)黃河也洗不清。

除了邏輯層面的區(qū)別，和上面一小節(jié)里純粹公眾號(hào)場(chǎng)景處理的方式還有有一個(gè)比較大的區(qū)別，就是數(shù)據(jù)庫(kù)里面理論上會(huì)存在這樣的兩條數(shù)據(jù)：

【openid（公眾號(hào) A）-unionid-userid】

【openid（小程序 B）-unionid-userid】

我會(huì)建議把數(shù)據(jù)結(jié)構(gòu)改造成下面這樣的：

【openid（公眾號(hào) A）-unionid-userid-appidA】

【openid（小程序 B）-unionid-userid-appidB】

為什么要增加 appid 的字段呢？原因比較簡(jiǎn)單，一會(huì)要做什么消息通知之類的功能，很多時(shí)候會(huì)基于 appid 這個(gè)字段做檢索，加上去會(huì)很方便。

很多時(shí)候一部分沒(méi)什么經(jīng)驗(yàn)的開(kāi)發(fā)開(kāi)發(fā)會(huì)喜歡用數(shù)字枚舉值，比如公眾號(hào)是 1，小程序是 2，但是實(shí)際上公司業(yè)務(wù)發(fā)展之后可能會(huì)做 7，8 個(gè)小程序，枚舉值并不能很好地表達(dá)業(yè)務(wù)層面實(shí)質(zhì)性的含義，這是種有問(wèn)題的抽象方式，所以從一開(kāi)始就把 Appid 存入系統(tǒng)中會(huì)比較科學(xué)。

上面描述的邏輯其實(shí)已經(jīng)很復(fù)雜了，單純用文字描述不是很好懂，下面有一個(gè)流程圖，各位可以抄作業(yè)了。需要強(qiáng)調(diào)的是，我所在的公司業(yè)務(wù)場(chǎng)景比這個(gè)還要再?gòu)?fù)雜一些，這個(gè)流程圖里面的內(nèi)容是沒(méi)有在線上驗(yàn)證過(guò)的，所以這個(gè)流程圖是無(wú)法保證 100% 正確的。

單獨(dú)看流程圖的話，也并不是非常好懂，所以我在 6 處地方做了 tips，這 6 處的邏輯可能會(huì)有點(diǎn)繞，但是都是有非常明確地目的的，缺少其中的某一個(gè)步驟，會(huì)導(dǎo)致結(jié)果產(chǎn)生變動(dòng)。

【1】這個(gè)步驟做去重，主要是針對(duì)數(shù)據(jù)庫(kù)很可能已經(jīng)存在了一條一模一樣的數(shù)據(jù)的情況，假如用戶清除了 cookie，前端不認(rèn)識(shí)用戶，就會(huì)把已有的數(shù)據(jù)傳輸過(guò)來(lái)，如果不做去重，下方邏輯判斷會(huì)有問(wèn)題。

【2】這個(gè)情況如果完全按照上文的要求進(jìn)行開(kāi)發(fā)，理論上不會(huì)出現(xiàn)，但是由于開(kāi)發(fā)不規(guī)范很可能會(huì)導(dǎo)致類似情況出現(xiàn)，所以特意加上這樣的限制邏輯。

【3】為了防止用戶試圖在別的微信號(hào)再次登錄已經(jīng)綁定了微信號(hào)的手機(jī)號(hào)而設(shè)計(jì)的機(jī)制。

【4】再次去重的目的也比較簡(jiǎn)單，有可能先前數(shù)據(jù)庫(kù)里面有數(shù)據(jù)【openidA-unionidA-userid 為空】，然后接口傳過(guò)來(lái)【openidA-unionidA-useridA】，第一次去重是不會(huì)把這兩條數(shù)據(jù)當(dāng)做重復(fù)數(shù)據(jù)的，但是經(jīng)過(guò)上面的流程處理后，兩條數(shù)據(jù)都會(huì)變?yōu)椤緊penidA-unionidA-useridA】，所以需要做去重邏輯。

【5】將 alpha 寫入數(shù)據(jù)庫(kù)的時(shí)候，如果去重后還有數(shù)據(jù) read_time 為空，說(shuō)明這是全新的數(shù)據(jù)，需要直接 insert，典型場(chǎng)景是用戶第一次訪問(wèn)我方系統(tǒng)的服務(wù)。

【6】這一步就是將最終結(jié)果返回給前端的過(guò)程，很可能前端只給后端 openid 和 unionid，但是后端通過(guò)關(guān)聯(lián)邏輯把 userid 也返回給了前端，前端就可以把 cookie 給種上了。

上面這個(gè)流程，嚴(yán)格來(lái)說(shuō)不是一個(gè)常規(guī)的「登錄」流程，更像是一個(gè)「數(shù)據(jù)綁定」的流程，但是我建議所有涉及到微信用戶體系的接口，全部封死成一個(gè)接口，不要分成「綁定」和「登錄」兩個(gè)接口。

同時(shí)，所有涉及到常規(guī)登錄的地方（比如 App 的賬密登錄），如果前端可以取到 openid 和 unionid 的 value，都應(yīng)該再調(diào)用一遍上面這個(gè)流程的接口。

這么做的原因有三，一是因?yàn)檫@樣做也可以實(shí)現(xiàn)業(yè)務(wù)的需求。二是為了減少測(cè)試的成本，通過(guò)上方的完整流程圖就可以看出來(lái)其實(shí)上面的邏輯說(shuō)這很簡(jiǎn)單，其實(shí)麻煩得很，如果再區(qū)分是綁定場(chǎng)景還是登錄場(chǎng)景，測(cè)試起來(lái)會(huì)非常頭疼。三是因?yàn)椋瑥牡讓映橄髞?lái)看，所謂的「數(shù)據(jù)綁定」本質(zhì)是是利用用戶無(wú)法偽造的 openid 來(lái)做了一個(gè)身份識(shí)別，其實(shí)也是一種登錄，綁定就是登錄的一種。

接口的入?yún)⒅饕褪?openid，unionid，userid 三個(gè)要素，其中 userid 可以缺省，因?yàn)樵凇负诵臋C(jī)制四」和「核心機(jī)制五」中提到的自動(dòng)登錄的場(chǎng)景下。我們還拿不到用戶的 userid，其實(shí)是把 unionid 傳給服務(wù)端，服務(wù)端返回 userid。

四、涉及不登錄生單的微信賬戶體系建設(shè)

小程序上線了，用戶數(shù)量激增，公司拿到了一筆融資，老板有點(diǎn)膨脹，說(shuō)咱們做 App 吧。

恰好，這時(shí)競(jìng)爭(zhēng)對(duì)手的 App 也上線了，他們還支持一個(gè)非常吊的功能，就是游客身份也能直接生單購(gòu)買，不需要在生單前登錄，這時(shí)老板著急了，要求自家產(chǎn)品也要有一樣的功能。

首先，這是一個(gè)非常真實(shí)的背景，而且根據(jù)行業(yè)內(nèi)知名電商公司的實(shí)踐，有超過(guò) 40% 的訂單來(lái)源于游客生單，所以做的必要時(shí)有的，關(guān)鍵的點(diǎn)在于怎么做。在正式開(kāi)始討論方案之前，其實(shí)我們不妨再次再次回過(guò)頭來(lái)看一下「核心思想」。

用戶體系要做的事情是什么？對(duì)用戶進(jìn)行身份識(shí)別，以及在身份識(shí)別的基礎(chǔ)上進(jìn)行限權(quán)操作。那么行業(yè)內(nèi)常見(jiàn)的「游客生單購(gòu)買」設(shè)計(jì)是不是和這個(gè)體系本身是相悖的呢？這個(gè)設(shè)計(jì)是不是太「人格分裂」了？我認(rèn)為不是。

因?yàn)闊o(wú)論是哪家公司，就算它對(duì)「游客生單購(gòu)買」的支持做的再好，也仍然千方百計(jì)地在引導(dǎo)用戶登錄。本質(zhì)是是因?yàn)椤赣慰蜕鷨钨?gòu)買」這件事情其實(shí)是把 App 內(nèi)的 cookie 當(dāng)成了一種身份識(shí)別的唯一標(biāo)示，而我們都知道 cookie 這種東西其實(shí)是很容易就會(huì)被抹掉的，如果用戶用收集的垃圾清理功能清一下緩存，很可能就洗掉了，對(duì)應(yīng)到用戶端的感受就是找不到訂單，這其實(shí)是比較嚴(yán)重的。

需要注意的是，App 內(nèi)的微信授權(quán)和小程序/微信內(nèi)網(wǎng)頁(yè)的微信授權(quán)，在交互上有比較大的差別。

在小程序/微信內(nèi)網(wǎng)頁(yè)獲取 openid 時(shí)，可以通過(guò)類似于「snsapi_base 為 scope 發(fā)起的網(wǎng)頁(yè)授權(quán)」直接獲取 openid，不需要用戶做任何操作。

在獲取 unionid 時(shí)，也只是喚起微信環(huán)境內(nèi)自帶的控件（就是一個(gè)彈窗）向用戶申請(qǐng)要求授權(quán)，交互流程是很簡(jiǎn)單的，而且任何頁(yè)面或者任何按鈕都可以加上這個(gè)觸發(fā)，其實(shí)是非常方便的。

在 App 內(nèi)，想要獲得用戶的授權(quán)（這是唯一獲得 openid 和 unionid 的方式）需要喚醒微信的 App，然后用戶在微信內(nèi)授權(quán)后再返回開(kāi)發(fā)者的 App。這意味著這種喚醒操作不能像之前設(shè)計(jì)的時(shí)候那樣隨意地在任意節(jié)點(diǎn)插入，因?yàn)橹暗沫h(huán)境內(nèi)，發(fā)起授權(quán)不過(guò)是一個(gè)彈窗，阻斷性會(huì)比較小，而在 App 內(nèi)則會(huì)直接跳出 App，交互上的代價(jià)會(huì)比較大，頻繁彈出容易導(dǎo)致阻斷主流程，得不償失。

一般建議將微信賬戶的授權(quán)做在登錄界面處，引導(dǎo)用戶綁定。也有一些在微信生態(tài)內(nèi)玩的很溜的公司會(huì)選擇在「訂單列表」，「我的」等頁(yè)面引導(dǎo)用戶綁定，因?yàn)檫@些商家有很多用戶都是從微信導(dǎo)流過(guò)來(lái)的，用戶下載 App 之后第一反應(yīng)肯定是「我在微信里面下的單子跑哪里去了？」。這樣的設(shè)計(jì)可以很好地引導(dǎo)用戶。

上面說(shuō)的都是交互層面的問(wèn)題，在后端邏輯層面，App 完成可以被當(dāng)成另一個(gè)小程序或者公眾號(hào)。

說(shuō)完微信在 App 內(nèi)的授權(quán)，我們?cè)僬f(shuō)說(shuō)「游客生單購(gòu)買」是什么情況，游客生單購(gòu)買的技術(shù)方案一般有兩種。

第一種是基于業(yè)務(wù)進(jìn)行設(shè)計(jì)的「游客生單購(gòu)買」，簡(jiǎn)單地說(shuō)就是業(yè)務(wù)方的數(shù)據(jù)庫(kù)允許在特定情況下，userid 的字段為空。

第二種方案是基于用戶中心進(jìn)行設(shè)計(jì)的「游客生單購(gòu)買」，簡(jiǎn)單地說(shuō)就是把游客的 cookie 當(dāng)做身份的唯一標(biāo)示，比如說(shuō)利用 cookie 生成一個(gè) userid，傳送給后端，然后等用戶登錄之后，用戶中心再做替換，并且廣播給業(yè)務(wù)方。

無(wú)論是我自己所在的公司還是請(qǐng)教別的公司的產(chǎn)品經(jīng)理，一般都認(rèn)為第二種方案是更好地設(shè)計(jì)，擴(kuò)展性會(huì)比較強(qiáng)，業(yè)務(wù)線不需要關(guān)心這么復(fù)雜 userid 替換的邏輯，可以直接拿過(guò)來(lái)用，比較符合「小前臺(tái)，大中臺(tái)」的設(shè)計(jì)理念，耦合性比較低。

根據(jù)上面第二種方案的邏輯可以看出來(lái)，游客生單這件事情，其實(shí)在哪里都能做，大部分公司選擇在 App 做是因?yàn)?App 的 cookie 保存時(shí)間一般會(huì)比瀏覽器久一些，用戶不會(huì)沒(méi)事去把 App 的緩存給清掉，風(fēng)險(xiǎn)相對(duì)可控。

在討論完本次系統(tǒng)改進(jìn)的主要方案之后，讓我們?cè)倩剡^(guò)頭來(lái)看看這次系統(tǒng)設(shè)計(jì)的目標(biāo)，我認(rèn)為主要是下面的幾個(gè)目標(biāo)：

1. 「快速精確身份識(shí)別」——要能夠快速的辨識(shí)用戶，用戶識(shí)別要準(zhǔn)確，不能出現(xiàn)把用戶識(shí)別錯(cuò)誤的情況，也不能出現(xiàn)明明應(yīng)該認(rèn)識(shí)但是卻不認(rèn)識(shí)的情況。交互層面，最好用戶操作成本超級(jí)低，點(diǎn)一下，甚至不點(diǎn)就能識(shí)別。
2. 「準(zhǔn)確限權(quán)」——用戶相關(guān)的數(shù)據(jù)可以全部連帶展示，不會(huì)丟數(shù)據(jù)，也不會(huì)展示不該展示的數(shù)據(jù)。
3. 「快速識(shí)別自動(dòng)綁定」——由于有多個(gè)軟件環(huán)境（微信網(wǎng)頁(yè)、小程序、App等），會(huì)涉及到多個(gè)環(huán)境下的用戶數(shù)據(jù)的綁定與統(tǒng)一，由于會(huì)做電商，用戶會(huì)對(duì)“數(shù)據(jù)丟失”非常敏感，所以用戶數(shù)據(jù)的綁定就格外重要了。
4. 「產(chǎn)品導(dǎo)流后賬戶綁定相關(guān)的交互設(shè)計(jì)」——由于用戶會(huì)很大概率先用小程序，再下載 App，所以 App 在核心界面，可能需要引導(dǎo)用戶綁定微信賬戶，這樣才能同步數(shù)據(jù)。（比如用戶在小程序以游客身份下單，但是同意了微信網(wǎng)頁(yè)內(nèi)授權(quán)，來(lái)到 App 的訂單列表是看不到數(shù)據(jù)的，需要引導(dǎo)用戶綁定微信賬戶）
5. 「基于游客身份的自動(dòng)綁定」——用戶在多個(gè)微信環(huán)境以游客身份生單的關(guān)系關(guān)聯(lián)問(wèn)題，這時(shí)用戶盡管沒(méi)有登錄，但是基于微信的機(jī)制我們?nèi)匀荒軌虬阉暈橥粋€(gè)人，所以需要做對(duì)應(yīng)的措施。

上面五點(diǎn)，一、二、三點(diǎn)是上文提到的固有的要求，四、五兩點(diǎn)是基于新的業(yè)務(wù)場(chǎng)景提出來(lái)的新的要求。

結(jié)合微信提供的接口，把上面的要求翻譯成具體可執(zhí)行的措施，就是下面幾個(gè)核心要點(diǎn)：

• 核心機(jī)制一，「將 unionid 和 userid 綁定實(shí)現(xiàn)限權(quán)」——把微信的unionid和自有系統(tǒng)的userid綁定起來(lái)，通常需要基于登錄行為實(shí)現(xiàn)
• 核心機(jī)制二，「利用 openid 進(jìn)行快速身份識(shí)別」——由于微信網(wǎng)頁(yè)可以直接識(shí)別用戶的openid，所以需要將 openid 和 unionid 做關(guān)聯(lián)，來(lái)實(shí)現(xiàn)一種“長(zhǎng)效并且精準(zhǔn)的cookie”的效果。
• 核心機(jī)制三，「利用 openid 進(jìn)行快速身份識(shí)別」（小程序場(chǎng)景）——小程序也可以直接獲取用戶的openid，所以需要將 openid 和 unionid 做關(guān)聯(lián)，來(lái)實(shí)現(xiàn)一種“長(zhǎng)效并且精準(zhǔn)的 cookie”的效果。
• 核心機(jī)制四，「基于交互引導(dǎo)解決App內(nèi)數(shù)據(jù)同步問(wèn)題」在 App 內(nèi)基于微信授權(quán)的交互機(jī)制和用戶的行為軌跡，在關(guān)鍵頁(yè)面提示用戶「綁定微信賬戶」。
• 核心機(jī)制五，「利用 unionid 與 userid 的綁定關(guān)系，實(shí)現(xiàn)快捷登錄」——從小程序內(nèi)獲得的 unionid，在微信網(wǎng)頁(yè)內(nèi)獲得的 unionid 和 App 基于賬戶綁定獲得的 unionid 是一致的，所以三者其一如果在數(shù)據(jù)庫(kù)已經(jīng)建立了 unionid 和 userid 的關(guān)聯(lián)數(shù)據(jù)，剩余兩方應(yīng)該可以借助數(shù)據(jù)庫(kù)內(nèi)的數(shù)據(jù)自動(dòng)建立聯(lián)系而不需要用戶在做任何類似于「手機(jī)號(hào)驗(yàn)證碼登錄」的身份識(shí)別操作。這個(gè)關(guān)聯(lián)邏輯需要對(duì)游客身份生成的虛擬 userid 也同樣生效。
• 核心機(jī)制六，「利用 unionid 與 userid 的綁定關(guān)系，實(shí)現(xiàn)靜默登錄」——在某些特定情況下，小程序可以不通過(guò)用戶授權(quán)直接獲取 unionid，所以應(yīng)該要借助這個(gè)機(jī)制，幫助用戶實(shí)現(xiàn)無(wú)需任何操作即可直接登錄的效果。
• 核心機(jī)制七，「交互層面處理用戶拒絕授權(quán)」——妥善處理用戶拒絕授權(quán)，所以拿不到 unionid 的情況。
• 核心機(jī)制八，「用戶標(biāo)識(shí)變更后的廣播機(jī)制」——所有涉及 userid 之間替換的行為，必須廣播至所有業(yè)務(wù)線，不論是虛擬的 userid 被真實(shí)登錄的 userid 替換，還是虛擬的 userid 之間的替換。

其中「核心機(jī)制一」、「二」、「三」、「六」、「七」都是在上文討論過(guò)的，「核心機(jī)制四」在本小節(jié)的開(kāi)頭部分已經(jīng)討論過(guò)，我們就來(lái)說(shuō)一下「核心機(jī)制五」和「核心機(jī)制八」。

我們不妨來(lái)對(duì)比一下涉及游客生單和不涉及游客生單對(duì)于「核心機(jī)制五」的設(shè)計(jì)上的不同要求

【涉及游客生單】

從小程序內(nèi)獲得的 unionid，在微信網(wǎng)頁(yè)內(nèi)獲得的 unionid 和 App 基于賬戶綁定獲得的 unionid 是一致的，所以三者其一如果在數(shù)據(jù)庫(kù)已經(jīng)建立了 unionid 和 userid 的關(guān)聯(lián)數(shù)據(jù)，剩余兩方應(yīng)該可以借助數(shù)據(jù)庫(kù)內(nèi)的數(shù)據(jù)自動(dòng)建立聯(lián)系而不需要用戶在做任何類似于「手機(jī)號(hào)驗(yàn)證碼登錄」的身份識(shí)別操作。這個(gè)關(guān)聯(lián)邏輯需要對(duì)游客身份生成的虛擬 userid 也同樣生效。

【不涉及游客生單】

從小程序內(nèi)獲得的 unionid 和在微信網(wǎng)頁(yè)內(nèi)獲得的 unionid 是一致的，所以二者其一如果在數(shù)據(jù)庫(kù)已經(jīng)建立了 unionid 和 userid 的關(guān)聯(lián)數(shù)據(jù)，另一方應(yīng)該可以借助數(shù)據(jù)庫(kù)內(nèi)的數(shù)據(jù)自動(dòng)建立聯(lián)系而不需要用戶在做任何類似于「手機(jī)號(hào)驗(yàn)證碼登錄」的身份識(shí)別操作。

排除增加了 App 這個(gè)運(yùn)行環(huán)境之外，最大的不同點(diǎn)在于「這個(gè)關(guān)聯(lián)邏輯需要對(duì)游客身份生成的虛擬 userid 也同樣生效?！惯@句話。

為什么需要這么做呢？主要是為了滿足如下場(chǎng)景：

用戶在小程序同意了「用戶信息授權(quán)」，系統(tǒng)獲得了她的 openid 和 unionid，但是她緊接著以游客身份生單，并沒(méi)有登錄。

這個(gè)時(shí)候用戶又在微信內(nèi)網(wǎng)頁(yè)做了同樣的事情，這個(gè)時(shí)候系統(tǒng)如果不對(duì)她作為游客身份的 userid 做同步，那么她在兩個(gè)環(huán)境的 cookie 是不一樣的，生成的虛擬 userid 自然就不同，但是系統(tǒng)基于 unionid 應(yīng)該是能對(duì)用戶在不同的地方的數(shù)據(jù)做整合同步的。

可能有的人會(huì)說(shuō)，竭盡全力幫助用戶同步數(shù)據(jù)會(huì)不會(huì)讓用戶覺(jué)得「毛骨悚然」，我覺(jué)得這是無(wú)稽之談，我做過(guò)很多用戶訪談，很多人甚至分不清「小程序」和「微信內(nèi)網(wǎng)頁(yè)」之間的區(qū)別，在他們看來(lái)，數(shù)據(jù)就應(yīng)該是同步的，丟數(shù)據(jù)才會(huì)讓他們毛骨悚然。

基于上面的討論，我們?cè)俅螌⒘鞒虉D做修正，就得到了如下的流程圖：

與上方的流程圖相比，唯一的區(qū)別在于判斷「userid 是否為空」的邏輯變成了「userid 是不是都是虛擬」，因?yàn)樵谟慰蜕鷨蔚臋C(jī)制下，即使用戶不登錄，也可以獲得一個(gè)虛擬 userid。

在做 userid 的關(guān)聯(lián)補(bǔ)充的時(shí)候，如果系統(tǒng)能夠識(shí)別用戶身份（基于獲取到的 unionid），那么即使當(dāng)前 userid 是虛擬的，數(shù)據(jù)庫(kù)中早先用戶數(shù)據(jù)的 userid 也是虛擬的，也需要保持 userid-unionid 一一對(duì)應(yīng)的關(guān)系，將現(xiàn)在這個(gè)虛擬的 userid 替換成數(shù)據(jù)庫(kù)中更早的那一個(gè)，這樣用戶先前的數(shù)據(jù)就可以在這個(gè)環(huán)境被讀取出來(lái)，具體的應(yīng)用場(chǎng)景在上方已經(jīng)描述。但是假如其中有一個(gè) userid 是真實(shí)的，那么它應(yīng)該獲得最高的優(yōu)先級(jí)。

后記

至此，關(guān)于整個(gè)微信賬戶體系如何建設(shè)的論述就告一段落了。其實(shí)想要打造完整的用戶體系還有很多可以做的事情，比如除了微信，是否能支持 QQ 和微博的登錄，比如第三方社交賬戶是否支持解綁（一般大公司的用戶中心都做了這個(gè)功能），都是我們需要考慮的問(wèn)題，但是我覺(jué)得在前期只需要做好微信就夠了。

如果將微博和 QQ 的數(shù)據(jù)加入進(jìn)來(lái)，那么整體數(shù)據(jù)結(jié)構(gòu)就會(huì)呈現(xiàn)如下的分布：

而整體的產(chǎn)品結(jié)構(gòu)會(huì)呈現(xiàn)如下樣式：

其實(shí)在正式開(kāi)始寫這篇文章之后，才有時(shí)間沉下心來(lái)再次對(duì)邏輯抽象，想出了上文中的流程圖。

在那之前我給開(kāi)發(fā)看也好，自己檢查也好，思考的邏輯都是一個(gè)類似于二叉樹(shù)的邏輯。但是隨著業(yè)務(wù)復(fù)雜度的提高，二叉樹(shù)的邏輯很明顯只能用來(lái)做覆蓋性測(cè)試，不適合用來(lái)做開(kāi)發(fā)，這算是在這件事情過(guò)程中踩得一個(gè)不大不小的坑吧。

我覺(jué)得用戶體系這個(gè)東西發(fā)展了這么多年，看上去很簡(jiǎn)單，但是其實(shí)里面深究起來(lái)學(xué)問(wèn)也不少，但是總的來(lái)說(shuō)在實(shí)際工作的時(shí)候，還是要牢牢把握住底層的核心思想，好的用戶體系主要就是做兩個(gè)事情，身份識(shí)別和限權(quán)。所有的工作都應(yīng)該圍繞身份之別和限權(quán)這兩個(gè)底層需要去做的，其實(shí)我們所做的一切，萬(wàn)變不離其宗，就是如何讓用戶把身份識(shí)別的成本降到最低，如何讓系統(tǒng)限權(quán)做的最準(zhǔn)確。

不妨回想一下，以前的用戶體系還會(huì)區(qū)分「注冊(cè)」和「登錄」，現(xiàn)在基本上就是手機(jī)短信驗(yàn)證碼登錄，沒(méi)注冊(cè)默認(rèn)注冊(cè)，這個(gè)變化其實(shí)就是上面所提到的核心思想的一個(gè)實(shí)踐方案，而且經(jīng)過(guò)業(yè)界各個(gè)大廠的實(shí)踐，基本上可以認(rèn)為是一種最佳實(shí)踐方案了。

從個(gè)人角度來(lái)看，微信這個(gè) openid 和 unionid 的機(jī)制非常的蛋疼，微信自己也作出過(guò)不少次改進(jìn)，但是我覺(jué)得這仍然是一件非常麻煩的事情。從微信官方的角度來(lái)看，他們或許還是出于保護(hù)用戶隱私不被濫用的角度在做這件事情，而作為開(kāi)發(fā)者也只有適應(yīng)的份，畢竟這個(gè)機(jī)制已經(jīng)在這邊了，沒(méi)啥好說(shuō)的。

上面文章內(nèi)的很多想法，大部分我都實(shí)踐過(guò)，效果是符合預(yù)期的，但是由于客觀條件的限制，有一些想法并沒(méi)有在生產(chǎn)環(huán)境得到過(guò)驗(yàn)證，并不能保證 100% 正確，況且不同的業(yè)務(wù)場(chǎng)景，對(duì)于同一件事情會(huì)衍生出不同的實(shí)踐方案，比如本文會(huì)強(qiáng)調(diào)盡量做到【userid-unionid】一一對(duì)應(yīng)，在實(shí)踐中有一些公司是允許一個(gè) userid 對(duì)應(yīng)多個(gè) unionid 的，其實(shí)仔細(xì)想一下，好像也沒(méi)什么大毛病。

感謝如下的小伙伴給本文提供的支持

• 十一貝科技-前端工程師-周航
• 某待業(yè)的前端工程師-權(quán)金鐸
• 十一貝科技-資深 java 工程師-李銳
• 廚芯科技-產(chǎn)品經(jīng)理-邵琨容
• 虎嗅-編輯-小田一成

文章內(nèi)的流程圖都是使用的 OmniGraffle 和 Xmind 繪制而成，如果有需要源文件或者有一些別的想法，歡迎添加我的微信做進(jìn)一步交流。

作者：戈弋；微信號(hào)：hentaigeyi

本文由 @戈弋 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。