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

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

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

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

• 賬戶可以定義是一個具有特定信息含義的內(nèi)容集。比如一張身份證，一本銀行存折，一份個人信用資料等。
• 賬號則是一組特定符號組成的序列，且與賬戶有一一映射關系。比如身份證號，銀行卡號，個人征信代碼等。
• 用戶則是通過這組特定字符序列與內(nèi)容集產(chǎn)生關聯(lián)的個體，同時也是賬戶內(nèi)容所描述的特定個體。

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

案例：信用卡

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

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

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

在小編看：

• 信用卡的用戶體系就是它的用戶成長體系，可能是用戶積分體系，會員等級體系等這些可以提升用戶粘性，促進用戶刷卡消費，提升業(yè)務量的產(chǎn)品運營模塊。而這部分模塊往往是直接面向用戶的，我們可以在各種信用卡產(chǎn)品中輕易找到。
• 信用卡的賬號體系就是信用卡的使用通道或者說產(chǎn)品觸達用戶的渠道?？梢允蔷€下直接刷卡消費，這時使用的賬號就是卡號和支付密碼。也可以線上產(chǎn)品端掃碼消費，或者第三方支付通道調(diào)起，這時必然要通過產(chǎn)品端的登錄賬號和密碼以及付款賬號和密碼等。這些不同的用途的賬號和密碼共同組建了一個復雜的賬號體系。
• 賬戶體系就更加復雜了，包括普通用戶可以看到的個人基本信息，個人認證信息，信貸賬戶，分期賬戶，分期賬戶，余額賬戶，借貸賬戶，消費記錄，貸款記錄，還款記錄等。以及普通用戶看不到的銀行信用評級記錄，逾期記錄，卡片升級記錄，異常消費記錄等等。由此也可以看出賬戶體系更多是面向業(yè)務的，根據(jù)業(yè)務不同，賬戶體系的設計偏重也不同。

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

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

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

用戶關系定位：

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

• 個人用戶：進行投保和被保險的個人。
• 個人客戶：存在的被保險的個人。
• 企業(yè)用戶：進行投保和被保險的企業(yè)。
• 企業(yè)客戶：進行被保險的企業(yè)。

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

案例：個人賬戶體系

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

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

這里可能有讀者朋友會問：為什么將基本信息和身份認證信息歸并在個人賬戶體系中，而不是放在用戶體系或者賬號體系中。

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

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

• 如該個人在某一保單中是連帶被保險人，那么該人對于該保單/該保險產(chǎn)品而言就是客戶，因為Ta無法與產(chǎn)品發(fā)生直接交互行為，而是需要主保險人代為進行保全或理賠的行為交互。
• 如該個人在某一保單中是主被保險人，但該保單的理賠收單方式是以企業(yè)為單位收單理賠。那么該個人對于該保單/該保險產(chǎn)品而言仍是客戶，因為TA沒有與產(chǎn)品發(fā)生直接交互行為。
• 如該個人在某一保單中是主被保險人，且他可以直接在產(chǎn)品中提起保全或理賠的申請，那么該個人對于該保單/該保險產(chǎn)品是用戶。

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

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

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

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

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

• 提供什么服務？比如投保，保全，理賠。
• 支持什么險種？比如健康險，財險，車險，壽險等。

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

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

從業(yè)務種類來進行保險賬戶體系的分析與構建：

保險的業(yè)務種類可以直接理解為保險的險種區(qū)分及具體理賠或保全規(guī)則。因為討論的是補充醫(yī)療保險的保全和理賠業(yè)務，所以第一個屬性就是賬戶業(yè)務類型，基本醫(yī)療保險或補充醫(yī)療保險。第二個重要的屬性則是保險項目性質(zhì)，這類企業(yè)的補充醫(yī)療保險項目會分為風險型和基金型。

所謂風險型保險項目是以一個特定時間段為標準（大多是一年一期），到期續(xù)保后重置保險額度，不進行保額累加的操作。而基金型保險項目則可以在到期續(xù)保后進行險種額度的累加。因而需要在賬戶中區(qū)分保單性質(zhì)是基金型還是風險型。

還有一類重要的維度就是保險期間，也就是險種額度有效期。例如去年的理賠申請僅能使用去年的險種額度而不能使用今年的險種額度。當然還有很多其他的規(guī)則，比如共享額度，即多個險種共用一個額度。企業(yè)公共額度，即在某些特殊病中對個人補充醫(yī)療賬戶的額外的額度補充。

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

從業(yè)務流程來進行保險賬戶體系的分析與構建：

保險的業(yè)務流程在這里可以理解為理賠流程和保全流程，當被保險人申請理賠服務后，在完成的收單，錄單，理算及復核后，會相應的扣除被保險人的對應的險種額度。這其中就會涉及到賬戶額度的變動。

根據(jù)業(yè)務流程不同，會延伸出額度加費流程，額度凍結(jié)流程，賬務清結(jié)算流程等。因此在額度層就需要記錄該賬戶的總額度，可用額度，凍結(jié)額度，剩余可用額度，初始額度，累計使用額度，累計加費額度。因而就能得到如下圖所示的額度賬戶的結(jié)構樣例。

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

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

有些讀者可能在設計賬戶體系或者初期構建一個C端產(chǎn)品時，會優(yōu)先搭建賬號體系，再根據(jù)業(yè)務發(fā)展逐步的完善賬戶體系和用戶體系。

這種產(chǎn)品設計思路在某些流量為王，偏重用戶體驗的C端產(chǎn)品中是一種還不錯的產(chǎn)品設計思路。但是在一些具有復雜業(yè)務場景的行業(yè)或產(chǎn)品中可能并不是一個好的設計思路，比如互聯(lián)網(wǎng)金融，互聯(lián)網(wǎng)保險或者偏重供需交易業(yè)務的互聯(lián)網(wǎng)+傳統(tǒng)行業(yè)。為什么這樣講呢？且看小編一一為你解答。

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

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

（1）自定義賬號類型：

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

（2）郵箱賬號類型：

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

（3）手機號碼賬號類型：

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

（4）三方授權賬號類型：

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

（5）特定賬號類型：

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

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

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

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

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

這里需要產(chǎn)品人衡量與思考的點在于：不合并或合并，對于業(yè)務價值的影響是什么？對于用戶價值的影響是什么？

（1）多賬號合并：

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

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

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

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

（2）多賬戶打通：

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

分析思路：

這種場景也較為常見，比如同一個微信可以在王者榮耀的iOS端和Android端各創(chuàng)建一個賬戶，登錄賬號通用，但對應的賬戶數(shù)據(jù)相互獨立。

那么什么業(yè)務場景中會對這類同一用戶同一賬號在多業(yè)務系統(tǒng)的賬戶數(shù)據(jù)進行打通處理呢？

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

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

總結(jié)

每一個行業(yè)，每一個產(chǎn)品都有自己的產(chǎn)品特點與業(yè)務偏重。產(chǎn)品方法論并不能以點概面，以偏概全。小編在本文分享的賬戶體系搭建的三步方法論僅針對偏重業(yè)務效率或供需交易的多業(yè)務場景的產(chǎn)品設計思路。希望通過本篇分享能為有需要的讀者朋友在產(chǎn)品設計之路上有所幫助和借鑒。

#專欄作家#

楊三季，微信公眾號：楊三季，人人都是產(chǎn)品經(jīng)理專欄作家。7年互聯(lián)網(wǎng)經(jīng)驗的高級產(chǎn)品官，深耕內(nèi)容電商，互聯(lián)網(wǎng)保險領域，擅長產(chǎn)品增長、數(shù)據(jù)分析、中臺架構等內(nèi)容。

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

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