中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

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

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

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

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

在正式開始進行最佳實踐的探索之旅之前，不妨先簡單的了解一下如下幾個接口。

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

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

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

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

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

3. 小程序獲取用戶信息接口（針對訪問小程序的場景）

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

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

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

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 個接口，分別是微信針對微信內(nèi)瀏覽網(wǎng)頁、已經(jīng)關(guān)注公眾號的用戶、小程序和 App 提供的獲取當前用戶的微信相關(guān)信息和唯一標識的接口。

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

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

有的人可能會問，為什么我一個開發(fā)者要搞 4 個接口？因為一個開發(fā)者有多個公眾號，小程序和 App，在微信看來都屬于不同的「應(yīng)用」，微信會給每個「應(yīng)用」分配一個專屬的 Appid，不同的應(yīng)用類型，接口自然是不同的。

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

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

微信官方的解釋是這樣的：unionid 機制的作用說明：如果開發(fā)者擁有多個移動應(yīng)用、網(wǎng)站應(yīng)用和公眾帳號，可通過獲取用戶基本信息中的 unionid 來區(qū)分用戶的唯一性，因為同一用戶，對同一個微信開放平臺下的不同應(yīng)用（移動應(yīng)用、網(wǎng)站應(yīng)用和公眾帳號），unionid 是相同的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面三個核心機制就是做好公眾號登錄（微信網(wǎng)頁授權(quán)）的核心邏輯，請各位同學如果要實踐的話務(wù)必牢記。

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

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

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

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

那怎么辦？通過如下接口可以基于用戶的 openid 再把 unionid 拿回來。

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

理論上來說，這個接口能夠拿回來數(shù)據(jù)的，一定是因為用戶做了下面幾件事情：

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

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

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

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

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

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

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

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

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

結(jié)合微信提供的結(jié)果，把上面的目標翻譯過來，就是下面幾個核心要點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【openidA-unionid 為空-useridA】

【openidB-unionid 為空-useridB】

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

【openidA-unionidA-useridA】

【openidB-unionidA-useridB】

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

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

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

【openid（公眾號 A）-unionid-userid】

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

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

【openid（公眾號 A）-unionid-userid-appidA】

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

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

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

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

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

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

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

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

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

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

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

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

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

這么做的原因有三，一是因為這樣做也可以實現(xiàn)業(yè)務(wù)的需求。二是為了減少測試的成本，通過上方的完整流程圖就可以看出來其實上面的邏輯說這很簡單，其實麻煩得很，如果再區(qū)分是綁定場景還是登錄場景，測試起來會非常頭疼。三是因為，從底層抽象來看，所謂的「數(shù)據(jù)綁定」本質(zhì)是是利用用戶無法偽造的 openid 來做了一個身份識別，其實也是一種登錄，綁定就是登錄的一種。

接口的入?yún)⒅饕褪?openid，unionid，userid 三個要素，其中 userid 可以缺省，因為在「核心機制四」和「核心機制五」中提到的自動登錄的場景下。我們還拿不到用戶的 userid，其實是把 unionid 傳給服務(wù)端，服務(wù)端返回 userid。

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

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

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

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

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

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

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

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

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

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

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

上面說的都是交互層面的問題，在后端邏輯層面，App 完成可以被當成另一個小程序或者公眾號。

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

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

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

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

根據(jù)上面第二種方案的邏輯可以看出來，游客生單這件事情，其實在哪里都能做，大部分公司選擇在 App 做是因為 App 的 cookie 保存時間一般會比瀏覽器久一些，用戶不會沒事去把 App 的緩存給清掉，風險相對可控。

在討論完本次系統(tǒng)改進的主要方案之后，讓我們再回過頭來看看這次系統(tǒng)設(shè)計的目標，我認為主要是下面的幾個目標：

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

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

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

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

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

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

【涉及游客生單】

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

【不涉及游客生單】

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

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

為什么需要這么做呢？主要是為了滿足如下場景：

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

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

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

基于上面的討論，我們再次將流程圖做修正，就得到了如下的流程圖：

與上方的流程圖相比，唯一的區(qū)別在于判斷「userid 是否為空」的邏輯變成了「userid 是不是都是虛擬」，因為在游客生單的機制下，即使用戶不登錄，也可以獲得一個虛擬 userid。

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

后記

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

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

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

其實在正式開始寫這篇文章之后，才有時間沉下心來再次對邏輯抽象，想出了上文中的流程圖。

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

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

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

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

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

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

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

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

作者：戈弋；微信號：hentaigeyi

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

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