Chronometrica 与 API Dojo 对比：无需抓取帖子，获取 TikTok 账号资料

先确定应用需要什么结果

一位开发者在关于采集 TikTok 数据的公开提问中描述了一款应用：此前的采集方式失效后，应用仍需要获取公开账号资料。这引出了一个实际问题：哪项服务适合已有的账号列表？但这不能证明哪项服务今后会更可靠。

选择 Actor 前，先写清所需结果。对于账号列表，结果可以包括稳定的账号标识符、显示名称、粉丝数和观测时间。标识符是用于将记录与账号匹配的值。观测时间说明这些资料是在何时核查的。

如果需要帖子，采集任务就会改变。如果应用必须展示近期配文、比较帖子或按帖子日期控制采集范围，账号资料记录就无法提供所需依据。视频总数并不包含视频本身或与视频相关的文字。

明确这一区别，也能帮助你制定清楚的验收规则。你可以检查返回的账号资料是否包含应用所需的字段，无需根据返回字段的总数来判断结果。

对于仅采集账号资料的任务，应将成功定义为正确匹配账号并取得所需资料。为每个未确认的输入保留记录。缺失结果必须保持可见，这样应用才能说明当前数据的局限。

两个 Actor 的采集约定各适合什么需求

Chronometrica 通过 `startUrls` 接收公开 TikTok 账号主页 URL 或账号名。文档规定，每个唯一输入会对应一条匹配的扁平结果。扁平结果将各个账号资料字段存放在同一条记录中。该 Actor 不采集视频或粉丝列表。这种仅采集账号资料的约定适合已提供的账号列表。Chronometrica 采集约定、输入模式。

API Dojo TikTok Profile Scraper 在以帖子为主的工作流程中返回账号资料。其公开使用规则要求账号至少有10篇帖子，并提醒不要将结果数量上限设得过低，或将日期边界设得过近。应将这些要求视为适用条件；它们不能证明每次针对空账号的运行都会失败。API Dojo 采集约定。

这些是采集约定的差异，并非实测性能差异。设置任务前，请查看当前的 Chronometrica 输入模式和 API Dojo 输入模式。

选择让记录可用的账号资料字段

Chronometrica 文档中的字段涵盖账号身份、部分公开资料和观测状态。相关字段包括 `input`、`channelId`、`secUid`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、`followersCount`、`followingCount`、`likesCount`、`videosCount`、`countPrecision`、`status`、`statusReason` 和 `observedAt`。缺失值保留为 `null`，表示没有可用值。Chronometrica 采集约定。

为每个必需字段明确用途。例如，应用可以用账号标识符匹配记录，用 `displayName` 标注账号，用 `followersCount` 展示公开粉丝数。应用可以存储其他资料，而不必将这些资料设为记录可用的必要条件。

区分身份信息与显示标签。显示名称便于人们阅读列表，但不能确认账号身份。账号名可能会改变。将新资料关联到应用中的现有记录前，请检查返回的身份字段。

也要保留原始输入。这样，你才能将返回记录与发起核查时使用的账号名或 URL 对应起来。当返回的显示标签与应用之前保存的标签不同时，这一点尤其重要。不要在未检查账号匹配情况时，直接接受这种差异。

解读数量数据时，要注意其局限。粉丝数不能识别具体粉丝，也不能衡量受众质量。视频数不能说明帖子质量或创作者是否合适。如果使用 `accountRegion`，应将其视为一项公开账号信息，而不是用户居住地的证明。Chronometrica 采集约定。

只针对应用能使用的资料设定要求。如果应用需要账号身份和粉丝数，缺少简介不一定会让记录不可用。验收规则应在开始采集前写明这一点。

设置仅采集账号资料的输入

Chronometrica 当前的公开输入模式只有1个输入字段：`startUrls`。它接收需要核查的公开账号主页 URL 或账号名。无需添加帖子数量上限、日期筛选条件或仅采集账号资料的开关。该 Actor 的采集约定本就仅限账号资料。Chronometrica 输入模式。

这个最简示例已通过输入模式检查。但它没有实际运行，也未测试示例账号当前是否可访问。请将 URL 替换为应用需要核查的公开账号主页地址。

{
  "startUrls": [
    "https://www.tiktok.com/@mrbeast"
  ]
}

TikTok Profile Data API Dataset Task 提供已保存的输入预设。Task 是为 Actor 保存的输入预设。使用前请检查其输入，确保其中包含你打算核查的账号。

完全相同的重复输入只会核查1次。如果应用列表含有重复条目，请注意这一规则。先决定应用是按唯一账号还是按自身的列表记录计算覆盖率，再在报告中明确这一选择。Chronometrica 采集约定。

采用简明的验收方法

使用以下方法，将返回的资料转为应用可用的记录。先明确所需结果，再逐一判断每个提供的账号是否符合要求。

1. 明确必需字段和帖子需求。写下一条简短规则，让其他人也能将其用于同一结果。例如，要求账号身份匹配且粉丝数有值。说明是否需要帖子正文、历史帖子或帖子日期。这决定了仅采集账号资料的 Actor 能否完成任务。
2. 让每个提供的输入始终关联到对应的应用记录。采集前保存原始账号名或 URL。如果应用有自己的记录标识符，也应保留。不要只用返回的显示名称，将资料关联到列表。处理重复输入时，不要丢失依赖这些输入的列表记录。
3. 关联资料前，先检查账号身份。将返回的身份字段与应用已有的信息比较。有稳定的账号标识符时，优先使用。如果无法确认匹配，就将记录保留为未确认。仅凭一个看似合理的名称，不足以将新采集的数量数据关联到现有账号。
4. 结合查看各个观测字段。检查 `status`、`statusReason`、`countPrecision` 和 `observedAt`。这些字段有助于评估返回资料及其局限。不要自行解释尚未核查的字段值。判断可用的数量精度是否满足应用规则。将未确认的输入保留在列表中，并保留其实际返回状态。Chronometrica 采集约定。
5. 区分0、数据缺失和是否达标。明确返回的0是一个数量。数量缺失表示没有可用值。是否达标则是应用对该记录是否符合规则的判断。这些是不同的概念。不要为了方便计算或界面开发，就将缺失的粉丝数填为0。
6. 将资料与观测时间一起保存。当前数量只能说明本次观测的情况，不能证明过去的数量。如果应用需要比较不同时期的数量，请分别保存后续观测结果。如果刷新失败后仍保留旧值，应保留其原始时间，以免应用将其显示为最新数据。
7. 需求改变时，重新评估采集工具的选择。一条可用的账号资料记录，仍可能缺少新功能所需的依据。如果某项功能需要帖子正文或帖子表现数据，请先定义必需字段，再选择帖子采集工具。不要根据账号汇总数量推断缺失的依据。

首次核查的规模应足够小，便于人工检查。将实际返回字段与验收规则比较。如果缺少必需字段，先记录这一结果，再添加更多输入。扩大列表规模无法解决验收规则不清楚的问题。

关于缺失和不可用状态的更多说明，请参阅 TikTok 账号资料访问状态指南。这里的核心选择仍然是：应用需要账号资料，还是需要帖子。

用虚构的应用账号列表演示

本节的整个示例均为虚构。它描述的是应用提供的账号列表，不是 Actor 运行结果、基准测试或客户成果。它也不能证明某个特定空账号的数据可以被采集。

这个虚构应用提供了3个账号：A、B 和 C。应用预先声明的规则要求账号身份匹配且粉丝数有值。它不要求帖子正文，也不要求最低帖子数量。

账号 A 有匹配的稳定标识符、名称、有值的粉丝数和60篇公开帖子。它符合应用规则，因为账号身份已匹配，且必需的粉丝数有值。

账号 B 有匹配的稳定标识符、名称、有值的粉丝数，观测到的视频数为0。它也符合规则。应用不要求帖子，因此视频数为0不会使其不达标。

账号 C 无法确认。应用没有可靠依据来确定其最新粉丝数。C 以未确认状态保留在列表中。应用不得将 C 标为一个空账号，也不得将其粉丝数设为0。

提供的3个账号中，有2个符合应用规则。因此，列表达标覆盖率为：

`2 / 3 × 100 = 66.67%`

这里的列表是指应用提供的账号列表。覆盖率是指列表中符合预先声明规则的账号所占比例。这个百分比只是应用数据示例，不是采集工具的成功率。

分母包含 C，因为 C 属于原始列表。如果应用在计算前移除未确认账号，就会基于一个更小的列表报告覆盖率。这会掩盖原始列表中的数据缺口。

Chronometrica 仅采集账号资料的约定符合这一虚构需求。B 说明了为什么必须区分帖子数为0与账号资料缺失。但它不能证明，对真实空账号进行一次新的查询就一定能成功。每个真实输入都需要记录各自的结果。

所需依据改变时，调整选择

假设这个虚构应用后来需要最近10篇帖子的配文。所需结果已经改变。此时，API Dojo 以帖子为主的工作流程就值得考虑。请根据新需求检查其当前采集约定和输入设置。API Dojo 采集约定、输入模式。

保留原本需要的账号资料字段，并增加明确的帖子需求。说明该功能必须接收哪些帖子数据，以及哪些日期控制重要。然后根据所需结果评估采集工具。

已保存的视频数无法回答有关配文的问题。当前粉丝数无法证明首次保存观测结果之前的粉丝增长情况。应根据功能所需的依据选择采集方式，而不是根据 Actor 列出的字段数量。

对于原先仅采集账号资料的任务，采集约定将范围限定为账号资料，这仍是选择 Chronometrica 的有力理由。它直接对应所需的工作单元：为一个已知输入返回一条匹配的账号资料记录。