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

推荐订阅源

博客园 - Franky
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
Google DeepMind News
Google DeepMind News
腾讯CDC
G
Google Developers Blog
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
Recent Announcements
Recent Announcements
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
aimingoo的专栏
aimingoo的专栏
有赞技术团队
有赞技术团队
Jina AI
Jina AI
人人都是产品经理
人人都是产品经理
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
M
MIT News - Artificial intelligence
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
美团技术团队
WordPress大学
WordPress大学
阮一峰的网络日志
阮一峰的网络日志

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
C端用户统一管理与OneID服务(含常见构建错误的实体关系)
王建儒营销数字化 · 2024-04-16 · via 人人都是产品经理

C端用户中心既关联用户基本信息,也管理各种关联关系,在日常业务中发挥着相应的管理职能和对业务系统的支撑服务职能。这篇文章里,作者就对C端用户中心及OneID服务等内容做了讲解,一起来看一下。

作为整个平台最核心、最基础的业务系统,C端用户中心统一管理C端用户基础信息、账户安全、通用配置等,并发挥着C端用户、账户以及关联关系的管理职能和对业务系统的支撑服务职能。

一、业务定义

客户、用户、会员、粉丝,这些词放在单个场景中沟通时,大家会很清晰的理解指的是什么,但在没有限定的场景下,就容易混淆。所以,有必要把这4个之间的区别讲清楚。

1. 客户、用户、会员、粉丝的区别

虽然是4个不同的定义,但在营销服平台中,使用同一个业务实体进行管理。

部分高单价商品或服务中,对C端客户还会多一个分类:即匿名用户、普通用户、意向用户、订金用户、成交用户。

2. 常见的C端客户、会员、用户的关系

  • C端客户是最大集:聚合了所有有手机号的(也包括未注册的用户)、只有类似微信Unionid的匿名用户等。
  • 从业务增长角度,期望客户量、会员量越大越好。
  • 从触达和转化角度,期望小程序用户、企微-外部联系人越来越多,接近会员量。
  • 从深度服务和用户价值挖掘角度,期望APP用户量越来越大,活跃度越高越好。

二、系统功能

C端用户中心既关联用户基本信息,也管理各种关联关系,以及用户的个性化设置。核心功能如下:

1. 基础管理

提供客户OneID服务,保障整个平台使用统一管理、唯一的客户数据;管理客户基本信息,如昵称、性别、城市等基础信息,用户的常用地址进行管理。需要特别说明的2点:

  • 客户类型分普通消费者、内部员工、伙伴员工,需要时还可增加集团员工类型。与B端用户中心的数据联动。客户类型的配置是为了区分普通消费者和员工,可以有针对性的设置营销活动。
  • 用户的真实姓名、证件号、生日、性别等C端维护的信息,如果没有实名认证环节,则B端也需要维护一套,如性别、生日。

2. 账户管理

统一管理C端用户的账户,包括账户密码服务、验证服务、找回服务、服务协议签署、账户注销等。业务与安全策略较高的金融类业务还有一人多账户、账户与设备强绑定等功能。

  • 密码服务:分登录密码、服务密码、安防密码。服务密码在强服务场景的行业中使用,安防密码则是针对智能设备的操作而设置的安全防护密码,如对智能汽车的指定操作所需的安全密码。
  • 验证服务:与密码服务配套使用,进一步确认用户身份,比如登录验证码、找回密码的验证服务等。
  • 账户注销:用户在应用端发起,请求用户中心服务端、核验完成后,按照约定的时间周期自动注销。
  • 账户安全:实名信息提交认证、人脸认证确认身份,并可设置多种登录方式,如密码登录、划线登录、指纹登录、声音登录等。可设置是否开启NFC。
  • 系统权限:用户授权APP获取系统权限,如定位、相机、文件存储等。
  • 账户授权:用户授权当前APP与三方平台使用用户信息。

3. 隐私管理

随着个人信息保护相关法律的实施和人们隐私保护意识的提升,C端产品必须透明化对隐私的保护和授权策略。

  • 常用隐私设置:加好友是否验证、是否公开真实姓名、动态不可见等。
  • 广告推荐设置:用户可开启或关闭C端产品个性化推荐、平台的广告推荐。
  • 信息收集清单:明确告知用户已收集到的信息,比如身份信息、位置信息、设备信息、搜索信息、人脸信息等。
  • 信息共享清单:授权给第三方的信息说明,包括三方授权说明、SDK说明、共享服务说明等。
  • 隐私协议:最新品牌方隐私协议说明、更新公告,直接关联方隐私政策说明。运营商授权用户使用手机号便捷登录的授权协议。

4. 通用管理

  • 用户可以设置语言、字体、皮肤,以及配置常用页面、能否使用剪贴板内容等。
  • 人与设备:统一管理人人关系、人设备的关系,以及授权记录。如车主通过授权某辆车的一些功能给朋友,让朋友可以使用车辆。并管理个人使用偏好,如汽车的座椅位置、后视镜角度、氛围灯等。

三、整体架构

  • 应用平台:已存在的平台或业务协同的三方平台。
  • 业务中心:进行业务处理的各业务中心,比如线索中心、会员中心、权益中心等。
  • 生态服务:与品牌方协同,为C端消费者提供服务的服务商,如银行、保险等。
  • 共享服务:业务环节中提供某项服务的服务平台,如身份验证、电子签名等。

四、ER模型

  • 证件信息:常用的有身份证、护照、军官证、港澳台居住证。
  • 应用账户信息:用户在不同平台的账户信息,比如微信公众号、小程序、企微、抖音等应用账户id,都需要记录。
  • 企微员工关系:一个C端用户与多个员工添加企微好友,记录好友关系。
  • 门店客户:客户是品牌的,也是门店的。用户与门店发生互动,可成为门店的客户。
  • 账户授权记录:记录账户信息授权给哪些三方平台了。
  • 协议签署记录:用户服务协议、隐私政策等更新后,用户新的签署记录(有区分是否强制签署)。
  • 商家员工关系:一个C端用户会在多个商家任职或服务,需要记录关联关系,品牌商家活动中会应用到。
  • 人人关系:对人与人的关系进行统一管理。人人关系类型有4大类:亲友、粉丝、分享、分销。
  • 人设备关系:1个用户拥有或被授权不同设备,需要管理人与设备的关系,比如手机、汽车、智能门锁等。
  • 设备授权记录:设备主可多次授权不同设备给不同的用户。

常见且容易构建错误的实体关系:

有些平台使用大宽表的方式来构建各类应用账户信息,以及员工企微员工关系,给业务开展、系统扩展挖了不小的坑。

五、关键应用

1. 用户OneID服务

C端客户可通过不同的渠道触达到品牌,在不同的场景下提供的用户ID信息也会很多,需要统一管理起来并归一到一个唯一的OneID上。

按照更换频次、获取难易程度,将常见的30+的用户ID进行了分类和排序:

2. 常见的两种OneID归一方案

1-复杂模型算法:将可收集到的客户ID信息汇总按照模型计算给出客户ID,是新建或使用已有客户ID。

  • 复杂模型算法,可应对复杂场景,安全性更高。
  • 对用户数据的准确性要求高。
  • 模型复杂、模型迭代和开发运维成本较高。

2-优先级策略:大部分企业使用此方案:按照前述的用户ID信息优先级来设置平台的客户ID实现策略。优先级策略的好处:

  • 依赖识别信息容易获取,比如手机号、微信UnionID等。
  • 可满足大部分场景。只要业务对数据误差可容忍,如每年不超过20例的用户数据误差。
  • 可快速实现、成本低。

3. 优先级策略的处理规则与逻辑

基本规则:

  • 使用高优先级ID值进行匹配。
  • 所有ID值只能保留在1个用户上,不可重复。
  • 更新数据到最早的用户信息上。

处理逻辑图:

4. 用户OndID服务

作为公共服务,供所有业务中心/应用端调用:

前端呈现上,面向一般业务用户只呈现有手机号的用户,而对于用户运营人员,要呈现全部用户,即包括类似只有微信Unionid或openid的用户。

专栏作家

王建儒,微信公众号:王建儒营销数字化,人人都是产品经理专栏作家。20年大汽车/大房产等行业数字化转型、研产供+营销服数字化平台规划建设与运营经验,聚焦B2B2C模式的营销数字化、新零售C2M/OTD、全域数字化运营。曾任新能源车企产品总监、科技公司CPO、用户运营与C端产品负责人、IT负责人、CRM资深专家,甲乙方经历。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

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