惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
Cyberwarzone
Cyberwarzone
L
LINUX DO - 最新话题
N
News and Events Feed by Topic
T
Troy Hunt's Blog
Help Net Security
Help Net Security
S
Security @ Cisco Blogs
Google DeepMind News
Google DeepMind News
Security Archives - TechRepublic
Security Archives - TechRepublic
M
MIT News - Artificial intelligence
G
Google Developers Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
V2EX - 技术
V2EX - 技术
Y
Y Combinator Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
大猫的无限游戏
大猫的无限游戏
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Security Blog
Microsoft Security Blog
Cisco Talos Blog
Cisco Talos Blog
T
Threatpost
Recent Commits to openclaw:main
Recent Commits to openclaw:main
S
SegmentFault 最新的问题
I
InfoQ
H
Hacker News: Front Page
D
Docker
Scott Helme
Scott Helme
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Blog — PlanetScale
Blog — PlanetScale
人人都是产品经理
人人都是产品经理
博客园 - 叶小钗
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
N
Netflix TechBlog - Medium
AWS News Blog
AWS News Blog
Know Your Adversary
Know Your Adversary
博客园 - 【当耐特】
T
Tor Project blog
U
Unit 42
H
Heimdal Security Blog
Microsoft Azure Blog
Microsoft Azure Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
P
Privacy & Cybersecurity Law Blog
PCI Perspectives
PCI Perspectives
美团技术团队
O
OpenAI News
T
Tailwind CSS Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
B
Blog
GbyAI
GbyAI
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
MyScale Blog
MyScale Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
万字长文,解析账号体系
飞鱼 B端产品站 · 2024-05-27 · via 人人都是产品经理

这个账户体系是用户在各个平台的通行证,也是平台识别用户的第一道关卡。这篇文章,作者给我们详细解释账号体系的概念和价值,供大家学习。

一、账号体系的概念及价值

账号体系是用户在各平台上的通行证

平台给与用户可持续的服务,用户在平台上获取价值,中间的媒介,便是账号体系。

账号体系存在的价值在于:

  1. 提升系统的持续迭代能力,为后期产品扩张预先铺垫;
  2. 加强账户相关功能模块的可行性,保证系统的稳定性;
  3. 账户融合能力提升,产品生态圈布局一站式账户通行证。

二、账号体系的需求分析

账号体系在对于用户与平台的意义在于,保障用户使用产品服务,产品提供个性化服务,同时满足企业的商业需求。

那么,账号体系的需求点在于何处?

  1. 用户的信息可被证实(如邮箱确认,手机验证码确认等),保障用户的真实性。
  2. 一个人有多个手机、多个邮箱、多个第三方账号,但其拥有者均为同一个人,需要将其合并为同一个账号,即保障用户的唯一性。
  3. 用户手机可能更换,存在手机号被注册情况,需解绑旧手机号同时绑定新手机号,即保障用户账号的账户安全性。
  4. 用户进行交易服务时,采取的保障措施,即保障用户的资金安全性。
  5. 用户采用第三方登录时,同时搭建自身的账号体系。
  6. ……

以需求的强弱来说,账号体系又可分为强需求弱需求

账号体系在对于社交类、互动类的产品来说,是重中之重,为强需求。账号体系是一切产品功能的基石,这类型产品,大多需要互动,建立用户数据等,那么就需要账号体系的搭建及维系。在这当中,账号体系展现的是核心价值,通过记录用户自身各类数据,将用户利益关联在其账号下,提供可持续的服务。

而对于工具类的产品,账号体系相对来说则是弱需求,无账号体系也可正常运作及使用,但有了账号体系,可更加精准的进行后续的用户画像建立,前期可能不重要,后续在进行更多版本迭代的时候,便可能派上用场。在这当中,账号体系展现的是扩展价值及商业价值,通过沉淀的用户数据,提供个性化服务,更高效的满足用户需求,提升用户体验。

总的来说,账号体系是为了解决用户信息唯一性、真实性、安全性的问题,于所有产品而言,账号体系并不是必备的,其搭建时间可在产品规划前期也可在产品规划后期,取决于产品类型。

三、账号体系的类别及历史渊源

账号体系分为多种,从互联网发展至今,可归纳为四种,自定义账号、邮箱账号、手机号账号、第三方登录账号

1. 自定义账号

自定义账号为“账号+密码”的形式,一般账号为用户自行定义,是比较久远的的账号体系。在互联网野蛮生长的前期,各大平台尚未建立,且智能手机还未出世,使用平台均为PC端,则账号需用户自行拟定。

缺点的话,相信经历过的伙伴记忆尤深,经常拿着个小本子记录着不同的账号密码。QQ一个,某游戏平台一个,某社交平台一个……若设置得不同,则增加了用户的记忆负担

放在互联网发展初期,则较为适用,而对于现在如此多的平台,“账号+密码”的方式已经开始慢慢逐步被替代

2. 邮箱账号

在互联网蛮荒时代的过去,为了解决“降低用户记忆负担”的问题,适逢各类邮箱盛行,QQ邮箱、网易邮箱、新浪邮箱等各大巨头争相抢占市场,邮箱已成为当时用户的常用工具,记忆难度远比随意取得账号名更为简单,所以被用以“邮箱号+密码”的登录方式。

而邮箱作为注册方式,优点是像对于自定义账号的体系,邮箱更能够降低用户记忆负担;缺点也很明显,邮箱的认证环节较为冗长,需要打开邮箱接收邮件并确认,容易在这个过程当中流失用户。

且在以往,PC端占据主导,如今,移动端占领大半江山,大多数用户不会在手机上安装一个邮箱应用,那么,在移动端接收邮箱验证信息的时候,难度增加,流失率也会增多

所以对于目前移动端主导市场的情况来说,“邮箱+密码”的账号体系,也已经开始慢慢地淡出人们视野。

3. 手机号账号体系

据数据资料显示,截止2018年,智能手机的市场份额占据比已经达到98.6%,那么,可以说基本人手一机

每个人可能没有社交账号(微信、QQ等),但一定会有手机号

优点的话,对于用户来说,记住账号可能困难,但记住自身的手机号较为简单,且安全性高;对于平台来说,利利用手机号登录,可以搭建起自身的账号体系,便于后续的精细化运营(活动通知,用户召回等等);由于目前手机号都是运营商实名,可减少垃圾营销号的账号。

缺点的话,其一,“手机号+验证码”登录需要支付一定的短信费用,好在价格不多,但需要防范黑客的恶意攻击,这里也涉及到账号体系的风控机制,后续会谈到;其二,在信号差的地方,接收不到验证码;其三,手机号存在换号情况,需要考虑解绑逻辑及换号逻辑。

注意点:手机号账号体系的便捷点在于,可将注册与登录流程合为一体,若未注册,则在获取验证码后登录的同时,系统自动帮用户注册,减少了用户的操作成本,提高便捷性。

但同时,由于其便捷性,也有其局限性,用户可能变更手机号,所以需要在用手机号注册之后,引导用户设置密码,减少风险。

4. 第三方账号体系

随着各大超级APP的诞生及趋于成熟,衍生出了“第三方登录”的这个概念。

第三方账号体系是指用户通过授权,将第三方资料绑定到自身账号体系上。当查询到用户第三方的帐号已经绑定了平台的某个user_id时,直接登录对应的帐号,实现一键注册与一键登录。

  • 优点的话,对于用户来说,授权方便,当拥有主流社交账号(如微信、QQ、微博等),即可一键注册及一键登录,无需浪费太多时间。且可获取第三方平台的一些基础资料,填充了账号前期的空白(例如头像、昵称等)
  • 缺点的话,主要针对于平台,无法形成自身的账号体系,依托于第三方,有一定的风险(第三方倒闭之类的),但可通过后续进入到平台,引导绑定手机号等操作来弥补。

考虑采用第三方登录,还需要考虑到,立即绑定延时绑定这两种情况。通常在第三方授权后,系统仅能拿到头像昵称等部分信息,若考虑后续自身的账号信息,那么需要要求用户进行绑定相应信息,则便涉及到立即绑定与延时绑定。

立即绑定会使得用户操作繁琐,容易造成流失,但能保证获取用户的信息。

延时绑定可保证用户体验,但却容易在使用过程中,用户填写信息时,被拒绝。

至于采用哪种方式,就需要在实际的产品设计当中进行取舍。

四、如何设计账号体系?

1. 账号体系的字段

要设计一个账号体系,那么需要先了解,账号体系包括哪些基础字段。

(1)用户账号(User Account,包括自定义、邮箱、手机号)

用户账号(User Account)为系统平台内唯一的标识,不同的账号体系类型,用户账号的展现形式也不同。包括自定义账号,邮箱号,手机号三种类型。

  • 自定义账号的,则用户账号由数字+字母或者中文组成。
  • 邮箱的话,则为邮箱号,数字+英文组成。
  • 手机号,则由11位数字组成。

通常处于隐私性及安全性的层面考虑,用户账号仅对个人可见,其余人不可见,是用户个人的通行证。

(2)用户密码(User Password)

用户密码(User Password)是基于“账号+密码”体系类的字段,一般由字母跟数字组成,部分密码会设置成包含符号。

这边产品同学在设计的时候需要考虑“字母+数字”跟“字母+数字+符号”的不同情况。

(3)用户名称(UserName)

用户名称(UserName)为用户对外展示的名字标识。可以是用户自定义,也可以是系统先自行分配设置,后续提供修改的权限,若是采用第三方授权登录,则一般会以第三方的昵称作为用户名称,后续可修改。

具体为用户自定义还是系统分配,下文设计的时候会具体说明。

(4)用户唯一标识(UserID,简称UID)

用户唯一标识(UID)为系统配置,一般为数字组成,不对用户可见。用户在注册为系统的账号后,则自动生成,不可更改,与每个用户一一对应。

(5)开放账户(OpenID)

借助第三方网站url验证用户身份,当用户第三方授权登录成功,系统通过获取用户的open ID生成user ID,同时也读取用户在第三方网站的身份昵称以及头像,该昵称可作为首次的账号名。

在技术层面上,OpenID也分为静默授权与用户授权

2. 账号体系的核心流程

账号体系包含四个核心流程,分别为注册流程、登录流程、找回密码流程、风控流程。其中,注册流程与登录流程可合并为一起。

(1)注册+登录流程

要设计一个登录注册流程,那么我们需要先简单的进行该流程的具体分析。

账号的注册登陆流程,遵循三个原则:①安全性 ②普适性 ③便捷性。

简单来说,登陆注册流程,安全第一是前提,其次保证普适性的同时,追求便捷性。:那么,根据KANO模型来看,安全性为基本型需求,普适性为期望型需求,便捷性为兴奋性需求。

上文提到,注册登录的几个组合方式,账号+密码、邮箱+密码、手机号+验证码、手机号+密码+验证码、第三方登录、第三方登陆+手机号绑定、第三方登录+密码、第三方登录+密码+手机号绑定…….

组合方式多样,并不必刻意去记,遵循主流绑定方式的同时,绑定的信息(手机号、微信等)越多,于平台来说风险越低,于用户来说,安全性越高,但同时也会增加用户操作成本。如何设计,取决于平台的现状及自身定位,不同产品,不同设计方法,并不能一概而论。

针对于安全性来说,绑定的方式越多,越安全;针对于便捷性来说,前期门槛可设置简单的注册登录(例如市面上的“闪验”登录),后续再进行资料补充。

这边有一个注意点,注意《用户协议》的规划设计。

《用户协议》是制约用户滥用违法的手段干扰系统运行的手段,是注册流程中不可缺少的部分,却也是最容易忽略的部分。

有几种方式可以设计,仅供参考:

  • 展示可供勾选的用户协议,根据产品的业务形态可以选择是否默认勾选的方式。
  • 注册时,强制弹出,用户需先同意后才进行后续操作,避免了后续因不同意浪费的时间。注册即表示同意用户协议。

(2)找回密码流程

常见的几种找回密码的方式:手机号、邮箱、银行卡、人工申诉

①手机号验证

若密码丢失,则可通过“原手机+验证码”的形式来进行重设密码,但会有运营商二次放号的情况,那么需要在系统设计中规划多个“受信任手机”或“受信任设备”的情况。

②邮箱找回

邮箱找回的方法是以往PC端的经典方法,PC时代=邮箱时代。QQ、网易等主流邮箱占据了整个市场,自然通过邮箱找回最为方便。但随着移动时代的到来,邮箱找回的方式逐渐被遗弃,且在账号体系若无通过邮箱为主的账号方式,则一般也很少会在体系当中要求用户绑定邮箱。

在移动时代,邮箱找回较为麻烦且用处不大,但可作为手机号找回的辅助方式。

③验证银行卡

若在体系当中涉及到银行卡绑定的,则银行卡可作为个人的唯一标识,通过“银行卡+预留手机号+验证码”的验证方式来验证个人信息,从而明确是否本人的方式,来找回密码。

④人工服务

在各类验证方式都走不通的情况下,只能通过人工服务来进行找回密码。需要先让用户上传身份证等个人确切信息之后,客服在一定的工作日内进行处理,会耗费相应的客服资源,且反馈时间较长

(3)风控流程

风控流程的本质在于确保用户身份的合法性及正确性,防止部分不法分子恶意攻击及注册,影响原本体系的安全。

账号作为用户登录系统的“通行证”,其重要性不言而喻。而保护好账号的安全,也是至关重要的。其在于注册、登录流程上,被黑客恶意注册,导致平台资源浪费;账号信息泄露,导致用户信息受损;不论是对于平台还是对于用户,都是极大的损失。

对于风控措施,可从恶意注册账号、IP、盗取等方向来思考。

以下几项针对于账号体系的风控措施,可供参考。

针对于恶意注册账号,浪费平台资源:

  • 禁止非正常的、大量的“验证账号是否存在”的操作请求,防止不法份子通过不停的输入大量账号,去获取该账号是否存在的数据。
  • 邮箱注册时增加邮件验证码功能或者通过邮件进行激活确认。
  • 通过短信验证时,进行短信次数限制,保护短信通道不被恶意者大量刷短信,造成堵塞。
  • 验证方式升级,通过图像验证码、文字验证码甚至题目验证码等,加大验证难度。
  • 唯一手机号,保证一机一号。
  • 通过IP对请求上限做出限制,防止恶意用户大量发起注册请求,攻击服务器。若多次请求,数据错误,则对账号进行梯度时间冻结。

针对于盗取账号,影响账号安全性:

  • 确保用户访问的真实性,进行手机号验证或手机扫码登录。
  • 异常操作,非本人IP/手机进行通知提醒。
  • 高风险的账号操作,系统后台运行后,重新进入,需要重新输入验证信息(指纹、手势等),常用在支付类系统。

3. 账号体系的页面展示

页面仅为部分逻辑展示,目前发展到了现在,登录注册的页面展现形式各异,依据系统的定位来规划及设计即可。

五、账号体系的合并与打通

在各大系统中,存在多个系统,多个账号,互相交杂的情况,那么,延伸出了账号的合并问题与打通问题。

同个系统中,存在的问题是合并问题:

  • 同类型的账号合并;
  • 不同类型的账号合并。

不同系统中,存在的问题是打通问题:

  • 单向数据打通;
  • 双向数据打通。

1. 账号体系的合并

账号的合并指的是,在一个系统内,一个用户的多个账号合并成为同一个账号。

账号分为同类型不同类型两种。同类型指的是注册类型相同,例如同一个人用两个手机号注册两个账号;不同类型指的是注册类型不同,例如有手机号注册,有微信注册,有邮箱注册,但其拥有者均为同一个人。

那么此时,用户发起合并,将其所拥有的账号合并为同一个

处理方式为:保留其中一个主账号,将数据累加到主账号当中,其余账号数据清空。

2. 账号体系的打通

账号的打通指的是,在不同的系统,账号数据的互通。在这当中,“互通”又分为单向打通与双向打通。

  • 单向打通指的是一个系统有权使用另外一个系统的部分数据,这里的“有权使用”我们可以理解为“授权”。第三方授权便是这个原理,某APP授权微信,则由于微信的开放平台数据,某APP可获取其名称头像等数据,进而采用这些数据在系统中流转。
  • 双向打通指的是两个不同的系统,数据相通,多用于合作模式的系统,情况不多。例如A与B两个系统,部分数据是公用的,那么,在A系统中修改了个人信息,在B系统中的个人信息也随之修改,共用的是同一套数据。

这当中的核心为数据流通,一个用户在多个系统内,局部数据流通(单向或双向),数据总量不变。

六、账号体系设计的几个要点

1. 搭建适合自身产品的账号体系

选择账号体系基于四个维度来判定,分别是:①终端类型 ②产品类型 ③用户类型 ④产品发展四个方面。

(1)终端类型

目前对于终端,分别是PC端移动端。对于以往PC端时代来说,邮箱是最盛行的,随手打开邮箱即可接收验证信息,拿到现在移动时代,如此操作便略显繁琐了。

(2)产品类型

不同的产品类型,由于其本身性质的不同,应设计不同的账号体系。

设计的核心在于尽量靠近产品主流业务所使用的信息,来设计账号体系

例如:打车平台、外卖平台是必须要知道用户手机号的,那么可直接采用手机号登录的方式来设计账户体系。

(3)用户类型

用户类型的不同,也需要考虑不同的账号体系。

拿三类用户来举个例子,学生、年轻人、老年人

  • 对于学生来说,考虑到部分学生是没有手机号的,则若仅限制用手机号注册,便会流失这部分的用户,而QQ几乎是人手一个,那么采用第三方登录是最合适的方法。
  • 对于年轻人来说,手机号、各类主流第三方账户,邮箱均有,那么设计最适合的登录方式即可。
  • 对于老年人来说,账号密码的登录体系由于其复杂性,必然不适合。那么采用手机号登陆较为合适,考虑到老年人这个特殊群体,需要设计较为简单的操作流程,可采用目前较为流行的“本机号码一键登录”的方式,将注册登录融为一体。

(4)产品发展

产品在前期发展的时候,需要快速占领市场,时间紧任务重,那么可直接采用接入第三方登录的方式。在发展到一定体量的时候,那么便有必要构建一套自己的账户体系了。

2. 根据产品类型设定账号是否强制登录

(1)先浏览再登录

若是内容类、资讯类的产品,为了用户体验,一般不强制登录,采用先浏览再登录的方式。将登录后置的一个重要原因在于留住用户。根据漏斗模型可知,用户操作步骤越多,流失越多。且降低浏览的门槛,能够吸引用户查看内容,当需要使用到账号信息时(例如购买),再引导用户去进行注册登录的操作。

那么,这么设计的缺点在于①注册入口多,系统维护成本高 ②用户信息需要分多环节设计

(2)先登录再浏览

若是社交类的产品,则一般采用先登录再浏览的方式。其原因在于,针对于社交,账号是唯一主体,且需要通过账号来进行后续的操作,无法跳过注册登录的流程。

但是,部分内容类的产品这么设计,容易造成用户流失

(3)无需注册登录

若是工具类的产品,则账号体系作为弱需求的存在,可有可无,在资源有限的情况下,可不做账号体系,直接使用产品,便也无需注册登录。当然,上文有提到,针对于工具类的产品,账号体系的意义在于后续的扩展价值及商业价值。

3. 考虑账号体系的安全机制(二次放号的情况)

上文提到,目前我们主流的账号体系注册方式,主要为:①手机号账号体系 ②第三方账号体系

那么,而以手机号作为核心的账号体系,却会延伸出不同的问题。

手机号更换且停用的情况,导致旧手机号丢失,运营商会有将废弃的手机号二次回收再发放的情况。

举个例子:A用户先前用旧的号码注册了某平台。有一天,他换了新的手机号,那么旧的号码便注销掉,运营商过了一段时间(大约四个月)重新将其投放入市场。

那么这个时候,便会遇到,有人拿这个旧的手机号进入这个平台,篡改了A用户的账号信息。

那么,如何避免这个问题呢?

本质在于,通过身份验证来确保是用户本人操作

(1)好友辅助验证

社交类产品多采用该方式,如QQ和微信,通过线下联系好友,好友在号上进行确认操作,多位好友进行验证之后,便通过。

安全性较高,但换来的也是操作复杂麻烦的代价,多用于社交类产品。

(2)历史信息验证

通过用户自身回忆历史的操作信息及个人信息,并回答相应问题,正确后即可通过验证。例如:“近期的购物产品是什么”“曾经用过什么密码”“回忆一下最近的好友”“回忆一下近期使用过的头像”等等

但当平台逐渐增多,数据不断交替更新的现在,历史信息验证这个方法的准确度逐渐下降,要让用户记住曾经设置的某些信息,越来越难,体验远没有想象中的好。

(3)用户身份验证

倘若用户在系统中留下了自身的信息,唯一且安全,那么,该信息便可用于自身的信息验证。例如:人脸识别,身份证,银行卡,社保卡等信息。

(4)通过已添加的其他“受信任的手机号/设备”通过验证

部分平台在系统内,会增设多个“受信任手机号”的功能,添加多个手机号,当主手机号丢失的时候,可通过其余手机号发送短信的信息验证,来验证用户自身的身份。

也可添加多个“受信任的设备”来认证登录,此后,受信任的设备可将陌生设备踢下线。

(5)密保问题认证/邮箱认证

通过密保问题验证及邮箱验证,是互联网早期PC时代时惯用的方式,通过“账号密码”的账号体系,附带设置密保问题的安全措施,保证用户的账号安全。

这个方式最大的问题便是密保问题的记忆,往往很多人还是会忘记。举个例子,如今苹果账号依然是使用密保问题,如若无刻意去记忆,那么我想大部分人还是容易遗忘。

(6)客服申述等

在所有自身提交信息并认证的措施都尝试之后,若还不行,那么只能通过客服申诉来找回账号。通过让用户填写证明账号信息的表单,提交客服,从而来人工判定账号的归属人。

但此法容易占用客服资源,且费时费力,是下下之策。

4. 一些能够提升用户体验的设计

(1)手机号注册,带空格

在注册登录或绑定手机号等两个流程,需输入手机号的时候,自动为用户空出空位出来,以3-4-4的方式,用户在输入的过程中随时可更加方便校准所输入的内容及位数是否正确。

在用户需要输入银行卡的信息时,同理,以4-4-4-4-3的方式来设计。

(2)精准的错误提示

在账号的表单输入框中,若信息输入错误,则需以精确的错误提示反馈给用户。

举个例子,在用户输入账号密码后,若信息不正确,则有两种处理方式:①信息错误 ②账号不存在/密码错误。

很显然,第二种处理方式会比第一种好得多,用户可以清晰的知道自身的错误并修正,减少了多次尝试的时间。

同时,根据泰斯勒定律“越简单的前端使用,那么背后一定有复杂的逻辑支撑”,用户获得的错误提示越精准,则开发资源及时间需要付出的越多。若产品前期急着开发上线,可牺牲部分交互及用户体验,优先级排后,待稳定后再做修改。

(3)输入数字的时候,自动调起数字键盘

在输入密码的时候,若密码要求纯数字,则自动调起数字键盘,且强制不可转换,以避免用户误操作输入错误信息,增加不必要的用户操作。

(4)有前置条件的按钮可置灰,输入信息后恢复可点击状态

若信息未达到系统要求信息,则按钮置灰,减少不必要的点击。

举个例子:登录时,需要输入账号与密码,若用户仅输入账号或密码时,按钮保持置灰状态。当账号及密码均输入且达到要求(例如6到16位),按钮回复可点击状态。

(5)密码提供显示/隐藏按钮

输入安全性较高的信息时,给予用户显示/隐藏按钮。

例如:在输入密码时,用户旁边若有人,则输入密码的步骤的隐私性降低,提供显示/隐藏按钮,可让用户自行选择是否显示正在输入的信息。

(6)必填与非必填项的提示

用户首次注册账号登录时,部分系统出于做前期用户推荐的目的,要求用户输入部分信息,则信息作为表单,进行必填与非必填的提示,例如可使用*号作为区分。将操作的可控性前置到用户输入信息的时候。

七、写在最后

账号体系可大可小,一个看似小的功能点可以延伸出很多细微的知识。

重点在于产品的体量大小,是否值得如此深度的来设计。

刚开始的产品,账号体系的作用可能仅限于可注册登陆,且用户量也少,那么并不怎么需要考虑风控及安全机制。而将自身主体业务做精做全之后,再来完善账号体系也不迟,毕竟账号体系说来也是一个庞大的工程量

本文由 @飞鱼 B端产品站 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务