过去十年，汽车行业的利润结构正在发生一次根本性的迁移。卖车这件事，越来越像"获客"，而不是"终点"。

一辆车的成交均价在降，但一个车主在全生命周期里能贡献的价值却在涨——保养、保险、金融、二手车置换、充换电服务、OTA 升级付费、周边生态消费……这些钱不是一次性收完的，而是需要在未来 5 到 8 年里，持续地、精准地触达这个用户。

这恰恰是私域运营的核心逻辑：把一次性的买卖关系，变成长期的服务关系。

有句话说，传统车企卖完车就"失联"了，新势力卖完车才刚开始"谈恋爱"。这句话虽然粗糙，但点出了本质差异——用户关系的持续经营能力，正在成为车企的核心竞争力。

问题是，“做私域"这三个字说起来轻巧，落到技术架构层面，是一整套复杂的系统工程。APP、小程序、企业微信、官网、线下门店、DMS（经销商管理系统）……每一个触点都在产生用户数据，但每一个触点的背后又往往是不同的供应商、不同的数据库、不同的用户 ID 体系。

这篇文章想做的事情是：从车企用户运营岗的 JD（职位描述）出发，倒推出一套完整的私域技术架构，逐层拆解数据归一、会员体系、SCRM 集成和数据中台的实现方案。

从 JD 倒推架构：用户运营岗到底需要什么技术底座

打开任意一个招聘平台，搜索"车企用户运营”，你会发现近两年的 JD 发生了明显的变化。

几年前，这类岗位的要求大多围绕"活动策划"“社群运营"“内容编辑"这些偏市场的技能。但现在，越来越多的 JD 开始出现这样的关键词：

这些要求不是随意堆砌的。把它们串起来，恰好对应了一个完整的技术架构分层：

1. 数据采集层：APP、小程序、企微、官网、DMS 等多端触点的数据接入
2. 数据归一层：OneID 体系，把不同渠道的匿名用户和实名用户合并为同一个人
3. 数据建模层：用户标签体系、行为序列、偏好模型
4. 业务引擎层：会员等级、积分、权益、优惠券等规则引擎
5. 触达执行层：SCRM 的 SOP 自动化、企微消息推送、小程序模板消息
6. 分析决策层：数据看板、漏斗分析、LTV 预测

换句话说，一个"用户运营"岗位的背后，实际上需要一整套数据中台来支撑。这不是运营一个人能搞定的事，而是需要产品、技术、数据团队协同完成的系统工程。

理解了这一层，才能真正理解后面所有的架构设计决策。

三触点统一数据模型：OneID 是怎么炼成的

车企私域最常见的三个触点是：品牌 APP、微信小程序、企业微信。用户在这三个场景下的行为模式完全不同：

• APP：深度使用，查看车况、远程控制、充电管理、社区互动
• 小程序：轻量交互，预约试驾、活动报名、到店核销
• 企微：1 对 1 或社群沟通，售后咨询、活动通知、销售跟进

每个触点的背后，都有一个独立的 ID 体系：

如果各用各的 ID，同一个用户在 APP 里是"张三”，在小程序里是 openid_xxxxx，在企微里是 external_userid_yyyyy，在 DMS 里是客户编号 20230001——系统完全不知道这些是同一个人。

OneID 的核心思路：ID-Mapping

OneID 的本质是一张映射表，它不替代各个系统的原始 ID，而是在它们之上建立一个统一的映射关系：

1
2
3
4
5
6
7

OneID: U_2024_00385
├── app_user_id: 186xxxx9999 (手机号)
├── device_id: A1B2C3D4E5
├── wechat_unionid: oU_xxxxxxx
├── wecom_external_id: wo_xxxxxxx
├── dms_customer_id: BJ_2023_0088
└── website_cookie: ck_abcdef

这张映射表的构建，通常依赖几个关键的"连接点”：

手机号是目前车企场景中最强的连接标识。APP 注册要手机号，小程序授权可以拿手机号（通过微信手机号快速验证组件），企微添加好友后销售会要求留电话，DMS 系统里也必然记录手机号。所以手机号是天然的"主键候选"。

微信 unionid 是第二强的连接点。只要小程序和公众号绑定在同一个微信开放平台账号下，unionid 就是唯一的。它可以把用户在小程序、公众号、企微（企业关联的开放平台账号下）的行为串联起来。

设备指纹作为补充。在用户还没有登录或授权的匿名阶段，设备指纹（device_id + IP + User-Agent 等组合）可以用来做弱匹配，等用户后续登录后再合并。

ID-Mapping 的技术实现要点

在实际落地中，ID-Mapping 有几个容易踩坑的地方：

第一，合并时机。不是等到数据全部到齐了再做映射，而是每产生一个新的 ID 关联事件就实时更新。比如用户首次在小程序里授权了手机号，这一刻就应该触发一次 mapping 合并操作。

第二，冲突处理。同一个手机号可能被两个人先后使用（虽然概率很低），或者同一个企微 external_userid 在不同员工那里对应了不同的微信账号。这些冲突需要有明确的优先级规则和人工兜底机制。

第三，隐私合规。手机号属于个人敏感信息，在存储和传输过程中必须加密（通常使用 AES-256 或 SHA-256 加盐哈希），并且需要在用户注销时能够彻底清除关联数据。

一个成熟的 OneID 系统，合并准确率通常要做到 95% 以上。剩下的 5%，宁可漏合（两个 ID 没被识别为同一个人），也不要错合（把两个人合成一个人），因为错合会导致严重的隐私事故——比如把 A 的车况信息推送给了 B。

会员体系设计：等级、积分、权益的技术实现路径

有了 OneID 之后，下一步是在统一的用户身份之上构建会员体系。车企的会员体系和电商不同，它不是围绕"高频交易"设计的，而是围绕"低频高价值事件"设计的——买车、保养、保险、置换，每一件都是大决策、长周期。

等级体系：从"买车"到"终身"

车企常见的会员等级设计遵循"生命周期进阶"模型：

技术实现上，等级引擎的核心是一个规则计算服务，它需要定期（通常是每天凌晨批量跑 + 实时事件触发双模式）根据用户的行为和消费数据重新计算等级。

关键设计点：

• 升降级规则要可配置：运营团队需要能灵活调整升降级的阈值和条件，不能每次改规则都要开发发版。
• 等级保护期：为了防止用户刚降级就收到降级通知造成体验落差，通常会设置 3-6 个月的保护期，期间等级只升不降。
• 等级与权益的解耦：等级是"身份"，权益是"能力"。同一个等级在不同地区、不同时期可以挂不同的权益包，二者通过配置中心关联，不要硬编码。

积分引擎：不只是"消费返积分"

车企的积分体系比电商复杂得多，因为积分的"获取场景"和"消耗场景"都非常多样：

获取场景：

• 签到、发帖、评论等日常活跃行为
• 完成保养、续保等消费行为
• 推荐好友试驾或购车（高积分奖励）
• 参与品牌调研、活动反馈

消耗场景：

• 商城兑换（车品、周边、联名产品）
• 充电 / 换电抵扣
• 服务抵扣（洗车、代驾、延保）
• 抽奖活动

技术层面，积分引擎的核心是一个事务型账本系统：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

积分账户 {
  user_id: OneID
  balance: 当前可用积分
  frozen: 冻结积分（已下单未核销）
  total_earned: 累计获得
  total_spent: 累计消耗
}

积分流水 {
  transaction_id: 唯一流水号
  user_id: OneID
  type: earn | spend | expire | adjust
  amount: 变动数量
  reason: 触发原因编码
  source: 来源系统
  created_at: 时间戳
}

积分系统最忌讳的是"对不上账"。每一笔积分的增减都必须有对应的流水记录，且流水不可篡改。这在技术上通常用"只追加日志"的模式来实现，类似于简化版的区块链思路——所有变更都是 append-only 的，修改只能通过新增一笔冲正记录来完成。

权益中心：让运营团队自己配

权益是会员体系的"肉"，等级是"骨架"。一个好的权益中心应该让运营团队能够：

1. 创建权益项：比如"免费洗车券"“充电 8 折卡"“代驾服务券”
2. 配置发放规则：比如"金卡会员每月自动发放 2 张洗车券”
3. 设置有效期和使用条件：比如"限 30 天内使用，仅限合作门店"
4. 追踪核销情况：发了多少、用了多少、过期了多少

这本质上是一个规则引擎 + 券码系统的组合。规则引擎负责"什么时候给谁发什么"，券码系统负责"券的生成、发放、核销、过期"的生命周期管理。

SCRM 集成：企微 + 微盛的数据流与自动化 SOP

SCRM（Social CRM）是车企私域运营中"执行层"的核心。它的角色是：把数据中台里的用户洞察，翻译成一线销售和客服每天在企微里执行的具体动作。

数据流架构

以企微 + 微盛 SCRM 为例，一个典型的数据流是这样的：

1
2
3
4

[企微 API] ──→ [SCRM 系统] ──→ [CDP / 数据中台]
      ↑              ↑              │
      │              │              ↓
      └── 标签回写 ←── 策略引擎 ←── 用户画像

具体来说：

1. 数据上行：企微 API 把客户的聊天记录摘要（合规范围内）、好友关系变更、群聊变动等事件推送到 SCRM。SCRM 把这些事件连同客户的基础信息一起上报到 CDP。

2. 画像计算：CDP 根据全渠道数据更新用户画像和标签。比如一个用户最近在 APP 里频繁查看充电桩安装服务，CDP 会给这个用户打上"充电桩潜在需求"标签。

3. 策略下发：策略引擎检测到某个用户满足特定条件（比如"购车满 11 个月 + 未预约保养 + 近期打开过 APP"），生成一个"保养提醒"SOP 任务，推送到 SCRM。

4. 执行触达：SCRM 把这个任务分配给对应的企微员工（通常是专属服务顾问），员工在企微侧边栏看到推荐话术和客户画像，一键发送保养提醒。

标签体系设计

车企 SCRM 的标签体系通常分三层：

基础属性标签（静态）：

• 车型、购车日期、所在城市、经销商
• 性别、年龄段、职业（来源于注册信息）

行为标签（动态，基于规则）：

• 近 30 天 APP 打开次数 ≥ 10 → “高活跃用户”
• 最近浏览了 SUV 车型页 → “换车意向”
• 社群中提问过保险问题 → “保险需求”
• 推荐好友留资 → “KOC 潜力”

预测标签（模型产出）：

• 续保概率：高 / 中 / 低
• 增换购概率：高 / 中 / 低
• 流失风险：高 / 中 / 低

标签不是越多越好。一个实用的标签体系，核心标签控制在 50-80 个，每个标签都有明确的业务含义和使用场景。那些"看起来很有科技感但其实没人用"的标签，只会增加计算成本和维护负担。

自动化 SOP：让系统推着人走

SOP（Standard Operating Procedure）是 SCRM 中最有杀伤力的功能。它的本质是：把运营专家脑子里的"最佳实践"编码成系统规则，让一线员工不需要动脑子也能执行到位。

一个典型的 SOP 例子——“新车交付后 30 天关怀”：

这个 SOP 的执行不需要服务顾问自己去记"第几天该干什么"，系统会在对应的时间点自动推送任务到企微侧边栏。顾问只需要点击"发送"或者按照建议话术执行即可。

技术实现上，SOP 引擎的核心是一个事件驱动的时间轮调度器：

• 触发器：监听特定事件（如"DMS 标记车辆已交付"）
• 条件判断：检查用户是否满足 SOP 的准入条件
• 时间线编排：按照预设的时间间隔生成一系列待执行任务
• 执行通道：自动任务走消息模板直接发送，人工任务推送到企微侧边栏

数据中台层：CDP 在车企场景的架构选型

CDP（Customer Data Platform，客户数据平台）是整个私域架构的"大脑"。它负责把分散在各个系统中的用户数据汇聚起来，形成统一的用户视图，并向上层应用提供数据服务。

车企 CDP 的核心能力要求

架构选型：自建 vs. SaaS

这是车企在做 CDP 时面临的第一个分叉路口。

SaaS 方案（如神策、GrowingIO、火山引擎等）：

• 优势：开箱即用，上线快，标签和人群圈选的 UI 做得比较成熟
• 劣势：数据存在第三方，车企对数据的控制力弱；定制化能力有限；长期成本可能很高（按用户量或事件量计费）
• 适用场景：中小型车企、新品牌冷启动阶段、技术团队人手不足时

自建方案：

• 优势：数据完全自主可控；可以深度定制车企特有的数据模型（如车辆生命周期、充电行为等）
• 劣势：建设周期长（通常 6-12 个月起步）；需要专业的数据工程团队
• 适用场景：大型车企集团、多品牌多经销商体系、对数据主权有强要求的场景

实际上，很多头部车企采取的是"混合路线"：用 SaaS 工具做前端的人群圈选和营销执行，但底层的数据仓库和 ID-Mapping 自己建。这样既控制了核心数据资产，又不用从零开发所有的上层应用。

技术栈参考

如果走自建路线，一个典型的车企 CDP 技术栈大致是这样的：

• 数据采集：APP/小程序用自研 SDK 或神策 SDK 做埋点上报；企微用官方 API + Webhook 做事件订阅；DMS 通过 CDC（Change Data Capture）工具做增量同步
• 实时计算：Kafka 做消息队列 + Flink 做实时流处理（行为事件实时入库、实时标签更新）
• 离线计算：Spark / Hive 做每日批量标签计算、人群圈选
• 存储层：ClickHouse 做 OLAP 分析、HBase / Redis 做用户画像实时查询、MySQL 做规则配置存储
• 服务层：Spring Cloud / Go 微服务提供 API 接口

这个技术栈不算新，但每一个组件在车企场景下都有需要特别注意的地方——比如车联网数据的实时性要求远高于普通行为数据，车辆告警事件需要在毫秒级被处理并触发通知。

常见坑：数据孤岛、隐私合规、渠道冲突

理论上的架构总是很完美，实际落地时，有几个坑几乎每家车企都会踩。

数据孤岛：经销商是最大的变量

车企的数据治理难度，一半来自于系统多，另一半来自于经销商体系的独立性。

大多数车企的经销商用的是独立的 DMS 系统，数据的所有权在法律和事实上都存在争议。经销商不愿意把客户数据完整地交给主机厂——因为客户数据是他们的命根子，交出去就意味着"客户跟我没关系了"。

这导致的现实问题是：主机厂的 CDP 拿到的 DMS 数据往往是"残缺"的。可能只有购车日期和车型，没有保养记录；可能只有手机号，没有完整的客户画像。

解决思路通常是两条路并行：

1. 利益绑定：主机厂通过"数据换资源"的方式激励经销商共享数据——比如共享完整保养记录的经销商可以获得更多的线索分配和营销补贴。
2. 技术兜底：在数据不完整的情况下，CDP 的 ID-Mapping 和标签引擎需要具备"缺失容忍"能力，不能因为某个渠道数据缺失就导致整个用户画像不可用。

隐私合规：车企是重灾区

汽车是一个天然涉及大量隐私数据的行业。你的车知道你每天去哪、停在哪里、开多快、听什么歌、打给谁电话。这些数据一旦被滥用，后果非常严重。

2021 年以来，《个人信息保护法》《汽车数据安全管理若干规定》等法规的出台，对车企的数据处理行为划定了明确的红线：

• 最小必要原则：只采集实现功能所必需的数据
• 明示同意：每一项数据的使用都需要用户的明确授权，不能一揽子同意
• 数据出境限制：智能网联汽车的数据原则上不得出境
• 人脸和地理位置：属于敏感个人信息，需要单独同意

在技术实现上，这意味着：

• CDP 需要内置同意管理模块，记录每个用户对每类数据的授权状态
• 标签计算引擎需要检查用户是否授权了对应数据的使用
• 数据导出和 API 调用需要有严格的审计日志
• 用户发起"删除我的数据"请求时，系统需要能够在所有下游系统中级联删除

合规不是"做了就行"的事情，而是"要能证明做了"的事情。审计日志和合规报告的重要性，不亚于数据系统本身。

渠道冲突：线上和线下的博弈

私域运营的本质是把用户从"分散的公域"汇聚到"统一的品牌私域"。但在这个汇聚过程中，渠道之间的利益冲突不可避免。

最典型的冲突：线上渠道（APP / 小程序）和线下渠道（经销商）之间的客户归属问题。

用户在小程序上预约了试驾，应该算谁的线索？如果这个用户最终在经销商 A 处成交了，经销商 B 之前的线上跟进工作怎么算？用户加入品牌社群后，是品牌方直接运营还是分配给经销商运营？

这些问题没有标准答案，但技术架构需要为此预留灵活性：

• 客户归属规则可配置：支持"首次触达归属"“最近触达归属"“地理位置就近分配"等多种策略
• 数据可见性分层：品牌方看到全量数据，经销商只看到归属于自己的客户数据
• 运营动作的去重：同一个用户不能被品牌方和经销商同时发送相似的活动推送，需要有全局的消息频控和去重机制

把架构落到组织里

技术架构再好，如果组织不匹配，也落不了地。

车企做私域，最常见的组织困境是：IT 部门建了系统，市场部门负责运营，销售部门管着经销商，客服部门处理投诉——四个部门各管一段，没有人对"用户全生命周期体验"负责。

一些走在前面的车企已经开始设立用户运营中心，作为一个横向拉通的部门，统一管理 APP、小程序、企微、社群的运营策略，并且有权限调动 IT 资源和经销商资源。这个部门的负责人通常直接向 CEO 或 CMO 汇报。

技术团队在这个组织中的角色，不是"接需求做开发"的乙方，而是"定义数据能力边界"的合伙人。因为只有技术团队最清楚，哪些运营策略在当前的数据基础上能落地，哪些需要先补齐数据能力。

私域运营对车企来说，不是一场短期战役，而是一次商业模式的深层转型。从"卖完车就结束"到"卖完车才开始”，这背后需要的不只是一个 APP 或一个企微账号，而是一整套以用户为中心的数据基础设施。

OneID 解决"认识你"的问题，会员体系解决"留住你"的问题，SCRM 解决"服务你"的问题，CDP 解决"理解你"的问题。这四层加在一起，才构成了车企私域的完整技术底座。

架构不是一天建成的。但方向一旦明确，每一步的投入都会在用户生命周期价值的增长中得到回报。关键是，别等到竞争对手已经跑通了再来补课。

📝 本文首发于 文艺技术笔记，更多技术文章欢迎访问。