通过隐含数据关系增强身份解析
从高层次来看，FullContact 的 Resolve 产品最基本的核心依赖于两个操作阶段：
当我们确定这些片段来自同一个人时，将联系信息片段连接在一起（“身份图构建”过程）
允许我们的客户通过输入一个或多个联系信息来查询身份，如果该信息位于我们通过图构建过程（Resolve）连接的集群之一中，则返回一致的标识符
在理想情况下，对于我们 Resolve 客户曾经进行过的所有查询，我们都会拥有完全完整、准确和重叠的联系信息片段。我们的图构建和 Resolve 执行过程的技术底层可以完美运行，同时几乎像上面的两个要点所暗示的那样简单。
不幸的是
现实世界的考虑因素几乎总是包括（但绝对不限于）以下复杂情况：
联系信息缺失或不完整；
联系信息拼写错误或其他错误；以及
正确且完整的个人联系信息，尽管这些信息以不相交/不可连接的片段形式存在。
这样的挑战需要不断发展、世界一流的身份解析产品，以将隐含和推断信息添加到显式数据连接和查询逻辑的基础中。虽然我们的图表仍然以显式关系为基础，但实质性的增量定性和定量改进依赖于对数十亿个数据点之间复杂的连接拓扑反复严格测试的二次和传递推理。
身份图基础：显式数据关系
如果我们拥有个人的高质量、完整的联系信息片段，则在构建图 cv电话数据 表期间连接该数据并从我们的 Resolve 产品中查询数据是简单的操作。
在构建图表的步
骤中，我们寻找多个联系信息集合/片段之间共享的重叠、唯一数据组合，以证明将这些集群 信息统计和示例这可以让你 合并为单个身份集群并授予该集群一个完整联系标识符（或 FCID）是合理的。
图 1. 图形构建通过共同联系信息将较小的共同身份集群链接起来
当客户使用我们的 Resolve 产品通过输入一个或多个联系信息字段来搜索身份时，我们会执行一系列 BEB 目录 计算效率高的键值查找，以查看该联系信息是否存在并附加到我们图形中的一个身份集群。如果是，我们将返回相关的 FCID。
图 2. 使用多个联系人字段值的查询将相关的 FCID 返回给客户
身份图增强：隐式数据关系和解析的示例
在联系信息片段缺失或断开/不相交的情况下，我们有时可能会接受这样一个事实，即我们正在尽最大努力，我们无法 100% 地将 100% 的客户查询与 100% 正确的身份集群相匹配。
但是，如果我们假设相当完整的数据（及其连接）作为图形构建过程的输入，我们可以连接许多不相交的身份片段并通过合理的推理解决潜在的问题查询。
在构建图表的情况
下，我们可能有两个不相交的 Jane Smith 联系信息集合，它们位于不同的地址，并且它们之间没有足够的唯一共享数据来证明它们的联系。但是，如果 Jane Smith 片段 #1 通过 123 Main Street 的住所连接到 123 Main Street 的 John Smith，并且 Jane Smith 片段 #2 连接到同一个城市中同一个 John Smith 的 456 Second Street，我们可以合理地假设 Jane Smith #1 和 #2 是同一个人，并将这些片段连接起来。
图 3. 通过（假定的家庭成员）John Smith 的共享地址推断 Jane Smith 的联系片段之间的联系
在这里，我们使用（可能的）家庭关系来推断 Jane 的身份片段之间的联系，即使这些片段明显不相交（或至少缺乏足够的共享信息来自信地建立联系）。
另一个例子：在调用 Resolve 时，客户可能会查询位于邮政编码 12345 中 Monroe Avenue 789 号的 Jane Smith。如果这是我们连接上述 Jane Smith 片段的同一邮政编码，并且我们不知道邮政编码 12345 中还有其他 Jane Smith，我们可以（在谨慎的不确定性下）返回该邮政编码中我们（唯一的）Jane Smith 的 FCID。
图 4. 查询邮政编码 12345 中 Monroe Avenue 789 号的 Jane Smith 无法返回明确的结果，因为 1）我们没有该姓名和地址的完全匹配，并且 2）该姓名在邮政编码 12345 中不是唯一的。另一方面，我们可以返回邮政编码 12346 的推断 ID（我们没有完全匹配的地址，但我们确实知道邮政编码 c 中只有一个身份
