常被混淆的賬號體系與賬戶體系

7 評論 1.3萬 瀏覽 63 收藏 25 分鐘

?導語:賬戶體系是任意一款互聯網產品都必有的基礎體系,而賬戶體系的產品設計文章卻寥寥無幾。本文小編將從互聯保險產品的賬戶體系入手,來聊一聊如何基于復雜業務場景構建一套完整賬戶體系。

賬戶體系、賬號體系、用戶體系的區別與聯系

在分享如何構建賬戶體系之前,先聊一聊小編對「賬戶」「賬號」「用戶」三者之間關聯和區別的理解。

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

在互聯網產品中,用戶體系往往是面向用戶,更偏重于用戶運營與增長。而賬戶體系則是面向業務,更偏重于產品結構與業務支撐。賬號體系則是橋接在用戶體系與賬戶體系之間,為用戶體系提供價值體現的同時,又可為賬戶體系提供服務的支持。換言之,在偏重用戶體驗的產品中,賬戶體系的價值常常被忽略。而在偏重于業務效率與供需交易的產品中,賬戶體系的價值舉足輕重。

案例:信用卡

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

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

那么我們換一個思考的角度,站在產品經理的立場看,對于一個信用卡產品來講,它的用戶體系,賬號體系,賬戶體系又分別是什么呢?

在小編看:

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

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

搭建賬戶體系的第一步:用戶是誰,具有什么樣的特點?

在互聯網保險行業中,由于其業務場景的多元化,可以分為持牌保險企業,保險經紀公司,理賠服務供應商,代理人展業供應商等多種產品形態。小編將通過復雜度適中的互保經紀公司的產品為例來進行分析。

用戶關系定位:

首先將保險產品的需求側用戶分為以下四類:

  • 個人用戶:進行投保和被保險的個人。
  • 個人客戶:存在的被保險的個人。
  • 企業用戶:進行投保和被保險的企業。
  • 企業客戶:進行被保險的企業。

這里的用戶和客戶的區別在于:用戶是與產品產生直接行為的個體,而客戶是與產品產生間接行為的個體。間接行為就是該個體并未與本產品中產生直接交互行為,而是通過第三方代為完成的。比如企業為員工提供的補充醫療險,就是企業為員工集體購買的險種。當產品本身為被保險人提供保全或理賠服務時,則需要為該被保險人進行賬戶的創建和維護。客戶與用戶的具體關聯邏輯將在第二步中進行講解。

案例:個人賬戶體系

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

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

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

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

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

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

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

搭建賬戶體系的第二步:業務是什么,具有什么樣的區別?

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

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

在互聯網保險中,業務主要可以分為兩個思考方向:

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

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

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

從業務種類來進行保險賬戶體系的分析與構建:

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

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

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

根據上述描述,我可以將額度賬戶切分為四層結構,即項目層,保單層,責任層,額度層。額度有效期則是從保單層到責任層再到額度層皆有關聯。

從業務流程來進行保險賬戶體系的分析與構建:

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

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

搭建賬戶體系的第三步:賬號有哪些,會遇到什么問題?

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

有些讀者可能在設計賬戶體系或者初期構建一個C端產品時,會優先搭建賬號體系,再根據業務發展逐步的完善賬戶體系和用戶體系。

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

1. 互聯網產品的賬號類型和適應場景

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

(1)自定義賬號類型:

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

(2)郵箱賬號類型:

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

(3)手機號碼賬號類型:

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

(4)三方授權賬號類型:

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

(5)特定賬號類型:

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

2. 同一產品的賬號合并與賬戶打通

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

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

合并賬號數據其實就是在同一個業務體系或系統下,將同一個用戶的不同賬號進行數據合并。而賬號的合并的本質區別就在于:是否將同一用戶的不同賬號的UID進行合并,保持用戶在系統中的唯一性。

這里需要產品人衡量與思考的點在于:不合并或合并,對于業務價值的影響是什么?對于用戶價值的影響是什么?

(1)多賬號合并:

場景:用戶A在同一產品的同一業務系統中有兩個相互獨立的登錄賬號,類型相同。

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

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

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

(2)多賬戶打通:

場景:用戶A在同一產品的不同業務系統中共用一個登錄賬號,但業務的賬戶數據是相互獨立,不關聯同步。

分析思路:

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

那么什么業務場景中會對這類同一用戶同一賬號在多業務系統的賬戶數據進行打通處理呢?

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

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

總結

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

#專欄作家#

楊三季,微信公眾號:楊三季,人人都是產品經理專欄作家。7年互聯網經驗的高級產品官,深耕內容電商,互聯網保險領域,擅長產品增長、數據分析、中臺架構等內容。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自pexels,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 把基本信息和身份認證信息歸為賬戶體系,那么同一個用戶的在不同業務系統的賬戶的身份認證信息不打通?每個業務系統的賬戶自己維護一套身份認證信息嗎?

    回復
  2. 自己人,一個群的,看到來支持下,寫的不錯!

    回復
  3. 好文章

    回復
  4. 賬號類似于數字身份標識,可以脫離雨用戶存在,同時可以基于數字身份關聯到用戶(人)在真實世界的身份(公司員工,平臺用戶等),賬戶依托于用戶(可以是個人或者組織機構),作為用戶資產或權益的憑證,在具體業務或者系統中,用戶需要通過賬號操作賬戶。

    回復
  5. 回復
  6. 好文章!

    回復
    1. 謝謝

      回復