如何关联 LinkedIn 个人资料、帖子和评论且避免错误匹配

先选定行粒度

行粒度表示一行代表什么。采集行之前先选定粒度。

证据粒度是一条选定的评论观察。一条评论观察，是来自一份快照的一条已保存顶层评论。计数粒度是一条选定的帖子。评论计数和帖子计数是不同的度量。把两者相加之前，先在文件里写下两种含义。

写下已知的来源 URL。写下报告期间。报告截止时间是你纳入的最后观察时间。截止时间之后的行仍留在原始数据集中。它不进入本报告。

本方法只用于已知的公开帖子 URL、这些帖子的公开顶层评论，以及已核对的个人资料。不要把它用于账号搜索、一个账号的全部帖子、反应列表、回复、发送消息、职位标签或文本评分。

术语

URN 是一种带类型的文本标识符。在 `urn:li:activity:1001` 中，URN 类型是 `activity`。类型是键的一部分。`ugcPost` 是另一种帖子类型。在这些 Actor 中，`member` 是个人账号类型。`organization` 不是个人账号类型。

LinkedIn URN 指南说明了官方 LinkedIn API 的 URN 类型。该 API 使用 `person` URN。Actor 的资料键使用 `member`。这两种架构并不相同。不要把一个 LinkedIn API 中的标识符复制到另一个 API 中，并称它们相等。

JSON 是一种文本数据格式。你将使用 JSON 或文本列，这样长标识符不会丢失位数。

布尔字段的值是 true 或 false。默认值是你不改该字段时使用的值。输入架构是 Actor 接受的已发布字段列表。父键是存在评论行上的帖子键。回退表示只有当前一个键缺失时，才尝试下一个键。规范来源 URL 是你已确认的那一条来源 URL，不是该 URL 的第二种形式。

兼容的键具有相同的 URN 类型和相同的值。冲突表示一个键指向两个目标，或者两个键指向两个不同的目标。当同类型的键指向同一条帖子时，仅 URN 类型不同并不构成冲突。

三个 Actor 返回什么

三个公开 Actor 提供源行。连接仍由你来建立。

LinkedIn Post Scraper 的构建版本是 1.0.60。LinkedIn Comments Scraper 的构建版本是 1.0.47。LinkedIn Profile Scraper 的构建版本是 1.0.28。每次运行前先阅读各 Actor 页面。较新的构建版本可能改变字段。

每个 Actor 都读取公开页面。它们都不使用你的 LinkedIn 登录。它们都不返回一个账号的全部帖子。

评论输入还有 `maxComments`、`includeAuthorDetails` 和 `collectAllAvailable`。`maxComments` 是 1 到 1000 的整数。它的默认值是 100。`maxComments` 是每个帖子或每项输入最多保存的评论数。它不是多次输入的一次运行的总上限。`includeAuthorDetails` 是布尔值。它的默认值是 false。`collectAllAvailable` 是布尔值。它的默认值是 false。`collectAllAvailable` 只去掉数字保存上限。它不去掉公开限制。它不采集回复。

评论计数和输入状态在 `OUTPUT` 中。`OUTPUT` 是本次运行的摘要。它不是评论行。在它内部，`inputResults` 带有 `status`、`statusReason`、`pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete` 和 `stopReason`。

`pageCommentCount` 是该页面报告的计数。`publicRowsOnPage` 是在该页面上看到的公开行数。`savedRows` 是已存储的行数。这三个数字可以不同。`isPublicPageComplete` 说明 Actor 是否把该公开页面标为完整。`isComplete` 说明已保存的集合是否完整。`stopReason` 说明保存为何停止。部分结果可能来自保存上限、公开预览或计费上限。未知计数保持为 null。不要在它的位置写入 0。

评论 Actor 可以接受带类型的 feed-update URL。帖子 Actor 要求 `/posts/` URL。如果你只知道 feed URL，就保留评论的父键。在采集帖子快照之前，先取得一条已核实、能够匹配的 `/posts/` URL。不要编造 `/posts/` slug。

使用这些 Task，然后修改示例输入。未修改的示例无法连接。帖子 Task 的示例与评论 Task 的示例不是同一条帖子。

不要把两个评论 Task 追加成两套评论。为该帖子选择一个评论 Task。详情 Task 仍可能返回一条没有作者 ID 的评论。一次有用的详情请求可能产生单独的计费事件。该请求不保证返回 ID。它也不保证产生费用。

作者详情默认关闭。在该默认输出中，稳定的评论作者键常常为 null。公开标识符和公开 URL 以后可能改变。一份资料快照显示的是该资料在其自身时间的状态。它不能证明此人在更早的评论时间担任一项工作。本方法不指派职位角色。

运行文档说明了运行上限和超时。大规模运行前先阅读它。不要把访问令牌放进表格。

如何把评论匹配到帖子

按所述顺序匹配。保持同类型规则。匹配键指向一条帖子。先检查所有可用的兼容键是否冲突。不要跳过一个相互矛盾的较低优先级键。只有在该检查之后，才按所述顺序选择第一个受支持的匹配依据。记录该依据。依据列由读者建立。Actor 不返回它。

1. 带类型的 `postUrn` 相等。
2. `activityId` 相等，且只在 activity 类型内部比较。
3. `ugcPostId` 相等，且只在 ugcPost 类型内部比较。
4. 一条已核对的规范来源 URL。

评论字段是 `postUrn`、`activityId`、`ugcPostId` 和 `postUrl`。帖子字段是 `postUrn`、`activityId`、`ugcPostId` 和 `url`。其中任何一个都可以是 null。

先用带类型的 URN，再用单独的 ID。一条帖子上可以同时存在 activity 值和 ugcPost 值，而且两者仍然不同。这是正常的。不要把 activity 值与 ugcPost 值相比较。跨类型的相同数字不是证据。

虚构示例中的帖子 A 有 activity `1001` 和 ugcPost `2001`。这是一条帖子的两个键，不是冲突。当一个键指向两条帖子，或者可用的键指向两条不同的帖子时，才存在冲突。回退顺序不允许较弱的键覆盖该冲突。让该评论保持未解析。

只有带类型的键缺失时才使用 URL。两条 URL 都必须是你已核对的同一条规范来源 URL。如果你无法核对这一点，就让该行保持未解析。URL 依据弱于带类型的键。写下该依据和两个观察时间。

在这次连接之前，把重复的帖子快照减到一条选定的查找行。如果查找表中一条帖子仍有两行成功记录，连接就会复制评论。修正查找表。不要删除被复制的评论行，同时却不改查找表。

缺少帖子快照就是缺少匹配。它不是一条空帖子。一条成功的帖子但没有已保存评论，是另一种结果。一次失败的帖子尝试，是另一种结果。你没有运行的一项输入，是另一种结果。

如何匹配个人资料

只有在作者表示个人账号之后，才把资料匹配到评论作者。评论字段是 `authorType`。它可以是 `person`、`organization` 或 null。帖子 Actor 可以把帖子作者类型写成 `Person`。每个来源值都按到达时的原样保留。对这一含义检查，`person` 和 `Person` 都表示个人账号。不要要求大小写字母相同。不要为了让字母一致而修改已存储的文本。

组织作者留在个人资料连接之外。组织 URL 不能变成 `/in/` 资料行。`urn:li:member:11` 和 `urn:li:organization:11` 是不同的键。不要去掉 URN 类型来强行匹配。

个人检查之后，按此顺序匹配：

1. member ID 相等：资料的 `profileId` 对评论的 `authorId`。
2. member URN 相等：资料的 `profileUrn` 对评论的 `authorUrn`。
3. 较弱的回退：`publicIdentifier` 对 `authorPublicIdentifier`，或者资料 `url` 与评论 `authorUrl` 中的规范 `/in/` URL。

不要匹配 null。不要匹配空白单元格。如果 member ID 指向资料 X，而 URL 指向资料 Y，该行就是冲突。不要用较弱的 URL 挑选胜出者。

URL 或公开标识符可以在不同快照之间改变。如果你使用这个较弱依据，就写下两个 `observedAt` 值和该依据。null URL 保持未解析。姓名、照片和头衔不是键。不要按姓名搜索来填补缺失的链接。

同样的资料字段可以与帖子作者字段 `authorId`、`authorUrn`、`authorPublicIdentifier`、`authorUrl` 和 `authorType` 比较。该比较只检查帖子作者角色。它是可选的。它不是评论作者。绝不要用帖子作者替换评论作者。绝不要把一个账号的每条帖子连接到该账号的每条评论。

one post snapshot
    -> many comment observations

one person profile
    -> many comments by that person

optional post-author match
    -> the post row only
    -> not the comment author

一个人可以写许多条评论。一条帖子可以有许多条评论。这两个方向是分开的。

评论身份使用 `commentId`、`commentUrl`、父键和 `observedAt`。ID 或链接可以是 null。保留该观察。不要编造稳定 ID。不要把相同文本当成同一条评论。不要把表格行号当成 ID。跨运行时，只有父键和 `commentId` 都稳定且相等，才选定一条观察。没有稳定 `commentId` 的行保持为各自独立的观察。

资料和帖子状态使用 `status`、`statusReason` 和 `observedAt`。把失败的资料行留在源文件中。不要把它当成一次成功的资料匹配。

连接前先选定一份快照

查找行是你允许连接使用的那一份快照。每条已核对的帖子至多选择一行成功的帖子。每位已核对的人至多选择一行成功的资料。在连接之前完成这件事。

保留原始数据集。不要把两份快照混成一行新记录。把选择规则写在文件里。一条清楚的规则是：报告截止时间之前最新的成功快照。

如果一个人有两份成功的资料快照，就选择一份。如果两份都留在查找表中，该人的每条评论都会按每份快照复制一次。多出来的连接行是查找表错误。修正查找表。不要删掉副本，然后称表格正确。

然后从选定的评论观察建立左连接。先把每条评论连接到一条来源帖子。再把它的个人作者连接到至多一份资料。没有帖子匹配的评论仍然保留。没有资料匹配的评论仍然保留。

连接后的证据表必须与选定的评论观察行数相同。行数更多，表示某个查找键仍指向不止一行。

这些由读者建立的字段属于证据行：匹配依据、匹配结果、选定的快照规则，以及你比较过的来源时间。把它们标为读者自建。不要把它们说成 Actor 字段。

把长 ID 保持为文本。电子表格可能改变一个长数字并丢掉位数。导出 JSON，或者在导入前把每个 ID 列设为文本。JSON 的定义见上文。数据集文档给出了导出路径：选择该数据集，选择 Export，选择格式，再选择 Download。单独保存 `OUTPUT`。数据集导出不包含 `OUTPUT`。

步骤

1. 写下粒度、已知 URL、报告截止时间，以及每种计数的含义。证据文件中，每条选定的评论观察占一行。计数文件中，每条选定的帖子占一行。在写完这些内容之前，评论合计与显示的帖子计数保持分开。
2. 打开用于安全数据连接的 LinkedIn 帖子 ID 与评论 ID。用一条已知的公开帖子 URL 替换示例 URL。把 `maxComments` 设为 3。保持 `collectAllAvailable` 为 false。让作者详情保持关闭。开始运行。在解释一个小集合或空集合之前，先打开 `OUTPUT`。行数少，可能表示保存上限、失败的输入、公开限制，或公开评论集合本来就短。仅凭行数不能说明是哪一种。
3. 如果默认评论行不含你需要的作者键，就改用带公开资料详情的 LinkedIn 评论作者，不要用第一个评论 Task。替换示例帖子。使用三条评论。保持不限量关闭。把 `includeAuthorDetails` 设为 true。不要把两份输出粘在一起。详情仍可能缺失。额外的详情请求可能单独计费，而且仍可能不返回 ID。
4. 打开用于数据连接的 LinkedIn 帖子 ID 与作者键。用同一条 `/posts/` URL 替换它的示例。不要传入帖子 ID。不要传入 feed-update URL。如果你只有 feed-update URL，就保留评论父键，并停止帖子采集，直到你有一条已核实的 `/posts/` URL。不要编造 slug。把 `ok`、`failed` 和 `invalid_url` 行分开保留。保留 `observedAt`。缺少帖子快照仍然是缺少匹配。
5. 阅读评论作者键。如果评论行已经包含本报告需要的每项作者事实，就跳过资料 Actor。如果没有，就用用于数据连接的 LinkedIn 个人资料 ID 与 URN采集不重复的公开 `/in/` URL。去掉重复的 URL。排除组织 URL。不要按姓名、照片或头衔搜索。把失败的资料尝试留在源文件中。失败的尝试不是已匹配的人。
6. 选定查找表。每条已核对的帖子保留一份成功的帖子快照。每位已核对的人保留一份成功的资料快照。对于重复的评论运行，每个稳定父键加上 `commentId` 只保留一条观察。没有 `commentId` 的行保持为各自独立的观察，即使文本相同。保留每一份原始数据集。写下截止规则。连接之前，先在查找表中解决重复键和冲突。
7. 把每条选定评论左连接到一条帖子。先用相等的带类型 `postUrn`，再用相等的 activity ID，再用相等的 ugcPost ID，再用一条已核对的规范 URL。不要跨越 URN 类型。然后把个人作者连接到至多一份资料。先用 member ID，再用 member URN，再用带日期的公开标识符或规范 `/in/` URL。写下读者自建的依据、结果，以及两个来源时间。不要用来源帖子的作者填补评论作者。不要把一个账号的全部帖子连接到该账号的全部评论。
8. 统计证据行。这个数字必须等于选定的评论观察数。如果更大，查找表中一个键仍对应许多行。修正该查找表并重新连接。不要把删除重复证据行当作唯一修复。另外分别统计未匹配的父级、缺失的个人键、失败的资料、组织作者和冲突。
9. 按已解析的帖子键给评论观察分组。只把 `commentsCount` 放在一条选定的帖子行上。把该次运行的 `OUTPUT` 覆盖情况放在帖子旁边。保留没有已保存评论的帖子。把一次成功的空采集、一次失败的尝试，以及你没有运行的输入，保留为不同的事实。把作者键计为观察到的账号。不要把它们称为各计一次的不同人员。不要把它们称为评论者或浏览者的完整集合。
10. 导出证据表、未解析表、按帖子计数的表，以及一份来源摘要。使用上文的数据集导出路径。把 `OUTPUT` 保存在旁边。把 ID 保持为文本。在每一条结果行上显示来源键、读者自建的依据，以及缺失的证据。只有当你拥有针对该确切缺口的受支持来源 URL 时，才填补缺口。否则让它保持未知。

证据计数是第 8 步。帖子计数是第 9 步。不要把帖子计数用作评论计数。

一次公开核对证明了什么

一次公开核对从一条已知帖子保存了三条评论。来源显示四条评论，并暴露了四行。上限保存了三条。这三条已保存父键都匹配到同一条来源帖子。一位评论作者匹配到单独的一行个人资料。所有这些已核对的匹配都成功了。

该次运行的评论 `OUTPUT` 中，`isPublicPageComplete` 为 true，`isComplete` 为 false，`stopReason` 为 `max_comments_reached`。合在一起读，Actor 把该公开页面标为完整，而保存仍不完整，因为已达到保存上限。

该核对只证明这些行和该摘要。它不证明以后的每一条帖子。它不是对 ugcPost 匹配、组织作者、null 键或冲突的一次新的实时测试。这些情形使用上文的字段规则和下文的虚构计数。

虚构的帖子、评论与计数

本节中的每个值都是虚构的。C1 到 C6 是教学标签。这些短 ID 是教学 ID。它们不是采集到的 LinkedIn 值。不要把下面任何一个 URN 当成真实的资料、帖子或评论。

报告截止时间在 `time-2` 之后。选定的 member12 快照是较晚的那份成功快照。帖子作者类型在 A 和 B 上存储为 `Person`。评论作者类型在 C1 到 C4 上存储为 `person`。这些含义相符。存储的字母仍然不同。帖子 C 存储为组织作者。

Member11 有一行成功且已选定的资料。Member12 有两份成功快照。连接前先选择一份。Member13 有一次失败的资料尝试。A 和 B 由 member11 撰写。C 由 organization11 撰写，不是由 member11 撰写。

C2 不能按带类型的 activity URN 匹配，因为该父 URN 是 ugcPost URN。activity ID `1001` 匹配帖子 A。ugcPost ID `2001` 也匹配帖子 A。两个同类型键一致，所以这是确认，不是冲突。你写下的依据是 activity ID。

C5 匹配帖子 C，因为两边都使用 ugcPost `1001`。帖子 A 也包含数字 `1001`，但这些数字是 activity ID。相同的数字不会把 C5 移到 A 上。

证据表保留六行。匹配表和未解析表是视图。当一侧匹配而另一侧不匹配时，它们可以重复一条评论。不要把这些视图加在一起，并把合计称为评论总数。

匹配视图有 8 行。C1、C2 和 C3 各有两个成功侧。C4 和 C5 只有帖子侧。8 不是评论总数。6 才是评论总数。

C6 有两个未解析部分，以及一行证据。把它作为一条评论只计一次。

逐项核对每个合计：

• 选定的评论观察：6。
• 左连接之后的证据行：6。
• 父帖子匹配：5，即 C1、C2、C3、C4 和 C5。
• 未匹配的父级：1，即 C6。
• 匹配到成功个人资料的评论行：3，即 C1、C2 和 C3。
• 用到的成功个人资料：2，即 member11 和 member12。
• 未解析的个人结果：2，即 C4 上失败的资料，以及 C6 上缺失的作者键。
• 处于个人资料范围之外的组织作者：1，即 C5。
• 已识别的 member 键：3，即 member11、member12 和 member13。
• 这 3 个 member 键不是 2 份资料，也不是 3 名已证实的人员。
• 按父级统计的已采集行：A 有 2，B 有 2，C 有 1，未匹配的父级有 1。
• 2 加 2 加 1 加 1 等于 6。

`commentsCount` 留在帖子行上。如果你把它复制到每一条已采集评论上，再把这些副本相加，A 会两次贡献 10，B 会两次贡献 20。那是 20 加 40，即 60。正确的、已知的显示合计对每条选定帖子只使用一次：10 加 20 等于 30。帖子 C 是 null。不要把 null 改成 0。不要称 30 为完整。已采集观察的度量不同：5 个已匹配父级加 1 个未匹配父级等于 6。

这张虚构表格没有 `OUTPUT`。真实覆盖情况仍需要该次运行中的 `pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete`、`stopReason`、`status` 和 `statusReason`。显示计数为 10 且已采集 2 行，本身并不是覆盖率。

如果两份 member12 快照都留在查找表中，C2 会被复制，C3 也会被复制。证据表会从 6 行增加到 8 行。先选择 `time-2` 快照。证据表回到 6 行。在两份快照仍留在查找表中时删除那两行多余证据，并不能修复下一次连接。

Member11 写了两条选定帖子 A 和 B，以及一条选定评论 C1。如果你把这两条由其撰写的帖子直接连接到 member11 所写的评论，C1 会出现两次。在同时谈论两边之前，先分别统计每个分支。帖子作者分支有 2 条帖子。评论作者分支有 1 条评论。父级匹配只把 C1 留在帖子 A 上。C1 匹配 member11，是因为评论作者键是 member11，不是因为 member11 写了帖子 A。

Member12 显示允许的方向。一份选定资料匹配两条评论。C2 留在 A 上。C3 留在 B 上。共享的资料不会把任何一条评论移到另一条帖子上。

仅有一份成功的帖子快照，并不能证明评论集合为空。只有一项已核对且成功的评论输入，并且保存行数为 0，才是观察到的空结果。上限仍然限制该结果。来源限制仍然限制该结果。失败的输入保持未知。未尝试的输入保持未知。观察到的空结果并不是显示为 null 的 `commentsCount`。六行示例的合计不变。C6 是一个未匹配的父键。它不是一次失败的帖子尝试。

另外三条虚构规则位于这六行之外。不要把它们加进上面的合计。

member 键为 null 的一个人，当当前 `/in/` URL 完全相同时，可以匹配一份已核对的资料。写下较弱的 URL 依据和两个观察时间。null URL 保持未解析。如果 member ID 指向 X 而 URL 指向 Y，就保留冲突，不要使用该 URL。`commentId` 为 null 的评论保持为自己的一条观察。相同文本不能补上缺失的 ID。表格行号也不能补上它。

完成的文件显示什么匹配了、为何匹配，以及什么仍然未知。它不对人员排名。它不判断一条帖子是否成功。