帳戶體系對於一個產品有多重要？我搭建過程的坑

原創： Kevin改變世界的點滴 Kevin改變世界的點滴

昨天

你們好，我是Kevin，這是2019年第137篇原創

在構建產品信息架構時候，少數產品新人在花時間思考用戶登陸註冊路徑與模塊可能並無怎麼花時間。

微信第三方登陸\手機號短信\遊客登陸\郵件登陸等，在現在移動互聯網天下。大部分的產品經理在設計可能腦子想都沒有多想，選用了

微信等主流第三方方式登陸註冊。

在最近咱們卻纔上了這個坑，因爲沒有深思熟慮帳戶體系的重要性以及可能的擴展致使了很多用戶流失。

而這個問題怎麼產生的？今天咱們從帳戶體系的搭建和用戶路徑提及。

帳戶體系的搭建意義：house結構

從0到1，以登陸註冊創建帳戶體系

上面這一篇是2017年我登陸註冊產品設計。相信在這篇文章裏面你能夠很快知道帳戶搭建的房屋邏輯。

如上圖，無論用戶選擇什麼方式註冊。在帳戶體系中都會以一個新的account的方式產生。

而產品經理與後臺開發工程師要解決的實際場景是，將真實的用戶對應在一個account上。

一個真實人只實際使用一個產品帳戶

用戶會由於手機號、微信號等其餘登陸方式生成Kevin0一、Kevin02等帳戶。但實際上擁有人都是Kevin。

這就形成了用戶帳戶多個，而用戶一個的實際問題

做爲一個互聯網企業，數據真實性和轉化漏斗是重要的。試想你的用戶都不是真實數據，而且在分析用戶下單狀況下你沒法保證數據報告是真實有效的。

做爲用戶來講，我須要記住多個帳戶。尤爲是當有付費行爲或訂單查詢，實際結果是可怕的。用戶沒法知道是那個帳戶享有vip服務。

如上爲愛奇藝的帳戶信息，用戶可使用手機號或微信號分別生成2個帳戶。形成用戶可能忘記本身充值的會員號。

多個帳戶存在的問題：去重與合併

看到這裏，有部分產品經理會提問：大不了把上面的Kevin下面的幾個帳戶合併了就好了吧。開發人工處理便可

關於合併：

這就是涉及到數據合併的問題，當產品從0到1快速迭代期間。業務快速擴展，字段也在增長。

合併意味着須要把這個帳戶之後的字段同步到一個帳戶下，不斷的維護工做是很是巨大的。

甚至有的帳戶根本不能合併，好比同一個產品下的電子錢包和雲音樂產品邏輯上就徹底不一樣，一個壓根不能合併，一個就是合併數據邏輯

關於去重：

那既然如此，只有讓用戶手動的排除或幫忙註銷用戶其餘帳戶。但須要客服甚至是發現了使用問題的用戶上門才能解決。可想而知時間和人力成本也是巨大。

用戶登陸註冊路徑順序與咱們踩過的坑

在PMTalk產品經理社區5月份上線新版本以來，很多用戶都會反饋一個問題。

即在手機上閱讀文章前的登陸都會提示手機號被佔用的狀況，起初認爲這只是早期用戶因爲沒有開放微信登陸致使的。隨着用戶反饋這個問題愈來愈多，咱們在思考是否是產品設計上的問題。

在遇到這樣的問題，咱們首先是知道前面說的用戶擁有多個登陸方式後產生的多個帳戶。在這裏增長了修改綁定手機號的方式，但願用戶將以前手機號綁定的帳戶更換爲當前微信下的。

用戶在微信中若爲新用戶，則註冊邏輯和用戶在PC端的註冊邏輯爲以下：

在邏輯上2者自己沒有太大的問題，用戶仍然會要求成爲手機號與微信進行綁定，保證一個帳戶。

但問題到底怎麼產生的？

咱們開始觀察用戶在pc與移動端登陸註冊交互路徑，咱們發現了問題。

因爲默認手機號登陸與註冊以及沒有要求手機登陸用戶強行綁定微號，致使90%以上的用戶在進入社區實際上是沒有綁定微信的。而這與H5的邏輯是衝突的，H5因微信受權的緣由用戶微信號與手機號是合併的。

這也就出現了用戶一旦打開了H5，用微信受權就會生成新的account帳戶。致使與PCaccount不是同一個。

在這件產品事故中，你能夠看出一個產品的帳戶體系是有多麼重要。至少如今我知道的，仍然有不在少數的產品因帳戶體系的問題，至今沒有給出一套合適的解決方案。

既要照顧最先的PC用戶、也要照顧移動端進來的新用戶。這樣的例子就如好比京東購物中須要考慮曾經在pc端使用用戶名註冊的用戶。

不得不在入口上保留【用戶】登陸的方式。

包括涉及到csdn等產品也出現了用戶帳戶合併的需求

帳戶體系的心得

一套好的帳戶體系能夠向下兼容，無論平臺怎麼變。均可以實現一個實際用戶只有一套帳戶的方式。

帳戶體系在考慮house結構外，還要知道用戶的交互路徑。從交互路徑下觀察用戶在不一樣平臺的登陸場景、註冊場景、以及找回密碼場景。

在這裏我將這個案例覆盤，期待將來在設計產品的同窗能夠避免採坑。

好，今天的分享就在這裏。