Chronometrica 与 Apify Facebook Pages Scraper：哪个更适合你的主页数据集？

先明确你需要的主页数据集

一位读者在公开讨论中提问：为什么 LinkedIn 和 Facebook 等平台不通过 API 让公开数据更容易获取？API 是软件请求数据的一种方式。讨论涉及 Facebook 商家主页数据和公开活动。它反映了广泛的数据获取问题，而不是对某一款采集器的具体需求。读者讨论

主页 Actor 解决的是其中较小的一部分问题：从已知的公开主页地址采集记录。选择工具前，需要明确输出要求。名称和计数列表的用途，与联系人列表或营业时间表不同。

先写下数据集必须支持哪项决策。例如，你可能需要先确认每家商家对应哪个主页，再导入计数。也可能需要为研究项目获取联系方式。这些需求对应不同的验收规则。

最初的数据获取问题，并不能证明精度标签对每位买家都重要。当你的工作流程必须区分精确计数与精度较低的显示值时，精度标签就很重要。选择工具前，应明确这项要求。

对比输出规范

用下表确定先检查哪些内容。所选工具的规范应明确涵盖你的工作所需的每个字段。

表中的产品信息来自上述日期核查的公开文档。文档未说明的功能仍属未知。Chronometrica Actor · Apify Facebook Pages Scraper

阅读表格时，应从所需输出出发，再看工具是否匹配。如果某个字段必不可少，而产品承诺中没有提到它，就需要进一步核查。无需据此推断另一款工具缺少该字段。

如果范围较小的规范能涵盖全部工作，它就适合你的需求。当额外字段能影响决策或省去后续采集步骤时，它们就有用。扩充数据集前，应写明每个字段的用途。

定义一条合格主页记录的标准

运行 Actor 前，先写一份简短的字段清单。将识别主页所需的字段与衡量主页所需的字段分开。

身份字段帮助你判断记录描述的是哪个主页。测量字段保存从该主页观测到的值。观测时间说明这个值何时采集。结果状态说明采集结果是否适合使用。

需要核查记录时，按以下步骤操作：

1. 明确每条记录必须能追溯到哪个输入主页。
2. 如果能确定主页身份，则要求提供规范主页地址。
3. 列明任务所需的计数或其他测量值。
4. 定义用途所能接受的精度。
5. 设定观测结果的最长可接受时限。
6. 规定不完整或失败的结果如何进入审核。

规范地址是返回记录中用于识别主页的标准地址。即使最初提供的地址不同，它也能帮助你比较相应记录。

验收规则应依据任务制定。粗略筛选名单可以接受精度较低的计数。依赖细微差异的计算可能需要更精确的值。在查看结果前就设定规则。这样可以避免为了适应碰巧返回的值而更改规则。

还应区分必需字段和可选字段。缺少可选字段时，记录仍可能有用。缺少必需字段则意味着记录暂时无法支持预期决策。

将提供的输入与主页身份分开保留

提交的地址与验收时确认的主页身份各有用途。审核时，应同时保留两者供检查。

Chronometrica 的文档列出了提供的输入和规范地址 `channelUrl`。其 `startUrls` 输入结构接受 1 至 1,000 个公开 Facebook 主页或个人主页 URL。重复输入只检查 1 次。每个唯一输入都会生成 1 行结果，并计入用量。Chronometrica Actor

这些规则说明了输入的处理方式。它们不能证明每个唯一地址都代表一家不同的商家。即使地址不同，也可能需要先核查身份，才能将对应记录视为不同实体。

应区分以下 3 个总数：

1. 提供的地址数量。
2. 已处理的唯一输入数量。
3. 审核后通过验收的主页身份数量。

第 1 个总数用于了解提交的列表。第 2 个总数用于核对采集结果。第 3 个总数用于说明可用数据集的规模。

对每行返回结果，先追溯到提供的地址。然后检查 `channelUrl`。根据现有的身份信息，检查该主页是否与目标实体相符。如果仍无法确定，就将该行保留为待审核。

本文对比的是建立数据集前应选择哪种采集规范。如需了解如何核查现有目录中的主页记录，请参阅如何核验本地商家目录中的 Facebook 主页记录。

结合精度和时间读取计数

将计数用于计算前，需要了解其相关信息。Chronometrica 的输出规范包含 `countPrecision` 和 `observedAt`。检查打算使用的测量值时，应同时检查这两个字段。Chronometrica Actor

`countPrecision` 说明返回计数的精度限定。应按文档解释返回值的含义。不能仅因一个值可以存为数字，就认定它是精确值。

`observedAt` 提供观测时间。它帮助你判断记录是否足够新，能否用于当前任务。它不能证明更早的数值变化历史。

执行以下 3 项检查：

1. 确认测量值存在。
2. 确认其精度符合规则。
3. 确认其观测时间未超出规定时限。

导出或导入数据时，应同时保留来源值及其限定信息。如果保留计数却丢弃精度，后续使用者可能会高估其确定性。如果丢弃观测时间，他们就无法判断数据的新旧。

缺失值应保留为未知。0 会影响总数、平均值、排名和筛选结果。只有返回的测量结果支持 0 时，才能使用 0。空白或不可用的计数不能支持这一结论。

比较不同主页时，应确定是否允许观测时间不同。规则可以允许一个采集时间范围，但必须明确说明这个范围。Actor 为验收决策提供依据；具体规则由任务决定。

导入前审核结果状态

返回的每行记录都描述一次采集结果。仅有这一行，并不能证明所有必需数据都已获取。

Chronometrica 的文档列出了用于结果审核的 `status` 和 `statusReason`。应按文档说明解读返回状态。如果原因字段解释了需要关注的结果，也应检查该字段。Chronometrica Actor

内部审核可分为 3 组。这些是工作流程标签，不是 Actor 承诺返回的状态值：

1. 通过：身份符合要求，必需值齐全，精度和时间均符合规则。
2. 待审核：使用前需要核查身份、补充解释或作出其他决定。
3. 暂缓导入：现有依据不足以支持该行记录的预期用途。

应在工作记录中保留待审核和暂缓导入的行。它们说明了提交列表与已验收数据集之间的差异。过早删除这些行，可能让不完整的采集看起来已经完成。

核对每个唯一输入是否都有对应结果行。然后核对每行结果是否都有内部审核决定。报告最终验收总数前，应查清无法解释的缺口。

如果之后重复采集，应保留足够的相关信息，以区分早期结果与后续观测。这是管理自身记录的规则，并不意味着 Actor 的文档范围包含历史数据采集。

虚构示例：20 个主页地址

此示例为虚构内容。它不是真实数据集、产品测试、买家引述，也不是成本实测结果。

一个目录团队提供了 20 个公开 Facebook 主页地址。导入前，团队需要规范身份信息、精度符合要求的观测计数、观测时间和结果状态。团队不需要更全面的商家资料。

团队选择 Chronometrica，因为其文档规定的可核查记录规范符合这些要求。团队准备了一张验收表，为每个输入地址预留位置，并设置记录审核决定的列。

首先，团队检查提交列表中的重复输入。核对返回行时，使用去重后的唯一输入总数。团队不会假设 20 个输入地址最终会成为 20 个通过验收的实体。

接着，团队逐一检查 `channelUrl` 是否对应目标商家。团队检查必需计数，读取 `countPrecision`，并根据时限规则检查 `observedAt`。然后审核 `status` 和相关的 `statusReason`。

团队将未知计数保留为未知，并将身份未确定的记录留待审核。只有完成这些检查后，才报告通过验收的实体数量。此示例没有虚构成功率或最终验收总数。

如果团队之后需要营业时间或评分，就应先评估 Apify Facebook Pages Scraper 提供的更丰富主页详情，再选择采集规范。Apify Facebook Pages Scraper

从 Task 开始，并检查输入

Task 是为 Actor 保存的输入预设。已发布的 Facebook 主页数据 API 数据集 Task 可作为这一工作流程的起点。

核查时，该 Task 页面可以访问。检查记录了 HTTP 200、成功的页面响应以及预期的 Task 标题。这项检查不能确认当前保存的输入。运行前，应填入计划使用的输入，并依据 Actor 当前的输入结构定义进行检查。

以下最小输入已通过基于缓存公开结构定义的静态检查：

{
  "startUrls": [
    "https://www.facebook.com/MrBeast/"
  ]
}

静态检查用于评估输入结构。适用时，它会检查字段名称、必需字段、允许的选项、列表长度、文本格式和数值限制。这些检查不能证明示例主页当前可访问，也不能证明采集会返回符合验收要求的数据。请将示例地址替换为你计划使用的公开来源。Chronometrica Actor

按以下简短步骤操作：

1. 写明必需字段和验收规则。
2. 准备已知的公开主页地址。
3. 依据当前输入结构定义检查输入。
4. 选取一小组能代表预期来源的地址运行采集。
5. 审核身份、精度、时间和结果状态。
6. 返回记录符合规则后，再扩大采集范围。

这组小规模采集应帮助你评估自己的工作流程。记录提交了什么、返回了什么，以及每行为何通过验收或被暂缓导入。有效的试运行应在大规模导入前回答这些问题。