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

推荐订阅源

Engineering at Meta
Engineering at Meta
Microsoft Azure Blog
Microsoft Azure Blog
I
InfoQ
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
人人都是产品经理
人人都是产品经理
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tailwind CSS Blog
MongoDB | Blog
MongoDB | Blog
Google DeepMind News
Google DeepMind News
WordPress大学
WordPress大学
量子位
美团技术团队
大猫的无限游戏
大猫的无限游戏
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Last Week in AI
Last Week in AI
博客园 - 司徒正美
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
小众软件
小众软件
C
Check Point Blog
博客园 - 三生石上(FineUI控件)
N
Netflix TechBlog - Medium
Recent Announcements
Recent Announcements
有赞技术团队
有赞技术团队
月光博客
月光博客

人人都是产品经理

为什么你的产品找不到差异化?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协议

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