一个公开讨论面板和一份限定范围的评论导出,旁边是独立的汇总面板和一个待解决项托盘。

如果你需要回复文本,或需要通过特定评论的 URL 进行查询,请选择 HarvestAPI。HarvestAPI 文档

选择时,先明确你需要研究哪些人。顶层评论作者样本可以回答关于已观察到的作者的问题。但它无法代表讨论中的每个人、所有回复作者,或所有点赞者。

本对比由 Chronometrica 发布。产品事实依据的是 2026 年 10 月 20 日保存的文档证据。本文没有报告新的采集运行,也没有报告同等条件下的性能测试。推荐依据是文档所述的采集范围和输出结构。

先比较采集范围

Actor 是托管运行的采集程序。这 2 款产品都是 Apify 上的 Actor。在本次对比中,关键问题是文档所述的采集范围是否符合你的研究问题。下表汇总了已核查的产品事实。Chronometrica 文档、HarvestAPI 文档

先比较采集范围
选择依据ChronometricaHarvestAPI
来源范围公开帖子/动态 URL;顶层评论帖子或评论 URL
回复研究不采集完整的回复讨论串文档列有回复采集模式
作者详情可选的公开作者详情需查看其作者详情模式
覆盖情况核查在 `OUTPUT` 中单独记录每项输入的结果需核对输出是否符合研究需求

不要只按导出行数选择产品。一行可能代表一条直接评论、一条回复,也可能代表一项采集结果。这些统计单位回答的问题不同。先确定一次观察具体指什么,再比较包含这类观察的输出。

为什么 Chronometrica 适合构建公开评论作者样本

Chronometrica 接受 1–100 个公开 LinkedIn 帖子/动态 URL。如果多项输入指向同一个受支持的帖子标识,它会移除重复输入。它还会保存唯一的公开评论 ID。这些功能有助于避免重复计算同一来源或同一条已保存评论。Chronometrica 文档

这些检查的用途不同。移除重复帖子输入,可以避免来源列表重复。唯一评论 ID 可以避免评论观察记录重复。但这 2 种检查都不能把评论数变成人数。同一作者可以发布多条评论,因此作者列表需要单独核查。

可选设置 `includeAuthorDetails` 用于请求已保存的去重作者的公开详情。它默认为 `false`,启用后可能额外触发单独的作者详情计费事件。当这些详情有助于回答研究问题时,再启用此设置。Chronometrica 文档

Chronometrica 最适合能够使用公开顶层评论样本、且需要明确说明样本范围的研究。你可以保留观察到的评论,建立独立的作者列表,并随导出文件保存采集限制说明。这样,审核者就有清楚的依据,判断样本能够支持哪些结论。

这不能证明你已观察到所有讨论参与者,也不能证明公开个人资料对应的人就是合格的销售线索。这些结论需要更多证据。

何时应因回复需求而改变选择

HarvestAPI 接受帖子和评论 URL。对于帖子输入,文档说明每条根评论的结果中最多包含 5 条嵌套回复。对于评论 URL,`scrapeReplies` 可以将回复作为独立结果返回。其 `postedLimit` 和作者详情模式也可能影响选择。请核对文档中的设置是否符合你的需求。HarvestAPI 文档

比较总行数前,先统一根评论和回复的统计单位。根评论就是顶层评论。附属于根评论的回复会增加文本观察记录,但不一定增加不同的人。

Chronometrica 不采集完整的回复讨论串。如果你需要讨论中的每条评论和回复,它就不符合要求。取消数量上限也不会改变它的采集范围。Chronometrica 文档

明确你需要观察哪些人

本对比背后的买方需求,是查找在买方 LinkedIn 帖子下发表评论或点赞者的个人资料。支持这一需求的证据是已保存的公开搜索摘要,而非完整的讨论文字记录。它能证明存在研究需求,但不能证明已取得经过核实的采集结果。公开需求

选择 Actor 前,先用一句话定义研究总体,也就是研究必须覆盖的人群。例如,你可能需要选定的 3 篇帖子中可见顶层评论的作者。另一项研究可能需要回复作者、点赞者,或这 3 类人。

将这些人群分开。评论导出不能证明你已获得完整的点赞者列表。顶层评论样本不能确定全部回复作者。如果回答问题必须包含某个缺失人群,就应停止并调整采集计划。

同时明确你打算提出的结论。“这些作者出现在采集样本中”所需的证据,少于“这些人就是所有参与者”所需的证据。只要符合现有证据,范围较小的结论仍然有用。

如需进一步了解这一区别,请阅读公开 LinkedIn 评论导出能代表完整讨论吗?。

从经过核查的小规模输入开始

Task 是为 Actor 保存的一组输入预设。打开公开作者详情 Task,运行前先检查其实际设置。

已保存的证据确认,该 Task 页面当时可以公开访问。页面检查不能确认它当前保存的输入内容。请以该预设为起点,并自行检查以下设置:

  1. 将已保存的 URL 替换为你要采集的公开帖子 URL。
  2. 首次检查时,为 `maxComments` 设置较小的上限。
  3. 如果需要公开作者详情,将 `includeAuthorDetails` 设为 `true`。
  4. 开始运行前,检查其余设置。

此示例中的字段和值已通过本地检查,符合已保存的公开 JSON Schema。JSON Schema 定义允许使用的输入字段和值。这项检查确认的是输入格式,不能确认运行时来源是否可用。Chronometrica 输入文档

json
{
  "startUrls": [
    "https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"
  ],
  "maxComments": 10,
  "includeAuthorDetails": true
}
从经过核查的小规模输入开始

将示例 URL 替换为你选定的公开来源。该 URL 是文档中的示例采集目标,不能作为新采集结果的证据。

经过核查的输入规范允许 `startUrls` 包含 1–100 项,`maxComments` 则允许设为 1–1,000 之间的整数。后者是每篇帖子的上限。设为 10 表示请求一个有数量上限的样本,并不保证保存 10 条评论。Chronometrica 输入文档

用首批样本检查已保存的文本和作者标识符是否支持你计划进行的分析。如果未做这项检查就增加采集量,可能只会得到更大的导出文件,却仍无法回答正确的问题。

描述结果前,先查看覆盖情况

Chronometrica 将评论行与 `OUTPUT` 中的输入结果和覆盖结果分开记录。汇总评论前,先阅读每项输入的结果。覆盖记录和停止原因有助于解释采集为何结束。Chronometrica 输出文档

按以下步骤做一次简要验收检查:

  1. 确认每条结果属于哪篇输入帖子。
  2. 通过公开的 `commentId` 值识别已保存的评论行。
  3. 在相关值公开可用时,通过 `authorUrl` 或 `authorId` 匹配作者。
  4. 对缺少标识符的记录,保留其未解决状态。
  5. 阅读该项输入的覆盖结果和停止原因。
  6. 判断观察到的样本能够支持哪些结论。

不要将输入状态记录当作评论。同样,不要直接比较页面显示的讨论总数与已保存的顶层评论行数。它们可能采用不同的统计单位,也可能对应讨论中不同的可见部分。

`collectAllAvailable` 设置会取消评论数量上限。但采集仍可能因公开来源的可用范围、费用上限、时间限制或故障而停止。该设置不能证明公开页面展示了每条评论。Chronometrica 采集限制

如果最初要求是获取每条评论,就不要将可获取的公开样本称为完整导出。如果“全部评论”的要求涉及公开顶层来源之外的内容,Chronometrica 就不符合该要求。

公开作者字段、日期和反应次数可能无法获取。请保留这些未知值。反应次数缺失不代表反应次数为 0,日期缺失也不能确定评论何时发布。Chronometrica 输出文档

虚构的选择示例,计算结果已核对

以下示例为虚构内容。它不是 Actor 测试、实时数据集、买方引语,也不是实测费用结果。

一名研究者从 1 篇公开帖子采集预览样本。样本包含 10 行顶层评论,来自 7 位不同的公开作者。研究者成功获取了其中 5 位作者的补充详情,另外 2 位作者的补充详情仍待查明。

研究者分别报告以下 3 项发现:

  • 样本包含 10 条观察到的顶层评论。
  • 这些评论来自 7 位不同的已观察作者。
  • 5 位作者有可用的补充详情;另外 2 位作者的补充详情仍待查明。

计算很简单:7 位已观察作者减去 5 位有补充详情的作者,还有 2 位作者的补充详情待查明。10 行评论不代表 10 个人。尚未查明这 2 位作者的补充详情,也不代表这些作者没有出现在评论样本中。

假设研究问题还需要这些评论下的 8 条回复。顶层评论样本就无法回答该问题。因此,研究者转而评估 HarvestAPI 的回复模式。HarvestAPI 文档

这 8 行可能获取到的回复属于另一种统计单位。未检查作者前,不能将它们计为新增的 8 个人。部分回复可能来自已在顶层评论样本中的人,多条回复也可能来自同一个人。

如果最初的问题只涉及这 7 位已观察到的顶层评论作者,那么这个限定范围的样本可能已经足够。如果问题涉及所有参与者,同一样本就不够。选择应依据必须覆盖的人群,而非文件大小。

将记录分为 4 类导出

保留 4 张表,或将记录明确分为 4 组。每组用途不同。这种结构能让他人检查你的工作,无需猜测每行的含义。

第 1 张表保存已采集的评论观察记录。每条评论都应保留来源帖子和 `commentId`。公开作者标识符可用时,也应保留。保留缺失值,让后续分析能够区分未知信息与实际观察到的 0。

第 2 张表保存去重后的已观察作者。使用公开标识符,从已保存评论中建立这张表。同一已识别作者即使发布了多条评论,也只在作者表中计为 1 人。身份缺失的记录应保持未解决状态。不要假定所有空值都属于同一个人,也不要假定它们分别属于不同的人。

第 3 张表保存作者详情获取结果。保留已观察作者与补充详情之间的关联。即使没有补充详情,作者仍可能是已观察到的评论者。如果将成功获取详情的人数当作作者总数,就会漏掉证据中已经出现的人。

第 4 张表保存每篇帖子的公开内容覆盖情况。保留每项输入的结果、停止原因和采集背景信息。导出时保留帖子来源和采集时间。这些记录说明应如何理解样本,并非评论测量数据。

这样分开记录,也有助于后续解读。例如,你可以检查公开作者信息,而不会无意中改变已观察评论的数量。如果下一步涉及作者角色,请参阅评论作者角色指南,并保留未解决的个案。

取得样本后,判断是否继续

扩大采集规模前,检查首次导出是否回答了既定问题。确认你能将每条已保存评论追溯到所属帖子,识别重复出现的作者,并解释详情缺失的情况。同时确认你理解每项输入的覆盖记录。

然后判断增加观察记录是否会改善研究。更大的顶层评论样本可以增加有关已观察顶层评论作者的证据。但如果问题涉及回复作者或点赞者,扩大顶层评论样本也无法解决采集范围与问题不符的问题。

验收规则应当具体。例如,一项研究可以接受部分作者的补充详情仍待查明这一情况,但仍要求每篇帖子都有明确的来源和覆盖记录。另一项研究可能要求,凡计入人数的观察记录,都必须有作者标识符。这些都是研究选择。请在汇总结果前明确说明。

不要将采集成功当作销售价值的证明。公开作者链接只能提供访问公开个人资料的途径。销售线索资格评估需要独立的标准和支持证据。

来源和延伸阅读

作者 Chronometrica · 更新日期

返回顶部 ↑