如何从0-1建设高效率与好体验的用户中台

笔者看到网上关于用户中台的分享比较少，想着分享一下建设用户中台的经验及想法，和各位同行交流探讨。

企业发展壮大，企业的产品矩阵会越来越丰富，拥有更多app、小程序等。在这个过程中，可能会面临两个问题：

1. 效率低：比如，各个app团队分别开发所在业务的用户体系，重复造轮子重复开发，导致浪费太多没必要的研发成本及导致研发效率低下
2. 体验一般：比如，用户使用同一企业不同的app，需要分别注册登录，用户体验一般

那么我们就需要建设用户中台，统一管理公司里面的不同产品的用户账号体系，从而提高企业效率及用户体验。同时，建设用户中台及其他业务中台，企业可以抢占市场先机实现战略价值。

当企业发现新的业务机会，我们可以借助用户中台及其他业务中台迅速上线新产品，比其他没有中台的企业更快抢占用户，形成市场门槛获得市场领先优势。

一、用户中台架构

笔者基于自身业务实践及学习交流梳理的用户中台架构如下图所示，用户中台主要包括账号、认证、权限、安全风控/审计这四个模块。

不同企业基于自身业务情况，企业需要搭建的用户中台覆盖的功能范围及功能颗粒度有所区别，各位读者可以根据自身企业情况来搭建合适自己所负责业务的用户中台。

笔者建议读者可以根据自身企业业务复杂度、应用数量及用户量级来综合考虑搭建用户中台的功能范围及颗粒度。一般来说，企业业务越复杂、应用数量越多及用户量级越大，企业需要搭建的用户中台功能就越多及功能颗粒度就越细。

笔者曾通过建设用户中台统一服务公司旗下APP、PC、H5、小程序等前台应用及应用背后的亿级用户，大大提高了效率及用户体验。

二、用户中台具体搭建

前文已说明用户中台的架构/框架，本章节则展开说明用户中台各个模块的情况。

1. 账号

账号的状态主要分正常、冻结、注销。一个应用里面大部分账号是正常使用的账号，若应用监测账号有异常行为则对账号进行冻结限制账号使用，若用户不想继续使用应用则可以进行注销。

而账号包括用户画像/标签、会员体系等。企业可以根据用户画像/标签，对用户进行更精准的用户数据分析，从而进行产品策划、运营、营销等行为以达到提高产品的活跃度、留存、转化率、营收等目标。

用户画像/标签主要包括人口统计学标签、商业标签及行为标签，其中，人口统计学标签主要指用户姓名、年龄、地域、学历、收入、婚况等。

商业标签一般基于RFM模型：

• 最近一次消费 (Recency)
• 消费频率 (Frequency)
• 消费金额 (Monetary)

行为标签主要记录用户在应用进行的注册、登录、浏览、转发/分享等行为。

会员体系包括会员等级、会员积分、会员权益。应用可以对用户的行为划分成不同的积分，比如登录获得5积分，转发行为获得10积分。

用户通过不同积分或者充值不同金额的钱，获得不同等级的会员，比如青铜会员、白金会员、黄金会员等。同时不同等级的会员会有不同的会员权益，一般来说，越高等级的会员的会员权益越多/价值越大。

2. 认证

应用通过进行用户资料认证从而确保是用户本人进行操作或者提高信息/资料的真实性。

用户在进行一些敏感操作或者重要操作需要通过实人认证确保是本人在操作，比如在一些政务平台查看自己社保记录这些敏感信息。而用户进行实名认证、学历认证、房产认证、车辆认证、纳税认证等从而确保用户姓名、学历、房产、车辆、纳税/收入的真实性。

一般来说，对于大部分企业/应用，只需要实人认证、实名认证。而婚恋行业、金融行业则需要更多认证，如学历认证、房产认证、婚况认证等。

3. 权限

权限的设计一般采用RABC模型，RABC指基于角色的访问控制（Role-Based Access Control）。

RABC模型认为授权实际上是Who、What、How三元组之间的关系，也就是Who对What进行How的操作，也就是“主体”对“客体”的操作。

• Who：是权限的拥有者或主体（如：User，Role）
• What：是操作或对象（operation，object）
• How：具体的权限（Privilege）

同时角色设计包括角色、角色组，多个角色的集合可以成为一个角色组，角色组可以拥有多个角色的权限集合，以及角色之间可以有权限继承的关系（比如子角色继承夫角色的权限，同时增加新的/其他的权限）。

对大部分企业/应用来说，只需要角色，不需要设计比较复杂的角色组模型，只有角色比较多/比较复杂的应用/系统才需要角色组的设计。

而权限类型可以划分成功能权限及数据权限。功能权限是指这个角色可以打开哪些模块的菜单/页面，可以进行哪些操作（新增、删除、修改、查询、转发/分享等）；而数据权限则指这个角色打开这个菜单后能对哪些范围的数据进行操作，比如只能查看本人的数据，只能查看部门的数据，可以查看所有数据等。

4. 安全风控/审计

本章节最后才介绍安全风控/审计模块，并不是说安全风控/审计模块是不重要的。恰恰相反，安全风控/审计是非常重要的，是整个企业/应用生存的基石，出现安全问题可能会涉及法务危机/公关危机，甚至损失掉用户对企业/应用的品牌信任感，严重情况下还可以导致应用下架/企业破产。

安全模块主要包括偏功能层面的安全设计及偏技术层面的安全设计。

在偏功能层面的安全设计中，密码/密保主要是保护用户的密码安全性；账号绑定主要是方便用户多种登录方式，同时帮助用户通过其他方式找回账号密码及验证本账号的安全性；异常提醒是非常重要的，通过对用户异常行为的检测从而避免用户被盗号从而损失财物等情况。

在名单管理中:

• 黑名单：可以设置一些恶意账号为黑名单，从而限制这些账号登录使用等
• 风险名单：当一些账号存在异常使用风险，则设置这些账号为风险名单，从而限制这些账号敏感操作（如支付、转账等操作）但其他普通操作还是可以使用
• 白名单：白名单的主要应用场景，如应用要测试/灰度一些新功能，则把这些账号设置为白名单，然后这些账号可以提前使用这些新功能

在偏技术层面的安全设计中，企业/应用可以完善访问控制、入侵防范/防撞库、数据加密、安全监控等能力。同时从研发管理角度，要求工程师在研发过程中的技术安全规范，并且进行安全排查尽可能在应用上线前/出现安全问题前排查出安全风险。

三、后记

本文为笔者关于用户中台的浅见，若各位同行在实际工作中对建设更高效率，或者更好用户体验的用户中台有其他建议，欢迎联系笔者进行交流探讨。

作为一个产品经理，我们都致力于为所在业务提供更好的产品方案，祝阅读本文的产品经理们都能追寻内心的产品情怀实现产品价值，感谢大家的阅读！

本文作者 @skyland

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！