如何研究 LinkedIn 评论作者的公开角色

把评论和账户分开

一行已保存记录是一条可用的顶层评论。它不是一个人。它不是一次反应。它不是一份完整个人资料。它不是一整条讨论串。

这些是行字段：

• `commentId`
• `commentUrl`
• `postUrl`
• `postUrn`
• `authorType`
• `authorUrl`
• `authorId`
• `authorUrn`
• `authorPublicIdentifier`
• `authorName`
• `authorHeadline`
• `authorLocation`
• `authorCurrentOrganizations`
• `text`
• `observedAt`

`authorUrn` 和 `postUrn` 是 URN 值。URN 是来自公开来源的带类型文本标识符。`authorId` 也是公开来源标识符。这些标识符是公开的。它们不是密钥。

`authorType` 有三个已核对的值：`person`、`organization` 或 `null`。`null` 表示未给出类型。不要把 `null` 读成 person。

`observedAt` 是你观察到该行的时间。它不是帖子发布的时间。如果两个时间都有，都写进笔记。不要对调。

`authorCurrentOrganizations` 可以包含不止一条公开记录。保留每一条。不要编造一个雇主。如果该字段为 null 或为空，组织证据就是未知。未知不是零。未知不表示失业。未知不表示没有公司。

作者详情可能缺失。一次请求可以返回头衔为空或组织为空的行。把这些单元格留为未知。不要用评论文本填补它们。

只用一张评论表。为角色编码不需要第二个数据集。

设定一次小规模运行

1. 选择已知的公开帖子。收集之前先写下研究问题。写明收集时间。为每个帖子写明上限。当推广评论、帖子作者评论和组织账户会改变研究时，标出这些行。推广评论主要推广产品或服务。保留已标记的行。不要删除它们。如果你把帖子作者账户排除在占比之外，要说明这一点并更改合计。
2. 打开作者详情，收集一个小样本。2026年10月13日核对过的已保存任务是 LinkedIn Comment Authors with Public Profile Details。其已保存输入为：

{"startUrls": ["https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"], "maxComments": 100, "collectAllAvailable": false, "includeAuthorDetails": true}

把该示例帖子换成你要研究的公开帖子。第一次运行时，把 `maxComments` 设为 3。保持 `collectAllAvailable` 为 false。false 使数量上限保持生效。保持 `includeAuthorDetails` 为 true。

作者详情是与评论行分开的一次请求。一次成功的额外详情可能导致单独的计费事件。计费事件是一条收费记录。并非每次请求都会产生收费。详情字段仍可能返回为空。本文不写价格。

1. 保存评论行和本次运行的 OUTPUT。在为任何角色编码之前，先阅读每个帖子的 OUTPUT。

运行级 OUTPUT 包含 `savedRows`、`authorProfileRequests`、`authorDetailEvents` 和 `rowsWithAuthorDetails`。阅读它们，以查看记录了多少行和多少次详情请求。当详情缺失时，`rowsWithAuthorDetails` 可以低于评论数。不要把这些计数用作角色合计。不要把它们读成账单。

每个帖子有一条 `inputResults` 记录。在那里阅读这些字段：

• `status`
• `statusReason`
• `pageCommentCount`
• `publicRowsOnPage`
• `savedRows`
• `isPublicPageComplete`
• `isComplete`
• `stopReason`

使用该帖子 `inputResults` 内部的 `stopReason`。OUTPUT 根上的 `stopReason` 不是该帖子的上限状态。

`isPublicPageComplete` 为 true 表示已提取暴露的公开页面。这不表示已保存完整讨论。`isComplete` 为 false 表示已保存的收集不完整。上限、公开预览限制、来源限制或收费限制都可能导致这一结果。阅读每个输入的状态、原因和 stopReason。运行状态成功并不使该表完整。`pageCommentCount` 和 `publicRowsOnPage` 是页面计数。这些页面计数不是观察到的个人账户数。

2026年10月13日，一次有范围的检查从 1 个帖子保存了 3 条评论。它发出了 3 次作者详情请求。暴露页面计数为 4 时，上限停止了该次运行。对该帖子，`isPublicPageComplete` 为 true，`isComplete` 为 false，`stopReason` 为 `max_comments_reached`。这 3 条已保存行不是整段讨论。它们只表明可以返回公开的作者详情。它们不是角色报告。不要把它们用作分步演算示例。

建立两张表

保留一张评论表。给每一行自己的 `commentId`。

如果缺少 `commentId`，仍把该行保留为它自己的来源观察。给它一个你编制的标签，例如 `missing-comment-1`。绝不要合并两个空白的评论 id。绝不要因为评论文本相同就合并两行。文本相同不是同一条评论。

只有在确认类型之后，才建立个人账户表。

1. 阅读 `authorType`。
2. 只有当 `authorType` 为 `person` 时，才按标识符合并。
3. 优先用 `authorUrn` 或 `authorId` 作为安全键。
4. 如果这些标识符不存在，一个已核对的公开个人资料 URL 可以作为一个临时标签。要说明 URL 标签弱于稳定标识符。URL 标签不是未解析。
5. 未解析表示没有安全键。没有 `authorUrn`，没有 `authorId`，也没有已核对的个人资料 URL。当已存在已核对的 URL 时，不要只因为缺少稳定标识符就把一行称为未解析。
6. 绝不要按 `authorName` 合并行。
7. 绝不要把空白标识符彼此合并。

`organization` 账户留在单独的一组。把它们的标识符与个人标识符分开。它们不进入个人账户合计。在合计旁边写明它们的数量。

如果 `authorType` 为 `null`，不要把该行当作个人账户。如果该行也没有安全的个人键，它保持未解析。不要把它归到邻近的姓名上。

未知角色和未解析身份是不同的。未知角色表示你找到了个人账户，但头衔没有写明角色。该账户仍留在个人账户合计中。未解析身份留在合计之外。

为你能看到的头衔编码

计数之前先写编码手册。编码手册是一份简短的类别清单，以及每一类需要的头衔证据。

使用这条规则。

• `operations`：头衔写明运营工作。
• `technical`：头衔写明软件或工程工作。
• `marketing`：头衔写明营销工作。
• `mixed`：头衔写明上述职能中的不止一种，且规则无法选定一种。
• `unknown`：头衔缺失，或头衔没有写明职能。口号属于 unknown。

在类别旁边保存准确的头衔文本。使用整段已写明的职能。不要从口号推断职位。不要从评论语气推断角色。评论文本不是角色证据。

每个个人账户身份使用一个主要类别。这样占比各计一次。你可以在第二个字段保留额外标签。不要把这些标签加成更多账户。

当同一账户有相互冲突的文本时，保留两份带日期的头衔快照。为每份快照保留准确的证据文本。不要挑选能使图表更整齐的头衔。报告要声明一条规则，用来选定哪一次带日期的观察、也就是哪一份头衔快照，作为报告所用的头衔证据。如果无法使用该规则，主要角色仍为 `unknown`。只把 `conflict pending review` 用于单独的读者复核状态。不要把不同时间的角色编码为 `mixed`。只有当选定的头衔写明多个角色且编码手册无法选定一个角色时，才编码为 `mixed`。当选定的头衔没有显示一个明确职能时，编码为 `unknown`。

角色类别是你为已写明职能所加的标签。它不是已核对的资质。

先各计一次，再相除

在活动表中计数重复评论。在角色表中，每个观察到的个人账户身份只计一次。

分母是你用来相除的合计。分子是你要除的计数。占比是分子除以所写明的分母。

对角色报告，分母是观察到的个人账户身份数。组织行在其外。未解析行在其外。未知角色账户留在其内。

已知角色覆盖率使用第二份报告，而不是新的受众。其分子是主要角色不是 `unknown` 的个人账户身份。其分母是全部观察到的个人账户身份。`mixed` 不是 `unknown`。

你也可以只在已知角色组内展示占比。该视图的分母更小。把该分母写在表上。在旁边保留未知计数。不要把这些占比与更大分母得出的占比比较。账户没有变。合计变了。

请第二位读者用同一份编码手册为几条头衔编码。复核你们编码不同的行。这检查的是一致性。它不能证明该职位是真实的。

虚构的分步演算示例

本节中的帖子、标签、姓名、头衔和计数都是虚构的。它们不是 2026年10月13日的那次检查。它们不是真实的人。

一个编造的帖子产生 8 条评论行。虚构的 `commentId` 值为 `c1` 到 `c8`。这 8 行都没有空白的 `commentId`。个人行的个人标识符已核对。`c8` 没有安全键。

个人账户表：

`org1` 的 `authorType` 为 `organization`，并有 1 条评论。它留在个人账户表之外。`c8` 的 `authorType` 为 `null`，且没有安全键。它是 1 条未解析评论。绝不要把 `c8` 归到 `p4`。

这 8 条评论包含 4 个观察到的个人账户身份、1 个组织作者和 1 行未解析作者。不要说恰好有 6 个人。未解析行可能重复某个个人账户。`org1` 是组织。

角色占比以 4 个观察到的个人账户身份为分母。

运营占比是 1 除以 4。即 25%。同一计算使 technical、marketing 和 unknown 也各为 25%。这四个占比使用同一个分母，因此相加为 100%。

已知角色覆盖率以 3 为分子、以 4 为分母。3 除以 4 是 75%。未知账户仍可见，为这 4 个中的 1 个。

第二个视图只使用 3 个已知角色账户。每个已知组是 1 除以 3，约为 33.3%。在该视图旁边保留未知计数。该未知账户是 1，并且在这个分母之外。

不要把 33.3% 与 25% 比较。这些数字使用不同的分母。它们不是受众的变化。

评论活动是另一个合计。它加总为 8。

`p1` 和 `p2` 各写了 2 条评论。如果角色报告使用全部 8 条评论行，就会把这两个账户各计两次。用活动表衡量评论数量。账户构成以这 4 个个人账户身份为准。

虚构覆盖说明：上限是 8。观察到的来源页面计数是 12。在 `inputResults` 中，`stopReason` 为 `max_comments_reached`，`isComplete` 为 false。这份虚构说明不指定 `status` 或 `statusReason`。

决定：把这张 4 个账户的角色表保留为观察到的样本。只有研究需要更多覆盖时才继续收集。绝不要把这个样本称为全部 12 名参与者。不要把 12 读成 12 个个人账户身份。

虚构发现：在这个有上限的样本中，每个主要角色占 4 个观察到的个人账户身份的 25%。已知角色覆盖率是 75%。该发现只关于这个样本。它不描述全部客户。它不表明谁可以购买。

你要交出什么

交出这些项目。

• 个人账户表，每个账户一个主要角色。
• 编码手册，以及用作证据的准确头衔文本。
• 组织计数，位于个人账户分母之外。
• 未解析身份计数，并为任何缺失的 `commentId` 附上读者编制的标签。
• 来自 `inputResults` 的每个帖子的覆盖说明。
• 一条范围有限的发现，并写明分母和收集上限。

写明收集时间。不要用帖子的发布时间替换它。如果头衔或组织列表为空，显示未知。不要把未知变成零。

如果 `isComplete` 为 false，要说明该表不是整段讨论。如果两份头衔快照不一致，两份都显示。不要藏起你没有编码的那一份。