賬戶體系是任意一款互聯(lián)網(wǎng)產(chǎn)品都必有的基礎(chǔ)體系，而賬戶體系的產(chǎn)品設(shè)計文章卻寥寥無幾。本文小編將從互聯(lián)保險產(chǎn)品的賬戶體系入手，來聊一聊如何基于復(fù)雜業(yè)務(wù)場景構(gòu)建一套完整賬戶體系。

一、賬戶體系、賬號體系、用戶體系的區(qū)別與聯(lián)系   

在分享如何構(gòu)建賬戶體系之前，先聊一聊小編對「賬戶」「賬號」「用戶」三者之間關(guān)聯(lián)和區(qū)別的理解。

• 賬戶可以定義是一個具有特定信息含義的內(nèi)容集。比如一張身份證，一本銀行存折，一份個人信用資料等。

• 賬號則是一組特定符號組成的序列，且與賬戶有一一映射關(guān)系。比如身份證號，銀行卡號，個人征信代碼等。

• 用戶則是通過這組特定字符序列與內(nèi)容集產(chǎn)生關(guān)聯(lián)的個體，同時也是賬戶內(nèi)容所描述的特定個體。

在互聯(lián)網(wǎng)產(chǎn)品中，用戶體系往往是面向用戶，更偏重于用戶運營與增長。而賬戶體系則是面向業(yè)務(wù)，更偏重于產(chǎn)品結(jié)構(gòu)與業(yè)務(wù)支撐。賬號體系則是橋接在用戶體系與賬戶體系之間，為用戶體系提供價值體現(xiàn)的同時，又可為賬戶體系提供服務(wù)的支持。換言之，在偏重用戶體驗的產(chǎn)品中，賬戶體系的價值常常被忽略。而在偏重于業(yè)務(wù)效率與供需交易的產(chǎn)品中，賬戶體系的價值舉足輕重。

案例：信用卡

這里小編通過「信用卡」這個大家生活中都會接觸的產(chǎn)品來講講上述三者的區(qū)別和關(guān)聯(lián)。

對于一張信用卡來講，我們站在普通人的角度看，它的用戶自然是使用它的人。它的賬號自然是登錄或支付的賬號和密碼。而它的賬戶可能就是它的消費記錄，可用金額等。讀到這里大家可能覺得這個例子非常的簡單。

那么我們換一個思考的角度，站在產(chǎn)品經(jīng)理的立場看，對于一個信用卡產(chǎn)品來講，它的用戶體系，賬號體系，賬戶體系又分別是什么呢？

在小編看，信用卡的用戶體系就是它的用戶成長體系，可能是用戶積分體系，會員等級體系等這些可以提升用戶粘性，促進(jìn)用戶刷卡消費，提升業(yè)務(wù)量的產(chǎn)品運營模塊。而這部分模塊往往是直接面向用戶的，我們可以在各種信用卡產(chǎn)品中輕易找到。

信用卡的賬號體系就是信用卡的使用通道或者說產(chǎn)品觸達(dá)用戶的渠道。可以是線下直接刷卡消費，這時使用的賬號就是卡號和支付密碼。也可以線上產(chǎn)品端掃碼消費，或者第三方支付通道調(diào)起，這時必然要通過產(chǎn)品端的登錄賬號和密碼以及付款賬號和密碼等。這些不同的用途的賬號和密碼共同組建了一個復(fù)雜的賬號體系。

賬戶體系就更加復(fù)雜了，包括普通用戶可以看到的個人基本信息，個人認(rèn)證信息，信貸賬戶，分期賬戶，分期賬戶，余額賬戶，借貸賬戶，消費記錄，貸款記錄，還款記錄等。以及普通用戶看不到的銀行信用評級記錄，逾期記錄，卡片升級記錄，異常消費記錄等等。由此也可以看出賬戶體系更多是面向業(yè)務(wù)的，根據(jù)業(yè)務(wù)不同，賬戶體系的設(shè)計偏重也不同。

那么下面小編將通過互聯(lián)網(wǎng)保險產(chǎn)品的賬戶體系搭建方法論來聊一聊如何設(shè)計一個可以應(yīng)對復(fù)雜業(yè)務(wù)場景的賬戶體系。

二、搭建賬戶體系的第一步：用戶是誰，具有什么樣的特點？

在互聯(lián)網(wǎng)保險行業(yè)中，由于其業(yè)務(wù)場景的多元化，可以分為持牌保險企業(yè)，保險經(jīng)紀(jì)公司，理賠服務(wù)供應(yīng)商，代理人展業(yè)供應(yīng)商等多種產(chǎn)品形態(tài)。小編將通過復(fù)雜度適中的互保經(jīng)紀(jì)公司的產(chǎn)品為例來進(jìn)行分析。

用戶關(guān)系定位：

首先將保險產(chǎn)品的需求側(cè)用戶分為以下四類：

1、個人用戶：進(jìn)行投保和被保險的個人。

2、個人客戶：存在的被保險的個人。

3、企業(yè)用戶：進(jìn)行投保和被保險的企業(yè)。

4、企業(yè)客戶：進(jìn)行被保險的企業(yè)。

這里的用戶和客戶的區(qū)別在于：用戶是與產(chǎn)品產(chǎn)生直接行為的個體，而客戶是與產(chǎn)品產(chǎn)生間接行為的個體。間接行為就是該個體并未與本產(chǎn)品中產(chǎn)生直接交互行為，而是通過第三方代為完成的。比如企業(yè)為員工提供的補(bǔ)充醫(yī)療險，就是企業(yè)為員工集體購買的險種。當(dāng)產(chǎn)品本身為被保險人提供保全或理賠服務(wù)時，則需要為該被保險人進(jìn)行賬戶的創(chuàng)建和維護(hù)?？蛻襞c用戶的具體關(guān)聯(lián)邏輯將在第二步中進(jìn)行講解。

案例：個人賬戶體系

當(dāng)確定了用戶是誰后，在搭建賬戶體系時就要為用戶添加標(biāo)簽，創(chuàng)建賬戶規(guī)則及字段，以及不同類型的賬戶的下的屬性字段有哪些。企業(yè)用戶因涉及到供給側(cè)，需求側(cè)以及第三方服務(wù)角色，相對較為復(fù)雜，在此就不展開討論了。此處小編以個人用戶為例簡單說明一下。

個人用戶的賬戶信息大概可以分為以上七個信息模塊。其中基本信息和身份認(rèn)證信息這兩個模塊的用途是確定用戶的真實性和唯一性。保險行業(yè)相對于其他行業(yè)，在進(jìn)行投保核保時是需要進(jìn)行個人身份的認(rèn)證。因而保險產(chǎn)品更容易獲取用戶的真實信息，用于保險風(fēng)控及用戶運營。

這里可能有讀者朋友會問：為什么將基本信息和身份認(rèn)證信息歸并在個人賬戶體系中，而不是放在用戶體系或者賬號體系中。這里小編解釋一下自己的考慮。首先沒有歸并到用戶體系的原因很簡單，用戶體系的作用是為了促進(jìn)用戶與產(chǎn)品的粘性，進(jìn)而促進(jìn)業(yè)務(wù)增長。而個人基本信息和身份認(rèn)證信息的歸并并不能起到這方面的作用。而在較為復(fù)雜或繁瑣的產(chǎn)品中，可能會存在多賬號的情況，此時如果將基本信息和認(rèn)證信息放入賬號體系中，可能會帶來數(shù)據(jù)不同步或數(shù)據(jù)冗余的問題。

保險信息和所屬企業(yè)的用途是確定個人是用戶還是客戶以及該個人與保單之間的關(guān)聯(lián)關(guān)系。因為一個人可以關(guān)聯(lián)多張保單。

• 如該個人在某一保單中是連帶被保險人，那么該人對于該保單/該保險產(chǎn)品而言就是客戶，因為Ta無法與產(chǎn)品發(fā)生直接交互行為，而是需要主保險人代為進(jìn)行保全或理賠的行為交互。

• 如該個人在某一保單中是主被保險人，但該保單的理賠收單方式是以企業(yè)為單位收單理賠。那么該個人對于該保單/該保險產(chǎn)品而言仍是客戶，因為TA沒有與產(chǎn)品發(fā)生直接交互行為。

• 如該個人在某一保單中是主被保險人，且他可以直接在產(chǎn)品中提起保全或理賠的申請，那么該個人對于該保單/該保險產(chǎn)品是用戶。

支付信息的用途是在用戶與產(chǎn)品產(chǎn)生理賠行為時所需要處理的業(yè)務(wù)信息模塊。這其中較為重要的是額度賬戶模塊，將在第二步重點說明。而登錄賬號模塊作為各種產(chǎn)品的基礎(chǔ)支撐模塊，將在第三步中重點討論一下。運營信息模塊屬于用戶體系部分，本文不做擴(kuò)展。

三、搭建賬戶體系的第二步：業(yè)務(wù)是什么，具有什么樣的區(qū)別？

如果第一步是確定賬戶的標(biāo)準(zhǔn)化屬性，那么這一步則是確定賬戶的業(yè)務(wù)化屬性。因為小編討論的是保險產(chǎn)品的賬戶體系，那么該賬戶體系主要圍繞的就是險種責(zé)任和險種額度。即交易業(yè)務(wù)的規(guī)則和金額。

投保方案中的每條險種責(zé)任對應(yīng)的險種額度都是不同的，被保險人的理賠訴求與險種責(zé)任是一一對應(yīng)的。

在互聯(lián)網(wǎng)保險中，業(yè)務(wù)主要可以分為兩個思考方向：

1、提供什么服務(wù)？比如投保，保全，理賠。

2、支持什么險種？比如健康險，財險，車險，壽險等。

這里我們就通過支持補(bǔ)充醫(yī)療險的保全和理賠的團(tuán)體保單業(yè)務(wù)為例子來簡單分析一下。

補(bǔ)充醫(yī)療保險是相對于基本醫(yī)療保險而言的，包括企業(yè)補(bǔ)充醫(yī)療保險、商業(yè)醫(yī)療保險、社會互助和社區(qū)醫(yī)療保險等多種形式，是基本醫(yī)療保險的有力補(bǔ)充，也是多層次醫(yī)療保障體系的重要組成部分。

從業(yè)務(wù)種類來進(jìn)行保險賬戶體系的分析與構(gòu)建：

保險的業(yè)務(wù)種類可以直接理解為保險的險種區(qū)分及具體理賠或保全規(guī)則。因為討論的是補(bǔ)充醫(yī)療保險的保全和理賠業(yè)務(wù)，所以第一個屬性就是賬戶業(yè)務(wù)類型，基本醫(yī)療保險或補(bǔ)充醫(yī)療保險。第二個重要的屬性則是保險項目性質(zhì)，這類企業(yè)的補(bǔ)充醫(yī)療保險項目會分為風(fēng)險型和基金型。所謂風(fēng)險型保險項目是以一個特定時間段為標(biāo)準(zhǔn)（大多是一年一期），到期續(xù)保后重置保險額度，不進(jìn)行保額累加的操作。而基金型保險項目則可以在到期續(xù)保后進(jìn)行險種額度的累加。因而需要在賬戶中區(qū)分保單性質(zhì)是基金型還是風(fēng)險型。還有一類重要的維度就是保險期間，也就是險種額度有效期。例如去年的理賠申請僅能使用去年的險種額度而不能使用今年的險種額度。當(dāng)然還有很多其他的規(guī)則，比如共享額度，即多個險種共用一個額度。企業(yè)公共額度，即在某些特殊病中對個人補(bǔ)充醫(yī)療賬戶的額外的額度補(bǔ)充。

根據(jù)上述描述，我可以將額度賬戶切分為四層結(jié)構(gòu)，即項目層，保單層，責(zé)任層，額度層。額度有效期則是從保單層到責(zé)任層再到額度層皆有關(guān)聯(lián)。

從業(yè)務(wù)流程來進(jìn)行保險賬戶體系的分析與構(gòu)建：

保險的業(yè)務(wù)流程在這里可以理解為理賠流程和保全流程，當(dāng)被保險人申請理賠服務(wù)后，在完成的收單，錄單，理算及復(fù)核后，會相應(yīng)的扣除被保險人的對應(yīng)的險種額度。這其中就會涉及到賬戶額度的變動。根據(jù)業(yè)務(wù)流程不同，會延伸出額度加費流程，額度凍結(jié)流程，賬務(wù)清結(jié)算流程等。因此在額度層就需要記錄該賬戶的總額度，可用額度，凍結(jié)額度，剩余可用額度，初始額度，累計使用額度，累計加費額度。因而就能得到如下圖所示的額度賬戶的結(jié)構(gòu)樣例。

搭建賬戶體系的第三步：賬號有哪些，會遇到什么問題？

讀到這里，可能會有讀者有疑惑，開篇時小編不是將賬號體系和賬戶體系分開來了嗎，為什么賬戶體系中要考慮賬號呢？因為賬戶體系是一個內(nèi)容集，我們需要一把鑰匙去打開這個內(nèi)容集，而賬號就是觸達(dá)賬戶體系的鑰匙。但是這把鑰匙如何設(shè)計也是需要考量的。

有些讀者可能在設(shè)計賬戶體系或者初期構(gòu)建一個C端產(chǎn)品時，會優(yōu)先搭建賬號體系，再根據(jù)業(yè)務(wù)發(fā)展逐步的完善賬戶體系和用戶體系。這種產(chǎn)品設(shè)計思路在某些流量為王，偏重用戶體驗的C端產(chǎn)品中是一種還不錯的產(chǎn)品設(shè)計思路。但是在一些具有復(fù)雜業(yè)務(wù)場景的行業(yè)或產(chǎn)品中可能并不是一個好的設(shè)計思路，比如互聯(lián)網(wǎng)金融，互聯(lián)網(wǎng)保險或者偏重供需交易業(yè)務(wù)的互聯(lián)網(wǎng)+傳統(tǒng)行業(yè)。為什么這樣講呢？且看小編一一為你解答。

1、互聯(lián)網(wǎng)產(chǎn)品的賬號類型和適應(yīng)場景：

首先我們先來看看產(chǎn)品賬號共有哪些類型，每一種類型的前世今生是怎么樣的。

（1）.自定義賬號類型：

自定義賬號起源于PC時代，用戶可以根據(jù)喜好設(shè)定一組字符為賬號，沒有特定的組合格式。其缺點除了顯而易見的因無特定生成規(guī)則而不容易記憶外，還無法關(guān)聯(lián)到某一可以認(rèn)證號主身份的識別信息，丟失后不易直接找回。

（2）.郵箱賬號類型：

與自定義賬號一樣起源于PC時代，在自定義賬號興起之后，為了解決其易忘，難維護(hù)，難找回的問題。同時使用郵箱也逐步進(jìn)入中國網(wǎng)民生活中。各大廠開始紛紛使用郵箱作為PC端最常見的登錄賬號形態(tài)。其優(yōu)點較自定義賬號除了降低了維護(hù)成本，提高了用戶找回賬號的便捷性外。也為對流失用戶的召回和激活，賬號安全性，產(chǎn)品業(yè)務(wù)推廣的提升都起到的至關(guān)重要的作用。

（3）.手機(jī)號碼賬號類型：

當(dāng)移動時代的到來后，由于中國大多數(shù)網(wǎng)民的手機(jī)號普及度遠(yuǎn)高于郵箱普及度，且國內(nèi)網(wǎng)民的并未養(yǎng)成如國外網(wǎng)民一樣的郵件使用習(xí)慣。手機(jī)號碼作為賬號載體受到了絕大多數(shù)移動產(chǎn)品的認(rèn)可。其較郵箱有更高效便民的登錄方式，僅需通過驗證碼即可登錄，不需在消耗腦力成本記錄密碼。尤其當(dāng)三大運營商對全網(wǎng)手機(jī)號實現(xiàn)身份認(rèn)證后，其對賬號安全性的提高是郵箱賬號所無法比擬的?，F(xiàn)在更有本機(jī)手機(jī)號一鍵登錄的功能，更極大提高用戶體驗。

（4）.三方授權(quán)賬號類型：

隨著幾大國民現(xiàn)象級的APP產(chǎn)品出現(xiàn)，其為搶占各垂直賽道和樹立用戶心智，衍生出第三方授權(quán)登錄的概念。僅需要移動產(chǎn)品開啟第三方登錄接口，用戶注冊/登錄時授權(quán)第三方，即可通過第三方賬號登錄產(chǎn)品。其優(yōu)點使用戶可以跳過較為繁瑣的手機(jī)號注冊登錄流程，一鍵式完成注冊/登錄，并可將基本信息直接帶入產(chǎn)品中。其缺點也十分明顯，用戶是方便了，但是作為產(chǎn)品本身，無法獲得用戶真實有效的身份信息。無法對用戶進(jìn)行安全驗證，用戶召回激活，用戶常規(guī)運營等行為。

（5）.特定賬號類型：

最后這一種可能在普通產(chǎn)品中并不常見，但是在某些B端產(chǎn)品或與個人敏感信息相關(guān)的產(chǎn)品中頗為常見，比如銀行類產(chǎn)品的賬號為身份證號，銀行卡號?；蛘呱绫．a(chǎn)品，某些教學(xué)平臺，OA系統(tǒng)等辦公軟件。該類賬號大多并非主動注冊創(chuàng)建的，而是通過被動邀請或主動激活已存在的賬號產(chǎn)生。其場景皆是對產(chǎn)品及賬號信息的保密性和安全性要求較高。

2、同一產(chǎn)品的賬號合并與賬戶打通：

當(dāng)我們了解了幾種賬號類型后，可能遇到過在一個復(fù)雜業(yè)務(wù)產(chǎn)品的賬號體系可能包含以上多個甚至全部的類型。這種情況的出現(xiàn)可能是產(chǎn)品的歷史遺留問題造成的或者其本身業(yè)務(wù)形態(tài)決定的。而作為產(chǎn)品經(jīng)理此時要思考的問題是：是否應(yīng)該合并這些賬號數(shù)據(jù)？這就涉及到了一個非常關(guān)鍵的字段：用戶唯一標(biāo)識。

• 用戶唯一標(biāo)識（UID）：用戶在產(chǎn)品中完成賬號注冊后，自動生成一組特定規(guī)則字符組，作為用戶賬號在產(chǎn)品中的唯一識別標(biāo)識，不可修改，不可重復(fù)，不對用戶開放。

合并賬號數(shù)據(jù)其實就是在同一個業(yè)務(wù)體系或系統(tǒng)下，將同一個用戶的不同賬號進(jìn)行數(shù)據(jù)合并。而賬號的合并的本質(zhì)區(qū)別就在于：是否將同一用戶的不同賬號的UID進(jìn)行合并，保持用戶在系統(tǒng)中的唯一性。

這里需要產(chǎn)品人衡量與思考的點在于：

• 不合并或合并，對于業(yè)務(wù)價值的影響是什么？對于用戶價值的影響是什么？

（1）.多賬號合并：

場景：用戶A在同一產(chǎn)品的同一業(yè)務(wù)系統(tǒng)中有兩個相互獨立的登錄賬號，類型相同。

分析思路：這種場景較為常見，比如一個人擁有多個微信號碼，QQ號，微博號等。大多數(shù)社交類產(chǎn)品是不處理這種一人多賬號的情況。那么什么業(yè)務(wù)場景中會對這類同一用戶多賬號進(jìn)行處理合并呢，小編在保險產(chǎn)品中就遇到過這類情況。其處理原因是因為互保產(chǎn)品中，用戶作為被保險人會進(jìn)行實名認(rèn)證，當(dāng)被實名認(rèn)證后，如存在多賬號的情況，將較難對其進(jìn)行保全及理賠的服務(wù)維護(hù)。多賬號的情況會造成保單信息不同步或保險數(shù)據(jù)冗余。換言之，當(dāng)在同一產(chǎn)品的同一業(yè)務(wù)中，同一用戶存在多個賬號的情況時，如對該業(yè)務(wù)數(shù)據(jù)造成較大影響時，需要對賬號數(shù)據(jù)進(jìn)行合并處理。此時多賬號的合并處理又分為兩種：

1）、當(dāng)需要被合并的賬號類型相同，如類型都是手機(jī)號碼時，其常見的處理手段為選擇其中一個手機(jī)號碼為賬號名，其他手機(jī)號碼注銷，并將其對應(yīng)的賬戶數(shù)據(jù)合并同步。

2）、當(dāng)需要被合并的賬號類型不同，如類型一個是手機(jī)號碼，一個是郵箱號碼時，其常見的處理手段為選擇其中一個類型為賬號主體，其他類型保存，可作為展現(xiàn)數(shù)據(jù)，也可作為副賬號。并將其對應(yīng)的賬戶數(shù)據(jù)合并同步。

在工作中，除了同一產(chǎn)品中同一用戶的多賬號是否合并的問題，我們還可能遇見同一產(chǎn)品同一賬號的多賬戶是否打通的問題。

（2）.多賬戶打通：

場景：用戶A在同一產(chǎn)品的不同業(yè)務(wù)系統(tǒng)中共用一個登錄賬號，但業(yè)務(wù)的賬戶數(shù)據(jù)是相互獨立，不關(guān)聯(lián)同步。

分析思路：這種場景也較為常見，比如同一個微信可以在王者榮耀的iOS端和Android端各創(chuàng)建一個賬戶，登錄賬號通用，但對應(yīng)的賬戶數(shù)據(jù)相互獨立。那么什么業(yè)務(wù)場景中會對這類同一用戶同一賬號在多業(yè)務(wù)系統(tǒng)的賬戶數(shù)據(jù)進(jìn)行打通處理呢。

這種情況在具有供需交易類業(yè)務(wù)場景的產(chǎn)品中是較為場景的，比如保險產(chǎn)品，或者二手交易類產(chǎn)品，交易代理人產(chǎn)品。普通C端用戶即可是需求方也可以是供給方，俗稱小B用戶。此時是否要將同一用戶在買方業(yè)務(wù)系統(tǒng)的數(shù)據(jù)與賣方業(yè)務(wù)系統(tǒng)的數(shù)據(jù)打通，在于其相互是否有業(yè)務(wù)交集或連帶的價值體現(xiàn)。

所謂打通賬戶數(shù)據(jù)就是將同一個用戶同一賬號的在不同業(yè)務(wù)系統(tǒng)的賬戶數(shù)據(jù)進(jìn)行部分關(guān)聯(lián)和同步。 在具有復(fù)雜業(yè)務(wù)場景的產(chǎn)品中，我們想清以上可能會遇的問題及對應(yīng)解決方案后再進(jìn)行賬號體系的設(shè)計會更加的清晰和高效。

-END-