如何将B2B活动的数据传入CRM

B2B 活动的数据传入 CRM 的方案：实体、ID、状态、字段、同意、重复项以及已接收记录的校验。

面向企业的活动（B2B，business-to-business）数据常常在场地与 CRM（客户关系管理系统）之间失去意义。表单里有姓名和 email，胸牌上出现编号，扫描器记录操作，而目标系统里只留下一个没有明确活动、场次、会面或邀请来源的新联系人。

我们在 Aventura 从另一头开始：先描述必须送达客户系统的事实，并约定 CRM 如何确认接收。这样的约定需要在开放注册之前完成。之后再修改标识符（ID）、状态和字段用途会明显更难：数据已经在从多个点同时流入。

如果您正在筹备商务活动，并希望提前把注册、到场签到（check-in）和现场活动与客户系统关联起来，请申请项目工作讨论。我们将帮助描述活动数据方案和联合测试要求。CRM 的配置和管理仍由客户的专业团队负责。

哪些数据必须进入 CRM？

只传递那些能够支撑 CRM 中具体操作的数据。对于每个字段和事实，都要事先明确目的、负责人和接收方。如果团队无法说明谁使用该值以及后续做什么，最好将该字段从表单或数据交换中移除。

B2B 活动的数据来源有多个。邀请带来活动与渠道信息。注册说明谁申请了参与。

到场标记确认出席。分会场、会议或展台行为会新增事实。CRM 应将这些部分连同共同上下文一起接收，但不必将它们存储在同一对象中。

对每个来源的最小问题如下：

UTM 标记（Urchin Tracking Module）有助于区分来源、渠道和访问活动。它们属于注册上下文，不能替代人员或申请标识符。胸牌编号也不应成为通用键：其作用仅限于特定项目及访问方式。

另一篇关于注册与 152-FZ 要求的文章探讨了表单的法律和组织层面。这里我们保持更窄的边界：哪些实体和字段会进入 CRM 中已接受的记录。

五个实体，而非一个过载的联系人

人员、公司、报名、出席和活动分别回答不同的问题。如果把它们合并到一张联系人卡片中并不断覆盖字段，系统就会丢失历史记录。关联记录可以保留事实的先后顺序，并允许单独核查每一次传递。这样团队不仅能看到联系人的当前状态，还能看到参与者在具体活动中的路径。

人员（Person）——参与者的主记录。主记录中包含稳定的联系信息和已确认的标识符。一个人可以参与多个活动、多次报名并执行不同的操作。

公司（Company）——组织。公司并不在所有情况下都等同于电子邮件域名，因此需要确定关联规则。企业域名可能是强有力的线索。公共邮箱、子公司或顾问需要另作处理，有时需要人工核查。

报名（Registration）——人员对具体活动的申请。它有自己的 ID、event ID、来源、创建时间和状态。同一个人再次参与其他活动会创建新的报名，而不是新的人员。

出席（Attendance）——实际到场的事实。报名并不能证明到访。Microsoft Customer Insights 同样区分 event registration 和 check-in，而且 check-in 可以针对整个活动或单个场次。因此，“已报名”和“已出席”这两个字段不能视为同义词。

活动（Activity）——单独的操作：参加场次、会面、扫描资料、到访展台或其他已确认的事实。活动保存自己的 ID、类型、时间和上下文。HubSpot Meetings API 遵循同样的逻辑：会面作为单独的 CRM 活动存在，并与联系人和公司关联。

这一模型并不要求所有 CRM 采用相同的结构。在一个系统中，报名会成为单独的对象；在另一个系统中，则成为活动参与；而活动则成为操作动态中的一条记录。无论采用何种技术呈现方式，其含义都应保持不变。

贯穿全流程的标识符体系

每个对象和事实都应有独立且稳定的 ID。由数据源一次性生成标识符，后续系统直接传递而不重新创建。这样重复投递会被识别为重复，团队也能在表单、交换日志和 CRM 中找到同一条记录。

工作集可以包括：

1. event_id - 具体活动。
2. person_id - 在约定范围内的人员主记录。
3. company_id - 客户系统或交换目录中的组织。
4. registration_id - 人员对该活动的报名。
5. attendance_id - 单独的签到事实。
6. activity_id - 分会场、会议、展台或其他动作。
7. source_system - 创建该事实的系统。
8. schema_version - 数据契约版本。

RFC 标准描述了 UUID——一种可无需中央注册即可生成的通用唯一 128 位标识符。当表单、移动应用和现场设备由不同系统提供服务时，这非常方便。UUIDv7 还额外支持时间顺序，但具体版本并不重要。关键在于：由一个团队制定生成规则，所有参与方都保留该值。

CloudEvents 规范提供了实用的事件传输模型。source + id 组合确定一个独立事件，重复发送的事实可以保留相同的 ID。接收方据此识别重复，无需根据姓名、email 和时间猜测。

重要。 所传输事实的标识符不等于人员标识符或活动的 event_id。Adobe XDM ExperienceEvent 事件模型明确区分事件记录的 _id 和人员身份。一个参与者可以产生许多活动，每个活动都获得自己的标识符。

在会议或论坛上，这种方法尤其有用：报名、总入口、分会场出席和预约会议来自项目的不同部分，但都围绕共同的 event_id 和 person_id 汇集。这样团队可以核查每个事实的路径，而不会在联系人卡片中混淆不同实体。

需要在承包商配置表单、胸牌和扫描器之前，先确定活动的数据架构。请申请数据架构讨论和初步预算。我们将把活动的各个接触点整合为一份技术任务书，并与客户方的 CRM 负责人一起进行测试。

如何就状态达成一致？

状态必须包含代码、定义、负责人和允许的转换。像“已到达”“已参与”或“有兴趣”这样的自由文本很快会在含义上产生分歧。字典明确规定了哪个事实会改变状态，以及 CRM 会得到什么。为注册、出席和会议分别设立独立的字典，可以避免同一个词表示不同的事件。

从独立的字典开始。注册状态不应与出席状态和会议结果混在一起。

表中的名称仅作为结构示例。最终代码由客户团队选择。如果 CRM 中已有字典，发送方通过明确的映射表来适配它。如果发送方使用自己的字典，映射表必须显示每个对应关系以及未知值的处理方式。

为每个状态记录四条规则：

1. 由哪个可观察到的事实来设定它。
2. 谁有权更改该值。
3. 是否可以回到之前的状态。
4. 在事件延迟或重复发生时会发生什么。

例如，checked_in 在入口处扫描被接受后出现。对同一 attendance ID 的重复扫描不会创建第二次出席。如果客户政策要求保留历史记录，迟到的注册取消不会删除已确认的出席事实。

不要在活动期间更改现有代码的值。添加新版本的架构并约定过渡方式。否则，更改前后相同的 status=confirmed 将意味着不同的事情。

如何编制字段与上下文映射表？

字段映射表在名称、类型、必填性、转换规则和出错时的行为层面将来源系统与 CRM 关联起来。仅有一份列清单是不够的。接收方必须理解值的来源以及它属于哪个实体。对于有争议的字段，应立即确定参考字典、架构版本、决策负责人以及系统在值错误时的响应方式。

HubSpot Properties API 很好地展示了数据类型与字段界面之间的区别。字符串、日期、数字和枚举的存储方式各不相同。状态字典适合使用受限的取值集合，而不是文本字段。如果目标 CRM 支持唯一性约束模式，可以将自有外部 ID 放入要求唯一性的字段中。

最小字段映射表如下所示：

上下文对于展台尤为重要。仅传递一个 badge_number=1842 无法向接收方说明任何信息。还需要 event ID、activity ID、操作类型、时间、扫描来源以及 person 或 registration ID。如果参与者请求了特定资料，只有在接收方存在已约定的操作时，才将资料代码作为单独字段传递。

对于参展，映射表不应只覆盖总体注册。其中会出现区域、展台、扫描器和不同的数据所有者。来源越多，统一的 source_system、架构版本和被拒记录日志就越重要。

如果最小化规则允许，建议将原始值与转换后的值一并保存。这样无需再次向现场平台发起请求即可排查有争议的状态。此类技术痕迹的保存期限由客户确定。

数据最小化与同意

表单和数据交换应仅收集实现既定目标所需的最小数据集。每增加一个字段，都会增加核查工作量、错误数量和法律负担。W3C WAI建议只询问完成流程所必需的信息，并提供清晰的标签、说明和错误提示。

我们采用简单的字段筛选标准：

1. 该字段在活动或CRM中解决什么任务？
2. 谁是该值的所有者？
3. 获取后将采取什么操作？
4. 注册时是否就需要精确值？
5. 能否稍后从主系统中获取该值？
6. 如果参与者不填写该字段会怎样？

如果前三个问题没有答案，该字段通常会被删除。例如，详细的行业画像可能对议程有用，但如果没有使用细分数据，且数据不影响参与者的行程安排，就不应收集。

同意及其他处理依据应按目的分别设计。欧洲数据保护委员会（EDPB）在《通用数据保护条例》（GDPR）指南中要求获得具体、知情且明确的同意，并能够证明同意的获取方式和时间。该文件不能替代俄罗斯的法律审查，但提供了一个有用的原则：不应将参加活动与后续营销传播隐藏在同一个无法区分的字段中。

如果处理基于同意，数据合同中可能需要包含：

• 目的；
• 文本版本；
• 时间；
• 界面来源；
• 选择结果；
• 在客户系统中修改或撤回的方式。

Google Customer Match展示了另一条边界。广告平台使用公司自有的线上和线下数据，而对于来自欧洲经济区的用户数据的合作伙伴上传，则要求提供同意信号。将注册信息操作性地传输至CRM本身并不意味着允许任何广告激活。该目的、字段构成和依据应由客户另行协商确定。

如何避免创建重复记录？

去重包括查找相似记录，并单独决定如何处理该记录。稳定的外部 ID 完全匹配可以自动处理。姓名、公司、邮箱或电话的疑似匹配则需要规则、优先级，有时还需要人工核查。在启动之前，团队要确定哪些特征被视为精确匹配，哪些只会将记录送去审核。

Salesforce 将匹配规则（matching rules）和重复处理规则（duplicate rules）分开。前者查找候选记录，后者决定操作：警告、允许或阻止创建。这一逻辑在特定平台之外同样有用。

工作顺序：

1. 如果 external_person_id 已知，则按它查找记录。
2. 如果客户政策允许将精确的规范化邮箱作为搜索键，则检查该邮箱。
3. 检查其他已确认的标识符。
4. 根据较弱特征的组合生成候选记录。
5. 结果不明确时不要自动合并。
6. 只有在通过规则后才创建新的主记录。
7. 将新的注册或活动关联到该记录，而不覆盖历史。

发送方和接收方以相同方式执行规范化。电话被转换为约定的格式。邮箱去除空格，并按采用的规则检查大小写。公司名称不应作为唯一键：不同的拼写和集团结构会导致误匹配。

另一个任务是幂等性，即安全地重复发送。如果写入后网络中断，发送方可能不知道结果并重复请求。同一个 registration_id、attendance_id 或 activity_id 应更新或确认现有对象，而不是创建第二个。

至少检查四种情况：

一个主记录并不意味着所有内容只有一行。主记录属于人员。注册、出席和活动仍作为围绕该人员的独立历史保留。

发送方、接收方与错误处理的责任人

数据交换必须有两个明确的责任人：发送方和接收方。前者负责数据的完整性、格式和重新投递。后者负责 CRM 架构、接收规则、关联关系以及记录的校验读取。缺少这一对角色，团队就无法明确谁负责修正错误、谁负责确认重新接收。

职责划分可以这样确定：

需要一份错误日志，包含 record_id、时间、架构版本、原因代码和重新处理状态。日志中的个人数据应缩减至必要的最低限度。团队通常只需技术 ID 和受保护记录的链接即可。

我们 Aventura 不负责实施客户的 CRM，也不制定其内部规则。我们可以描述活动的数据来源，与专业团队商定传输格式，并核实场地场景是否能提供预期数据。接收模型和访问权限由客户的 CRM 负责人负责。

如何验证从报名开放到数据落库的完整链路？

端到端测试从参与者的操作开始，到对 CRM 记录进行核对读取结束。在这两个节点之间，团队需要分别验证数据来源、传输和处理。软件接口的响应或文件夹中出现文件，只能证明中间步骤完成。只有当目标系统中的关键字段、关联关系、负责人和状态都经过核对后，记录才算被成功接收。

请准备一个单独的测试活动，以及一组不含真实人员数据的合成记录。然后按顺序执行以下场景。

1. 正常报名。填写表单，保存 UTM 上下文，并检查 registration ID。
2. 已知人员。使用现有测试主记录的 person ID 重复报名。
3. 签到。扫描测试胸牌，并检查单独的 attendance ID。
4. 场次或展位。创建 activity_id，包含 event_id、操作类型、时间 occurred_at 和来源系统 source_system。
5. 会面。传递时间、负责人、结果，以及与人员和公司的关联关系。
6. 重复投递。再次发送同一个记录标识符，确认没有创建重复记录。
7. 字典错误。传递一个未知状态，检查系统是否按约定规则拒绝该记录。
8. 缺少必填字段。确认错误原因对发送方清晰可理解。
9. 核对读取。读取 CRM 记录，将字段值、关联关系和负责人与预期进行比对。
10. 修正。修正后重新写入记录，确保原始 ID 和历史记录不丢失。

每次检查都要保存预期结果和实际结果。出现差异时，必须指定负责人、修复期限，并重新运行同一场景。

报名和 check-in 的压力测试解决的是另一个相邻问题：系统能否承受计划流量，以及发生故障时会出现什么情况。其场景汇总在报名和 check-in 压力演练一文中。而这里的验收标准仅限于单条记录在整个链路上的语义和完整性。

测试结束后，双方签署字段映射表、状态字典和测试结果的版本。上述任一文档发生变更，都需要重新验证受影响的场景。

启动就绪检查清单

当项目参与者对实体、字段和有效记录的判定标准有一致理解时，整个架构才算就绪。这份检查清单可用于表单开放前的最终联合会议。它并不重复完整的字段映射，而是锁定那些缺少后团队难以控制重复记录和争议状态的决策。

1. 活动拥有稳定的 event_id，而报名、出席和活动行为各自拥有独立标识符。
2. 个人、公司、报名、出席和活动行为在含义上相互区分。
3. 状态具有代码、定义、负责人和字典版本。
4. 字段映射记录类型、必填性、转换规则、活动来源和错误。
5. 匹配查找、重复提交和重复记录处理的规则另行达成一致。
6. 明确指定发送、接收和错误修正的负责人。
7. 端到端测试涵盖正常记录、已知人员、重复记录、错误和校验读取。
8. CRM 负责人在报名开放前已确认关联关系和架构版本。

这一就绪状态并不取代后续的数据工作。事件与商业系统的整体关联在关于事件驱动增长与漏斗的材料中讨论。活动结束后向市场和销售移交行动的顺序另见关于SLA 跟进的文章。当前架构在 CRM 接收带有正确关联关系和负责人的可验证记录时即告结束。

我们 Aventura 可以将活动的各个数据点整合为一份统一的技术任务书，走一遍嘉宾路径，并与客户团队进行联合测试。申请项目讨论和初步预算。在会议上，我们将确定活动数据来源、我们的工作范围以及 CRM 方参与验收的人员。

资料来源

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match