作者
在本文中，我们将解释 ID 协调所面临的挑战，并展示我们在客户 Data 平台中创建统一配置文件 ID 的方法，特别是...
Data 是通过离线 Data 仓库和在线网站跟踪收集的。.
客户 Data 平台
客户 Data 平台 (CDP) 允许企业以统一和集中的方式从各种来源收集、管理和分析客户 data。该平台 CDP 的目标 是通过汇总 data 的数据，为每个客户创建一个全面而统一的视图。 多接触点, 如网站、移动应用程序、社交媒体、电子邮件互动等。.
珍宝 Data
Treasure Data 是基于 cloud 的客户 Data 平台。以下是 Treasure Data 的一些常见业务用例：
身份核对
身份核对是在不同系统或 data 数据库中对与某人有关的 data 进行比较和匹配的过程，以确保准确性、一致性和对该人的统一认识。.
在多个系统或 data 信息源存储相同个人的信息，但 data 可能不完整或不一致的情况下，这一点尤为重要。.
身份核对的挑战
身份核对会遇到许多挑战，特别是在 data 集广泛、信息来源多样的情况下。这些挑战包括不一致的 data 格式、导致错误匹配的质量问题，以及因错误或系统更改导致的重复记录管理。. 主要挑战在于缺乏唯一的 ID 在不同的信息源、表格和 database 中代表用户。.
企业通过投资 Treasure Data 等先进的 data 工具来应对这些挑战。.
实施身份核对
我们使用 Treasure Data 统一功能为我们的一个客户实施了身份核对。在本文中，我们将分享我们的方法和实施逻辑。.
给定条件 在 CDP databases 中有一些表格，其中包含用户在网站上的访问信息，以及来自 data 仓库中 CRM（客户关系管理）database 的客户信息。.
目标 在每个 CDP 表中都有一个唯一的档案标识符。这样，我们就可以创建一个主细分市场，360 度全方位了解客户及其旅程。.
提供在线 data： 网站页面上的浏览量、网站上提交的表单、其他网站特定信息，如存储在单独表格中的产品页面详细信息。.
提供离线 data： CRM data 来自 data 仓库。.
创建唯一个人资料 ID 的步骤概览：
统一网络表格
为了统一 Web data，我们将利用 Treasure Data 统一功能的能力。这需要在 YAML 格式的配置中定义需要统一的源表和列。有关如何在 Treasure Data 中实现统一的分步指南可在以下网站找到 珍宝 Data 文档.
因此，它会在每个表中创建统一 ID。规范 ID 的目的是创建一个代表每个网络用户的 ID。当应用于网络 data 时，它非常有用，因为在网络 data 中，识别用户会话并在不同会话中统一网络 data 是一项挑战。.
我们根据以下合并键定义了规范 ID：
- 名称： td_canonical_id
merge_by_keys：[电子邮件、电话、客户 ID］ 源表：[提交的网页表单、网页产品详情、网页访问量] 源表：[web_form_submitted、web_product_detail、web_page_visits
合并键的顺序决定了优先级。第一个合并键标识所有网络 data，具有相同的 电子邮件 (在网站上提交的网络表格中提供的电子邮件）为同一用户。.
第二优先是 电话号码 (由网站访客提交）：具有相同电话号码的 data 也被识别为来自同一用户。第三优先是 td_client_id - 第一方 Cookie ID。第一方 Cookie ID 在相同的域中具有持久性。不同的域会有不同的 td_client_id。如果网站访问者清除浏览器 cookies，td_client_id 将发生变化。.
统一后的结果如下图所示。.
示例 1： 宝 Data 将这 3 个输入定义为相同的用户 ID（td_canonical_id），因为它们具有相同的 电子邮件. .不同的电话号码不会影响结果，因为我们定义了电子邮件比电话号码具有更高的优先级：
例 2： 如果未提供电子邮件，则相同 电话号码 代表相同的用户 ID（td_canonical_id）：
例 3： 如果没有定义优先级更高的匹配字段，则使用第一方 cookie ID。相同 td_client_id = 相同的用户 ID (td_canonical_id)。这种没有任何个人身份信息（PII）的不明访客在网站访客表中很常见。Td_client_id 并不完全可靠，因为它可能在 cookie 清除后发生变化，但在没有 PII data 的情况下，它是我们所能找到的最好办法。.
如果我们假定网站上只有表单提交包含电子邮件和表单，那么没有 PII 的表格会发生什么情况，例如 网页访问量?假设网站访问只有第一方 Cookie ID - td_client_id。在第一个示例中 网页访问量 表的td_client_id分别为 ‘asd-123-qwe-456’、‘zxc-234-ert-345 ’和 ‘567-tyu-ghj-234’，则td_canonical_id=‘abcd1234’。因为 提交表单 表已经定义了这 3 个 cookie id 属于同一个用户、, 网页访问量 在没有电子邮件或电话的情况下，将依靠这些信息。.
同样的逻辑也适用于没有 PII data 的其他网络 data 表。.
创建连接在线和离线的主表 data
既然网络 data 已经相互统一，那么现在就是统一在线（网络）和离线 data 的时候了。我们所说的离线 data 是指包含 PII 的 CRM data。我们将从在线 data 中获取 web_form_submitted 表中 PII data 的使用情况（电子邮件、电话）。.
在理想情况下，data 工程师可以将 CRM 表添加到统一的 yml 文件中，但我们遇到过这样的情况：客户要求统一在线和离线 data 的条件比自动统一所能提供的条件更加复杂。因此，我们在这里依赖于 SQL 的强大功能。.
我们通过电子邮件或电话对提交表单 data 的网络表和客户关系管理表进行了全外连接。. 名字和姓氏不是唯一的，因此不可靠。.
SELECT t.crm_client_id, d.td_canonical_id
FROM crm_user_table t
FULL OUTER JOIN web_form_submitted d
关于（t.电子邮件 = d.电子邮件
或 t.phone = d.phone)
此外，还建议为匹配分数定义一个逻辑，以防多个表单使用相同的电子邮件或电话号码提交。例如，姓名与客户关系管理客户姓名匹配的网络表单比不匹配的网络表单优先级更高。.
用 profile_id 丰富其他表格
在本节中，我们将定义最终的 profile_id，它对每个用户（已识别用户和未识别用户）都是唯一的。.
总而言之, profile_id = COALESCE(crm_client_id，td_canonical_id).
用于网络表格 crm_client_id 每个网络密钥 (td_canonical_id)来自步骤 2 中创建的主表。也就是说，如果用户在网站上提交了表单，并提供了电子邮件或电话，我们就可以在客户关系管理 database 中将其识别为已知客户（如果他们已经是公司的客户）。因此，我们可以说，那些与提交的网页表单具有相同 cookie ID 的网页访问也属于已识别的客户关系管理客户。.
来自网页访问量 t
左连接主表 d
on t.td_canonical_id = d.td_canonical_id
且 d.rn_web_key = 1
rn_web_key 的定义如下：
按 td_canonical_id 分区
按 match_score 排序、,
time desc）作为 rn_web_key
它的作用是避免在目标表中出现重复，因为所有网络表都有多对多的关系。此外，它与离线和在线 data 之间匹配度最高的配置文件共享 crm_client_id。对于每个 td_canonical_id，它会选择匹配分数最高的一个，如果匹配分数相同，则选择最新的条目。.
创建 audience 表，其中包含来自所有表的配置文件
现在所有表格都有了配置文件 ID，是时候创建主分段了。. 主分部（母分部） 是 Treasure Data 的一项功能，它统一了有关用户的所有信息，包括用户与网站和产品的互动。它允许业务分析师、营销人员和其他用户在 Audience Studio 中查看所有已识别和未识别的配置文件，并在不编写任何 SQL 查询的情况下利用它们创建各种细分市场。.
要创建主分段，我们需要有一个 audience 表，用于连接所有属性表和行为表。audience 表的目标是包含所有在线和离线配置文件。它将只包含 profile_id，因为这足以将它与所有其他表（crm_user_table、web_page_visits、web_form_submitted、web_product_detail）连接起来。.
实现方法非常简单，只需将包含 profile_id 的所有表联合起来，然后重复删除所有 profile_id。.
