作者
本文将阐述身份识别对齐面临的挑战，并演示我们在客户数据平台（特别是Treasure Data）中创建统一用户ID的方法。
数据来源于离线数据仓库和在线网站跟踪。
客户数据平台
客户数据平台（CDP）使企业能够以统一、集中的方式收集、管理和分析来自各种渠道的客户数据。CDP 的目标是通过整合来自多个接触点（如网站、移动应用、社交媒体、电子邮件互动等）的数据，为每位客户构建一个全面且连贯的视图。
Treasure Data
Treasure Data 是一个cloud客户数据平台。以下是 Treasure Data 的一些常见商业应用场景：
身份核对
身份核对是指在不同系统或数据库之间对某人的相关数据进行比对和匹配，以确保数据的准确性、一致性，并形成该人的统一视图。
在多个系统或数据源存储同一人的信息，但数据可能不完整或不一致的情况下，这一点尤为重要。
ID 核对面临的挑战
身份信息核对面临诸多挑战，尤其是在数据集庞大且信息来源多样的情况下。这些挑战包括数据格式不一致、质量问题导致的错误匹配，以及因错误或系统变更而产生的重复记录的管理。核心挑战在于缺乏一个能在不同信息来源、数据表和数据库中唯一标识用户的标识符。
企业通过投资Treasure Data等先进数据工具来应对这些挑战。
ID 核对的实施
我们利用Treasure Data的统一功能，为某位客户实施了ID对齐。本文将分享我们的方法和实现逻辑。
已知条件：CDP 数据库中包含有关用户在网站上浏览路径的信息表，数据仓库中的 CRM（客户关系管理）数据库也提供了客户信息。
我们的目标是在每个CDP表中拥有一个唯一的用户档案标识符。这将使我们能够创建一个“主用户分群”，从而全面掌握客户及其旅程的360度视图。
可用的在线数据包括：网站页面的浏览量、网站表单的提交情况，以及其他与网站相关的信息（例如存储在单独数据表中的产品页面详情）。
可用的离线数据：来自数据仓库的CRM数据。
创建唯一个人资料 ID 的步骤概述：
Web 表格的统一
为了统一 Web 数据，我们将利用 Treasure Data 的数据统一功能。这需要在 YAML 格式的配置文件中定义源表以及需要统一的列。有关如何在 Treasure Data 中实现数据统一的分步指南，请参阅Treasure Data 文档。
因此，它会在每个用于数据统一的表中创建一个规范 ID。规范 ID 的目的是创建一个能够代表每位网络用户的标识符。当应用于网络数据时，这一机制尤为有用，因为在网络环境中，识别用户会话并统一不同会话间的网络数据往往颇具挑战性。
我们定义了规范ID基于以下合并键：
– name: td_canonical_id
merge_by_keys: [email, phone, td_client_id] source_tables: [web_form_submitted, web_product_detail, web_page_visits]
合并键的顺序决定了优先级。第一个合并键将所有具有相同电子邮件地址（即在网站表单中提交的电子邮件地址）的网页数据视为来自同一用户。
第二优先级是电话号码（由网站访客提交）：包含相同电话号码的数据也会被识别为来自同一用户。第三优先级是td_client_id——First-Party ID。First-Party ID 在同一域名下是持久的。不同域名将拥有不同的 td_client_id。如果网站访客清除了浏览器cookiestd_client_id 将会发生变化。
合并后的结果如下所示。
示例 1：Treasure 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 数据的情况下，这是我们目前能采用的最佳方案。
如果我们假设只有网站上的表单提交才包含电子邮件和表单信息，那么对于那些不包含个人身份信息（PII）的表（例如web_page_visits），情况又会如何？假设网站访问数据仅包含First-Party ID——td_client_id。 在第一个示例中，web_page_visits表中包含 td_client_id 为“asd-123-qwe-456”、“zxc-234-ert-345”和“567-tyu-ghj-234”的记录，其 td_canonical_id 均为“abcd1234”。 由于web_form_submitted表已定义这 3 个 Cookie ID 属于同一用户，因此在缺少电子邮件或电话号码的情况下，web_page_visits将依赖此信息。
同样的逻辑也适用于其他不包含个人身份信息（PII）的网页数据表。
创建一个将在线数据与离线数据进行关联的主表
既然各渠道的网络数据已经实现统一，现在是时候将线上（网络）数据与线下数据进行整合了。这里所说的线下数据，指的是包含个人身份信息（PII）的客户关系管理（CRM）数据。至于线上数据，我们将提取web_form_submitted表中包含的个人身份信息（如电子邮件、电话号码）。
在理想情况下，数据工程师可以将 CRM 表添加到统一 YML 文件中，但我们曾遇到过这样一种情况：客户对线上和线下数据统一的要求比自动统一功能所能提供的更为复杂。因此，我们在此借助了 SQL 的强大功能。
我们对网站表、表单提交数据以及CRM表进行了基于电子邮件或电话字段的完全外连接（FULL OUTER JOIN）。姓名和姓氏并非唯一字段，因此不可靠。
SELECT t.crm_client_id, d.td_canonical_id
FROM crm_user_table t
FULL OUTER JOIN web_form_submitted d
ON (t.email = d.email
OR t.phone = d.phone)
此外，建议制定一套匹配评分规则，以防出现多个表单使用相同的电子邮件地址或电话号码提交的情况。例如，姓名与CRM客户姓名匹配的网页表单，其优先级应高于未匹配的表单。
使用 profile_id 更新其他表
在本节中，我们将定义最终的 profile_id，该标识符对每位用户（无论是否已验证身份）都是唯一的。
简而言之，profile_id = COALESCE(crm_client_id, td_canonical_id)。
对于网页表格，crm_client_id是根据步骤 2 中创建的主表中的网页键（td_canonical_id）提供的。这意味着，如果用户在网站上提交表单并提供了电子邮件或电话号码，我们就可以在 CRM 数据库中将其识别为已知客户（前提是他们已经是该公司的客户）。 因此，我们可以认为，那些与提交的网页表单具有相同 Cookie ID 的网页访问，也属于该已识别的 CRM 客户。
FROM web_page_visits t
LEFT JOIN master_table d
ON t.td_canonical_id = d.td_canonical_id
AND d.rn_web_key = 1
rn_web_key 的定义如下：
partition by td_canonical_id
order by match_score,
time desc) as rn_web_key
其作用是避免在目标表中产生重复记录，因为所有 Web 表都具有多对多关系。此外，它会与离线数据和在线数据匹配度最高的个人资料共享 crm_client_id。对于每个 td_canonical_id，它会选择匹配分数最高的那个；如果匹配分数相同，则选择最新的条目。
创建一个包含所有表中用户资料的受众表
既然所有数据表都已拥有用户画像 ID，现在是时候创建主分段了。主分段（父分段）是 Treasure Data 的一项功能，它整合了与用户相关的所有信息，包括用户与网站及产品的交互情况。借助该功能，业务分析师、市场营销人员及其他用户可在 Audience Studio 中查看所有已识别和未识别的用户画像，并利用这些数据创建各种分段，而无需编写任何 SQL 查询。
要创建主分段，我们需要一个受众表，用于与所有属性表和行为表进行关联。受众表的目标是包含所有用户档案——无论线上还是线下。该表仅包含 profile_id，因为仅凭此字段就足以将其与其他所有表（crm_user_table、web_page_visits、web_form_submitted、web_product_detail）进行关联。
实现方法很简单，只需将所有包含 profile_id 的表进行合并，并对所有 profile_id 进行去重即可。
