团 体 标 准
T/CCSA 560—2024 T/CAAAD 013—2024
数字营销技术 客户数据平台技术要求
Digital marketing technology - Technical requirements for customer data platform
2024 - 07 - 03 发布 2024 - 10 - 01 实施
中国广告协会 中国通信标准化协会 发 布
T/CCSA 560—2024 T/CAAAD 013—2024
前 言
本文件按照GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中国广告协会和中国通信标准化协会共同提出，并分别归口。
本文件起草单位：悠易互通(北京)广告有限公司、中国信息通信研究院、上海亦拓广告有限公司、上海源犀信息科技有限公司、国家广告研究院、北京国双科技有限公司、上海嗨普智能信息科技股份有限公司、北京腾云天下科技有限公司、秒针信息技术有限公司、上海驰骛信息科技有限公司、华扬联众数字技术股份有限公司、武汉卓尔数字传媒科技有限公司。
本文件主要起草人：李旸、杨正军、朱岩、马良骏、郑超、夏军、林宗平、顾明毅、杨阳、黄腾、杜蓓、闫辉、邵真奇、张姣、唐旭、刘崴、夏琨。
引 言
近年来，数字营销技术越来越流行。客户数据平台CDP的出现，为营销人员提供了以往数据管理工具无法实现的独特功能，因此人们对CDP类别的兴趣也开始急剧增长。客户数据平台CDP可以从多种类型的客户相关系统中提取数据(如客户关系管理、社交媒体、电子商务、内容素材、短信和邮件等)，灵活地整合和分析数据，并向外部系统导出数据。CDP作为更广泛、更集中的客户数据管理解决方案， 旨在与其他平台协同工作，从而为品牌提供服务，提高综合营销能力。
数字营销技术 客户数据平台技术要求
1 范围
本文件规定了客户数据平台的功能要求、接口要求、安全要求等内容。
本文件适用于客户数据平台在数据采集、处理、分析、营销等各个环节中涉及到的数据交换、使用和存储活动。其他领域的相关活动也可以参照本标准进行。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 41479-2022 信息安全技术 网络数据处理安全要求
GB/T 35273-2020 信息安全技术个人信息安全规范
GB/T 22239 信息安全技术—网络安全等级保护基本要求
3 术语和定义
下列术语和定义适用于本文件。
3.1
客户 customer
客户(顾客)是数据平台CDP的数据主体，是一个自然人的消费者用户以数据形式表现在系统中。在不同的行业或系统中，有可能被称为顾客、个人、用户、消费者、联系人、线索等等。
3.2
客户数据平台 customer data p latform
是指企业掌握的跨系统管理和运营用户数据的平台，提供顾客数据和用户授权数据的集中采集与整理，加强数据协同和数据流动和数据驱动的广告营销决策，提升企业的信息处理和数字营销技术能力的数据平台。文中也称为“系统 ”。
3.3
品牌/品牌主 brand owner
购买或使用CDP的企业主体，通常是CDP厂商的客户，但因为本标准是关于客户数据平台，所以将其称为“ 品牌 ”或“企业 ”。
3.4
触点 touch point
触点是指信息、服务和体验能触达用户的方式，在不同系统中可能被称为“渠道 ”、“连接 ”、“第三方应用 ”。比例如公众号、微信社群、小程序和企业微信等所有互联网接触到用户其他平台触达方式。触点包括潜在需求用户在购买前、购买中和购买后的商品/品牌接触点，简称触点。广义触点已经超越了传统广告范畴，加入了用户社群、评价和搜索等，还有电商渠道的广告与直接商品数字展示与体验空间，以及数据营销和忠诚计划保持顾客对品牌价值的积极关系，主要通过私域流量触达，线下门店和人员触达也都属于触点。触点例子如附录A表A.1所示。
3.5
身份 ID identity
身份ID是指客户在某个触点里面的标识，比如在某个品牌官网里面的客户身份就是一个个的浏览官网的匿名用户、或登录用户。一般来说，一个客户在一个触点中可能有1-N种身份ID，例如手机号、登录账号等;来自不同触点的身份ID可以用于合并客户，例如来自不同触点获取的手机号。
3.6
客户标签 customer label/tag
对某项客户特征的描述。客户标签需要按照用户信息和顾客画像来处理生成，已生成客户标签可以不用附载个人信息;另外，使用群体画像也可以产生客户标签。数字营销领域中的客户标签，是指通过一定的数据加工逻辑产出，能够为业务所直接使用的可阅读、易理解、有业务价值的数据知识。多层级客户标签例子如表B.1所示。
3.7
行为事件 behavioral event
客户与品牌交互的行为，因为是发生过不可改变的行为，所以通常用“事件 ”的形式记录。在有些系统中也被称为“ 日志 ”。行为事件例子如表C.1所示。
3.8
业务对象 business object
CDP的数据是以客户为中心进行组织的，仅记录行为事件这使得数据结构变得简单，但可能限制了存储可更新的业务对象的能力，例如订单退单后将原订单删除。业务对象使得CDP可以包含使用如订单等对象的预置功能，因为订单有加入购物车、付款、收货、退款等多种状态，而如果记录为事件会重复记录，所以通常会用单独的“订单 ”实体更新订单的各种状态，可以正确的计算订单总金额。业务对象也可以简化外部数据到CDP的映射，以及外部系统对CDP数据的访问。在不同系统或行业中可能被称为“订单 ”、“交易 ”、“保单 ”等。业务对象例子如表D.1所示。
3.9
统一客户身份 oneID
在CDP中通过对用户身份 ID 的识别、合并、去重，形成的映射为一个自然人的统一唯一ID。通常获得合法授权客户或用户许可，为数据记录到的客户或用户配备统一记录编号，用以识别客户或用户。
3.10
客户画像 customer persona/ profile
是指通过为客户和潜在客户设置多个分类和标签，将可以更好地对该名客户需求识别和目标定位。如果为多位客户设置了不同的标签，企业就拥有了细分客户群体的能力。
3.11
群组 group/cohort/segment
群组是客户的集合，用于批量处理客户。在不同系统中可能被称为“人群 ”、“群体 ”等。
3.12
元数据 metadata
元数据是定义数据的数据，例如年龄可能是0-100岁，年龄的元数据则为“整数 ”。在CDP中，因为要用一套系统满足不同行业的不同客户需求，所以需要为用户、事件等关键数据定义元数据，满足可配置的需求。
3.13
私有化/私有化部署 on-premise
包括CDP在内的软件系统的一种交付方式，通常计算、存储等硬件资源是独占的，需要由客户企业自己提供，由企业服务器管辖。
3.14
操作员 operator
使用CDP等数字营销技术的个人，通常是品牌的员工。
4 缩略语
下列缩略语适用于本文件。
API：Application Programming Interface(应用程序接口)
CDP：Customer Data Platform(客户数据平台)
ID：Identity(身份标识)
SDK：Software Development Kit(软件开发工具包)
5 概述
CDP应包含以下部分：数据模型、身份ID映射、客户画像、数据分析;数据可以通过接口，基于数据模型来输入和输出CDP;整个系统是建立在安全的环境之上的。总体架构如下图1所示：
图 1 CDP 标准总体架构
6 功能要求
6.1 数据模型要求
6.1.1 数据模型综述
数据模型是CDP的基础，将上层数据业务模型与底层数据存储模型隔离， 以适配各种上层业务。数据输入、输出的接口均需要依赖于数据模型的定义。如图2所示。
图 2 CDP 数据模型
6.1.2 数据类型要求
数据模型中的字段应支持以下几种常见数据类型，不同的类型对于之后的客户画像、数据分析等功能有不同应用，如表1所示。
表 1 常见数据类型
6.1.3 客户模型要求
6.1.3.1 客户身份 ID 模型要求
一个身份ID，是一个客户在一个触点的某一种身份类型的数字体现，可用于识别客户，也可以与已有的客户合并。身份ID数据模型图如图3所示。
图 3 身份 ID 数据模型
客户身份ID模型需要符合下列规则。
a) 应支持不同的身份 ID 类型，如手机号、邮箱、Open ID、Union ID 等;
b) 应支持同一个客户有多种身份 ID 类型;
c) 应支持同一个客户的同一个身份 ID 类型，在不同的渠道有相同的身份 ID，例如在网站、小程序有同样的手机号;
d) 应支持同一个客户的同一个身份 ID 类型，在相同的渠道有不同的身份 ID，例如在网站注册时使用了手机号 A，在领取会员卡时使用了手机号B;
e) 应支持同一个客户在同一个触点有多个身份类型的 ID;
f) 应支持通过多种方式输入身份 ID 数据，包括新建客户、对已有客户更新身份 ID、行为事件或业务对象中附带身份 ID 等。
6.1.3.2 客户标签模型要求
多层级客户标签例子参见附录B表B.1。客户标签模型需要符合下列规则。
a) 应支持预置标签，如性别、年龄等;
b) 应支持自定义标签，品牌商可以根据其业务需求自定义个性化标签;
c) 应支持基于客户、行为事件、业务对象等数据计算复合标签;
d) 宜支持标签的生命周期管理，可以启用、停用、删除标签;
e) 宜支持标签的查询和详情展示，例如标签层级的树状展示、标签客户数的分布等;
f) 应支持对同一个客户，有 1000 个以上的标签;
g) 应支持当有新的数据输入时相关标签实时更新。
6.1.4 行为事件模型要求
行为事件例子参见附录C表.1。行为事件模型需要符合下列规则：
a) 应不可变更， 以发生时的数据为准;
b) 应支持预置行为事件;
c) 应支持自定义行为事件，以及其包含的事件属性;
d) 行为事件应可跨触点，例如品牌商的网站 A 和小程序 B，应可支持同样的“领取卡券 ”行为事件;
e) 应保存 1 年以上， 以支持年度同比的行为事件数据分析。
行为事件的参数如表2所示：
表 2 行为事件参数
6.1.5 业务对象模型要求
业务对象例子参见附录D表D.1。业务对象模型需要符合下列规则。
a) 应支持与客户相关的业务对象，如“客户 ”的“订单 ”;
b) 应包含“业务对象 ID ”的参数，多条有同一“业务对象 ID ”的数据记录进入系统时，最后一条会覆盖之前的记录;
c) 与行为事件模型一样，应支持触点类型、触点、客户身份 ID 类型、客户身份 ID、时间戳参数;
d) 与行为事件模型一样，应支持预置属性和自定义属性;
e) 宜支持业务对象间的多层关系，如“订单头 ”与“订单行 ”的 1 对 N 关系;
f) 应支持实时更新。
6.2 身份 ID 映射要求
6.2.1 身份 ID 管理要求
身份ID管理需要符合下列规则。
a) 宜查看客户身份类型的列表，添加或删除客户身份的类型;
b) 宜停用或启用某种身份类型进行客户合并。停用时，系统不会将此身份类型的 id 包含在客户合并计算中，只会处理其他类型 ID。启用时，系统将此身份类型的 id 与其他类型 ID 一起进行客户合并计算;
c) 宜展示客户关联的身份 ID 列表和客户身份合并日志;
d) 宜通过权限对象管理系统操作员是否可以进行以上各操作;
e) 宜记录操作员进行以上各操作的日志;
f) 应支持存储 1 亿以上的身份 ID 数量，以满足品牌方对大数据量的需求;
g) 应存储身份 ID 1 年以上， 以便与历史上的客户进行合并。
6.2.2 身份 ID 识别合并要求
身份ID识别合并的流程参见下图4。
图 4 身份 ID 识别合并流程身份ID识别合并需要符合下列规则。
a) 应支持触点内识别合并，CDP 应在单个触点内使用客户的身份信息进行识别，例如使用小程序A 的客户 a 的 open Id 作为身份识别 ID，以更新客户的身份和标签信息;
b) 应支持跨触点识别合并，CDP 应能够识别多个连接上的同一客户，并将这些连接上的标识合并为一个客户。例如，通过手机号将官网A1 的客户 a1、小程序A2 的客户 a2、小程序A3 的客户 a3 合并为客户 a;
c) 宜支持查看身份 ID 的识别合并历史日志;
d) 宜支持手动合并，即指定同一类型的两个身份 ID，合并为同一客户的统一身份 OneID。
6.3 客户画像要求
6.3.1 单个客户画像要求
CDP中可以准确的识别出单个客户，所以也可以查看单个客户的详细画像。单个客户画像需要符合下列规则。
a) 应展示客户的个体画像，包括其身份 ID、客户标签、群组、事件、业务对象等信息;
b) 应支持通过身份 ID、标签查找筛选出客户;
c) 宜根据事件时间戳倒序展示客户历史上发生过的事件时间轴。
6.3.2 群组圈选要求
群组圈选指生成一个客户的集合用于营销或分析，例如一个营销活动需要圈选目标受众群组。群组圈选需要符合下列规则。
a) 应支持基于客户的标签、行为事件、业务对象等字段的交、并、差的条件组合来圈选;
b) 应支持基于是否在已有群组的条件组合来圈选;
c) 对于条件中的各个数据类型的字段的要求为：
1) 对于字符串型字段，应支持等于、不等于、包含、不包含、空值、非空的条件选项;
2) 对于整数型、数字型字段，应支持等于、不等于、大于、小于、区间、空值、非空的条件选项;
3) 对于布尔型字段，应支持等于、不等于、空值、非空的条件选项;
4) 对于日期、 日期时间型字段，应支持绝对时间区间、绝对时间前后、相对时间(即相对于计算圈选的时间)区间、相对时间前后、空值、非空的条件选项;
d) 对于行为事件，应支持选择“发生过 ”或“未发生过 ”，宜支持行为事件序列的条件;
e) 应支持多个群组同时进行圈选计算;
f) 群组圈选计算应在 24 小时内完成;
g) 宜支持单次手动或定时自动更新群组， 自动更新可支持更新频次、时间段的选择;
h) 宜支持不基于条件组合、而是手动将多个客户圈选为群组;
i) 宜支持通过近似计算预估群组的人数。
6.3.3 群组管理要求
群组管理需要符合如下规则。
a) 应支持群组列表的展示和搜索，应支持展示群组的客户数、创建时间、最近更新时间等关键字段;
b) 应支持群组的复制、编辑、删除等操作;
c) 因为群组圈选计算时间往往较长，群组状态应支持开始计算、计算中、计算完成等多种状态;
d) 应支持展示、导出群组内的客户列表。
6.3.4 群组画像要求
群组画像能够通过多种维度描述一个群组内客户的分布情况，并通过可视化方式直观呈现。群组画像需要符合如下规则。
a) 应支持按客户标签展示群组内客户数的分布;
b) 宜支持按多个客户标签的组合展示群组内客户数的分布;
c) 宜支持按发生行为事件的次数展示群组内客户数的分布;
6.4 数据分析要求
6.4.1 数据分析综述
数据分析需要符合如下规则。
a) 应支持对 CDP 中的数据模型做数据分析，例如客户数据分析;
b) 应支持在 30 秒内展示出数据分析的结果、或提示转入离线分析，宜支持预计算、缓存等技术手段来加速展示;
c) 应支持权限管理，使品牌商的不同部门、操作员只能查看、管理其有权限的数据分析报表。
6.4.2 客户数据分析要求
客户数据分析需要符合如下规则。
a) 应支持以客户的总数作为指标， 以客户标签作为维度和筛选条件;
b) 应支持选择多个群组以进行对比分析;
c) 宜支持以客户的新增数、流失数作为指标。
6.4.3 行为事件数据分析要求
行为事件数据分析需要符合如下规则。
a) 应支持设置事件指标：应支持一个或者多个指标，指标应可选择事件的总次数、人均次数、事件字段的去重数、整数/数字型事件字段的总和/均值/最大值/最小值，宜支持多个指标间的四则运算;
b) 应支持设置事件时间筛选条件：应支持按绝对时间区间、相对时间区间作筛选条件，宜支持不少于 1 年的时间范围;
c) 应支持设置筛选条件：应支持以客户标签作为筛选条件，应支持以指标中行为事件的事件属性作为筛选条件;不同数据类型的客户标签和事件属性支持的操作符同“6.3.2 群组圈选要求 ”，应支持一个或多个触点作为筛选条件，应支持多个条件的组合;
d) 应支持设置分析维度：应支持一个或多个分析维度;应支持通过客户标签、所选指标的共同事件属性作为分析维度;
e) 应支持按一个或多个群组作对比;
f) 宜支持按时间范围，与所设置的事件时间筛选条件做对比。
除了标准的行为事件数据分析外，CDP还宜支持以下高级分析模型：
a) 转化漏斗分析：分析一个多步骤过程中每一步的转化与流失情况，例如分析客户购买商品完成流程转化漏斗分析;
b) 分布分析：分析某一事件指标分布的区间内有多少去重客户数，例如最近 7 天订单平均金额在 0-1000 元、1000-2000 元、2000 元以上的客户数量;
c) 留存分析：分析客户从初始行为到后续行为的留存情况，从某个客户群体的初始行为时间来计算，统计发生了某个行为的群体，在后续一段时间内发生期望行为的人数;
d) 路径分析：对客户在 APP 或网站中的访问行为路径进行分析。为了衡量网站优化的效果或营销推广的效果，以及了解客户行为偏好，时常要对访问路径的转换数据进行分析;
e) 归因分析：通过归因分析模型来分析待归因事件(广告位点击、推广位点击)对目标转化事件(支付订单等) 的贡献。分析模型包括但不限于：首次触点归因、末次触点归因、线性归因、时间衰减归因、位置归因;
f) 间隔分析：对事件间的时间间隔进行分析，分析行为事件的时间间隔分布情况。
6.4.4 数据分析可视化要求
数据分析可视化需要符合如下规则：
a) 应支持以图表方式展示数据总量、增量、分布情况;
b) 应支持折线图、柱状图、饼图、数字、表格等多种常见可视化展示方式，宜支持不同图表格式间的切换，宜支持图表、表格的下载;
c) 应支持将可视化图表添加到仪表盘中，形成多个图表的组合，宜支持调整仪表盘内图表的大小布局， 以及仪表盘的下载;
d) 当维度有多个值时，宜展示各个维度所占的百分比。
7 接口要求
7.1 数据输入接口要求
7.1.1 数据输入综述
数据输入需要符合如下规则：
a) 应支持输入符合“6.1 数据模型要求 ”的数据。
b) 应支持将源数据映射到预置字段例如姓名或电子邮件、或者映射到自定义字段;
c) 客户数据输入应支持 1000 万条/天的处理量;
d) 行为事件数据输入应支持 1 亿条/天的处理量。
7.1.2 数据输入的方式要求
a) 应支持开放API，适用于一次性或周期性地批量输入数据的需求，应提供配套的API文档;
b) 应支持导入文件，如 CSV 格式：
1) 应支持在界面上手动导入，应支持异步导入以适配较大的文件;
2) 应支持 SFTP 协议，由品牌商提供 SFTP 服务器，系统定期从服务器读取文件;
3) 导入完成后应显示成功、失败的数据量;
c) 应支持触点数据输入：
1) 应支持触点的 Basic, API Key, Bearer Token, OAuth 等基础的认证方式;
2) 应支持触点的API签名规则，以防止重复提交;
3) 应支持主动调用触点的开放API;
4) 应支持接受触点的 Webhook 推送实时数据，并应支持发送相应的回执;
d) 宜支持通过 SDK 埋点的数据输入：
1) 应支持 Web JavaScript、小程序、iOS、Android 等多种平台的 SDK;
2) 无代码埋点时，应通过设备标识符匿名化生成客户身份 ID;
3) 无代码埋点时，应自动产生预置事件(例如访问网页、点击页面元素等)，应支持 5000次/秒的数据输入;
4) 代码埋点时，应支持输入客户模型、行为事件模型、业务对象模型的相关数据;
e) 在品牌商的私有化环境部署时，宜支持从以下数据源输入：云原生存储(BLOB 等)、常用存储中间件(Kafka、HDFS 等)、数据库(MySQL 等)数据环境。
7.2 数据输出接口要求
7.2.1 数据输出的方式要求
CDP数据输出的方式需要符合如下规则。
a) 应支持开放API，适用于一次性或周期性地批量输出数据的需求，应提供配套的API文档;
b) 应支持输出文件，如 CSV 格式：
1) 应支持在界面上手动导出下载，应支持异步下载以适配较大的文件;
2) 应支持 SFTP 协议，由品牌商提供 SFTP 服务器，系统将文件传输到服务器;
3) 文件生成完成后宜通知操作员，并在系统中保留 1 天以上;
c) 应支持 Webhook 推送， 以支持实时将 CDP 数据推送到外部触点，应支持 HTTPS 协议;
d) 宜支持订阅消息队列，如 Kafka，以支持在私有化环境中实时导出数据;
e) 宜支持数据库查询，如 JDBC 连接，以支持在私有化环境中非实时地导出大量数据。
7.2.2 数据输出的内容要求
CDP数据输出的内容需要符合下列规则。
a) 应支持输入到 CDP 的各项数据，如客户(身份 ID、标签)、行为事件、业务对象;
b) 应支持通过条件筛选输出的数据;
c) 应支持输出 CDP 中身份 ID 映射产生的统一身份 OneID;
d) 应支持输出在 CDP 中圈选出的群组数据：选择一个群组，导出其内的所有客户的数据。
8 安全要求
8.1 系统安全
系统安全需符合下列要求：
a) 平台应采用安全网络设备保证平台系统的硬件层安全，如路由器、交换机、防火墙、入侵检测系统等。
b) 应关闭非必要的业务数据(外部)接口以保证接口安全，应支持接口访问的授权验证和来源验证。
c) 应支持不同账户的分级和最小必要权限授权管理，如管理员、运维人员、访客等，根据不同等级账户需要应具有不同的管理权限。
d) 应具备系统漏洞修复能力，不应含有 6 个月上的 CNVD,CNNVD 高危及以上漏洞。
e) 应具有安全报警、安全审计、 日志记录功能， 以保证各操作行为的可追溯性。
f) 应具有更新功能，更新时应能够对更新来源进行鉴别，并对更新文件进行完整性校验。
g) 平台宜符合 GB/T 22239 三级要求。
8.2 通信安全
接口安全需符合下列要求：
a) 应采用双向身份认证技术保证平台各接入方的身份合法性。
b) 应采用安全通信协议保证平台各计入方的通信安全，如 1.2 及以上版本 TLS 等。
c) 应采用密码技术保证通信中关键数据的保密性和完整性等。密码算法应符合相关国家标准和行业标准的要求，宜使用商用密码算法，不应使用已被证实存在安全风险的密码算法。
8.3 数据安全
平台数据处理应符合GB/T 41479-2022相关要求，对平台中涉及到个人信息处理的应符合GB/T 35273相关要求。对数据和个人信息处理中采用的密码技术应符合相关国家标准和行业标准的要求，宜使用商用密码算法。
附 录 A (资料性)触点例子
触点例子如表A.1所示
表 A.1 触点类型和举例
附 录 B
(资料性)
多层级客户标签例子
多层级客户标签例子如表B.1所示
表 B.1 多层级客户标签例子
附 录 C (资料性)
行为事件例子
行为事件例子如表C.1所示。
表 C.1 触点类型和行为事件
附 录 D (资料性)
业务对象例子
业务对象例子如表D.1所示。
表 D.1 业务对象和例子业务对象：订单
评论