# Chronometrica 与 Novi：TikTok 账号资料字段和 Actor 事件费用

如果 Chronometrica 的扁平化公开账号资料字段能满足你的需求，而且你重视其列出的较低 Free 套餐 Actor 事件费用，就选择 Chronometrica。如果 Novi 更大的原始用户对象能提供某个必需字段，而 Chronometrica 的规范无法提供，就选择 Novi。先核查必需字段。较低的事件费用无法替代必需的事实。请参阅 [Chronometrica 规范](https://apify.com/chronometrica/tiktok-channel-scraper)和 [Novi 规范](https://apify.com/novi/tiktok-user-info-api)。

本比较由 Chronometrica 发布，Chronometrica 也是文中 Chronometrica Actor 的开发方。Actor 是一种托管的数据采集程序。本指南使用了于 2026 年 10 月 20 日核查的公开规范和 API 定价记录。推荐依据是所列的 Free 套餐费率。这些费率不能确定总账单，也不能证明性能优势。请参阅 [Chronometrica 定价记录](https://api.apify.com/v2/acts/chronometrica~tiktok-channel-scraper)和 [Novi 定价记录](https://api.apify.com/v2/acts/novi~tiktok-user-info-api)。

本指南所回应的公开提问，关注的是如何在自建采集程序和公开 TikTok 账号资料服务之间做选择。提问也涉及服务稳定性，但没有询问哪种服务最便宜。我们将事件费用视为选择服务时的一个因素。本比较没有测量稳定性。[公开讨论](https://www.reddit.com/r/DevOpsLinks/comments/1vgwqze/what_do_you_think_works_for_pulling_public_tiktok/)

对于已有公开账号资料清单的开发者，实用的操作顺序很简单：明确所需数据，核查各项输出规范，再根据有核查日期的费率建立费用模型。输出规范说明服务提供哪些字段，以及这些字段的含义。

## 先明确应用程序需要哪些字段

写下应用程序必须如何使用每份账号资料。然后列出完成这些操作所需的字段。这样可以让比较始终围绕明确的需求进行。

在一个虚构的账号资料目录中，必需字段可能包括账号名、显示名称、账号资料 URL、简介和粉丝数。更新已存记录的流程，可能还需要身份字段、观测时间和明确的状态。这些只是需求示例，并不说明两项服务都提供相同的值。

将必需字段与有用的附加字段分开。缺少必需字段会使某项必要操作无法完成。附加字段可以补充背景信息，但缺少它不会阻止该操作。在查看费用差异之前，先做出这一区分。否则，低价可能让不完整的结果看起来已经足够。

为每个必需字段记录以下 3 项内容：

1. 含义：该字段必须代表什么事实？
2. 验收规则：应用程序可以使用哪些值？
3. 缺失值规则：该事实未知时，必须如何处理？

不要只依赖字段名称。名称相似的 2 个字段，可能代表不同的事实，也可能使用不同的格式。在将任一字段映射到已存记录之前，先核查文档中说明的含义。

还要明确什么才算 1 条可用结果。应用程序可能要求确认账号身份，并获得所有必需字段。也可能接受部分记录，前提是其状态能说明缺失的信息。这 2 种规则都可能合理。比较结果数量之前，先确定规则。

让每项需求都对应其用途。如果应用程序需要匹配已有记录，就明确匹配时使用的字段。如果需要显示计数，就规定如何显示未知值或精度有限的值。这样，后续核查就有明确依据，也便于重复执行。

## 对照必需字段核查双方的输出规范

Chronometrica 文档所列的账号资料输出包括 `input`、`channelId`、`secUid`、`shortId`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、公开计数、`countPrecision`、`status`、`statusReason` 和 `observedAt`。它采集账号资料，不采集历史帖子或粉丝列表。[Chronometrica 输出规范](https://apify.com/chronometrica/tiktok-channel-scraper)

如果这些账号资料事实及其背景信息能满足需求，这种扁平化输出就很适合。扁平化输出会直接提供各个具名字段。核查每项必需事实是否在输出中有文档明确说明的对应字段。仅凭可用字段的数量，无法回答这个问题。

Novi 接受用户名、用户 ID 和 URL 输入，并返回一个更大的原始用户对象。原始对象保留了更广泛的源数据结构。请核实具体所需的字段及其含义。[Novi 规范](https://apify.com/novi/tiktok-user-info-api)、[Novi 输入结构](https://apify.com/novi/tiktok-user-info-api/input-schema)

某项具体需求可能必须依靠更广泛的输出才能满足。同时，你也需要明确应用程序会使用其中哪些部分。仅凭输出更大，不能证明它能为你的清单提供更好的结果。

如果文档没有明确说明某个必需字段，就将其记为待确认。文档未说明某个字段，不代表服务没有该字段。字段名称相似，也不代表两者匹配。在依据费用选择服务之前，先解决这个问题。

保留一份简短的字段映射表。将应用程序字段与文档中的源字段、字段含义及验收规则并列记录。检查少量结果时，使用这份映射表。它能为接受输出或调查缺口提供明确依据。

## 保留让账号资料可用的背景信息

账号资料中的值需要背景信息。应保存其观测时间，并记录结果是否完整到足以满足你的用途。Chronometrica 提供 `observedAt`、`status`、`statusReason` 和 `countPrecision`。导入账号资料事实时，应按照文档规定的含义使用这些字段。[Chronometrica 规范](https://apify.com/chronometrica/tiktok-channel-scraper)

将缺失的计数与计数为 0 的情况分开。0 表示计数确实为 0。缺失值表示计数未知。用 0 替代未知值，可能在没有证据的情况下改变报告、筛选结果或提醒。

也要保留计数精度。精度说明一个值有多精确。如果计数的精度有限，就不要将其显示为精确测量值。应用程序中显示或比较计数的部分，应能获取精度信息。

确定部分结果应如何影响已存记录。一种可行的应用规则是：当最新一次尝试未能确认某个值时，保留先前的已知值。如果使用这条规则，就要保留先前值的观测时间。不要让旧事实看起来像是刚刚观测到的。

还要将最新一次尝试的状态与先前的观测分开保存。这样，应用程序就能区分过去的已知值与最新采集确认的值。缺失值规则应说明应用程序可以使用哪一个值。

如果你使用账号地区值，该值也不能证明一个人的居住地。先明确应用程序需要什么事实，再判断源字段能否支持该事实。

这些规则会影响结果是否可用。如果应用程序无法区分新近观测到的事实与尚未确认的值，仅有正确的字段名称还不够。相关指南 [TikTok 账号资料访问状态与缺失值](/zh-Hans/articles/%E4%BD%BF%E7%94%A8%E7%BC%BA%E5%A4%B1%E6%95%B0%E6%8D%AE%E5%89%8D%E6%A0%B8%E5%AF%B9tiktok%E4%B8%BB%E9%A1%B5%E7%8A%B6%E6%80%81/)对此有更详细的说明。

## 使用最新生效的 Actor 事件费率

核查的 2 份公开 API 记录都使用 `PAY_PER_EVENT`。这种定价方式为具名事件列出费用。事件是定价记录中标明的可计费操作。应选择最新生效的 `startedAt` 记录，而不是历史记录中的第一条。对 2 个 Actor 使用相同的套餐级别。

本次核查的 Chronometrica 当前记录自 `2026-07-16T22:51:35.105Z` 起生效。Free 套餐列出的费用为每份可用账号资料 $0.0015。其当前事件列表不包含 Actor 启动事件。[Chronometrica 公开 API 定价](https://api.apify.com/v2/acts/chronometrica~tiktok-channel-scraper)

本次核查的 Novi 当前记录自 `2026-08-16T17:08:03.534Z` 起生效。Free 套餐列出的费用为每条结果 $0.0055，另加每次启动 $0.001。[Novi 公开 API 定价](https://api.apify.com/v2/acts/novi~tiktok-user-info-api)

这些记录于 2026 年 10 月 20 日核查。Chronometrica 的 README 中包含旧价格，与其 API 记录不同。本比较使用上述有生效时间的 API 费率。不要混用历史记录与当前费率。

将计算出的金额称为 Actor 事件费用。此项限定范围的计算不包含平台使用费用。不得将结果标为总账单。

记录事件名称、计费单位、费率、套餐级别、生效时间和核查日期。这样便于复核计算。在将其用于当前决策之前，再次核查最新生效的记录。如果费率发生变化，就更新计算。

## 算术已经核对的虚构示例

这是一个虚构的费用模型，不是实际账单、基准测试或客户结果。假设每个 Actor 在 Free 套餐下恰好返回 100 份可用且匹配的账号资料。假设没有其他结果事件。表格的 2 行之间只有运行次数不同。

| 虚构工作量 | Chronometrica Actor 事件费用 | Novi Actor 事件费用 | 差额 |
| --- | --- | --- | --- |
| 100 条可用结果，运行 1 次 | 100 × $0.0015 = $0.150 | (100 × $0.0055) + (1 × $0.001) = $0.551 | $0.401 |
| 100 条可用结果，运行 5 次 | 100 × $0.0015 = $0.150 | (100 × $0.0055) + (5 × $0.001) = $0.555 | $0.405 |

表格使用上述有生效时间的 [Chronometrica API 费率](https://api.apify.com/v2/acts/chronometrica~tiktok-channel-scraper)和 [Novi API 费率](https://api.apify.com/v2/acts/novi~tiktok-user-info-api)。计算包含列出的启动事件费用。保留 3 位小数，以便清楚显示这项费用。

运行 1 次时，$0.551 − $0.150 = $0.401。运行 5 次时，$0.555 − $0.150 = $0.405。这 2 个差额都仅指 Actor 事件费用。

可用结果数量相等是一个假设，不是测量结果。输入 100 个账号资料，并不能证明任一服务会按你的验收规则返回 100 条可用记录。因此，该表不能证明对未经测试的清单能实际节省多少费用。

使用差额之前，先根据字段做判断。如果双方规范都满足需求，这个模型就能提供一项有效但范围有限的费用依据。如果只有一方能满足某个必需字段的要求，就先根据这一需求做选择。

模型也应包含运行次数。相同数量的可用结果，可以分布在不同次数的运行中。明确写出这 2 个数量，让其他开发者无需猜测你的账号资料采集方式，就能复现计算。

## 用少量公开输入核查 1 个必需字段

先核查最可能改变你选择的字段。它可能是将账号资料与数据库匹配时使用的身份值，也可能是其缺失值处理方式会影响报告的计数。开始采集之前，先明确通过条件。

Chronometrica 文档中的输入结构接受 `startUrls`。输入结构说明可接受的输入字段。下方示例展示当前输入结构，不是付费运行，也不是经过核实的实时结果。使用前，请将 URL 替换为相关公开账号资料的 URL。此示例不能证明来源当前可访问。[Chronometrica 输入结构](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema)

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

用少量公开输入核查 1 个必需字段

Task 是保存好的输入预设。已核查的公开 [TikTok 账号资料数据 API Task](https://apify.com/chronometrica/tiktok-channel-scraper/examples/tiktok-profile-data-api-dataset)提供了输入参考。保存好的预设不能证明你选定的账号资料会产生什么结果。

检查少量结果时，使用之前准备的字段映射表：

1. 确认结果对应的是目标账号资料。
2. 核查必需字段的含义、格式和值是否可用。
3. 检查状态和观测时间。
4. 在适用时保留计数精度。
5. 将未知值记录为未知。

如果字段仍待确认，就明确尚不清楚的内容。问题可能在于文档中的含义、返回的值，或应用程序的验收规则。在决策记录中保留这一区分。这样可以避免将不明确的需求变成对服务的断言。

1 次成功核查可以支持下一小步操作，但不能证明每个账号资料都能成功采集。只有当结果提供了应用程序所需的证据后，才扩大清单。保留已通过验收的字段映射表，以便按照相同需求复核后续变化。

## 按 6 个步骤做决定

1. 明确必需的事实。列出必需的账号资料字段、可接受的格式和缺失值规则。说明什么样的结果才算可用。
2. 映射双方规范。将每项必需事实与文档中的输出对应起来。比较数量之前，先解决含义上的差异。
3. 设定模型输入。记录可用结果数量、运行次数，以及双方一致的套餐级别。将假设的数量标为虚构。
4. 核查当前定价。选择最新生效的 API 记录。列出每项适用的结果事件和启动事件，以及各自的费率、计费单位和核查日期。
5. 计算 Actor 事件费用。将每种事件的数量乘以其费率，再将金额相加。所报告的金额不包含平台使用费用。
6. 验证必需字段。检查少量相关结果。扩大清单之前，保留未知值和观测背景信息。

决策记录可以很简短。它需要包含必需字段、待解决问题、证据链接、有核查日期的费率、假设和计算。其他开发者应能复核并更新这一选择，而无需重新推导你的思路。

先选择能够提供必需字段的规范，再将费用计算作为一个决策因素。除非有单独的证据回答相关问题，否则应将稳定性、运行时间和提取成功情况保留为待确认事项。

## 字段符合需求时，从 Chronometrica 开始

如果你已有一份公开账号资料清单，而且其需求适合扁平化输出，就选择 [Chronometrica TikTok Channel Scraper](https://apify.com/chronometrica/tiktok-channel-scraper)。已核查的规范和所列的较低 Free 套餐 Actor 事件费用支持这一选择。扩大清单之前，先用少量相关的公开输入验证 1 个必需输出字段。

如果 Novi 更大的原始用户对象能提供某个必需字段，而 Chronometrica 的规范无法提供，就选择 Novi。做决定之前，先解决尚不明确的字段支持问题。所列的较低 Actor 事件费用无法替代必需的事实。

## 来源和延伸阅读

- [Chronometrica TikTok Channel Scraper——公开账号资料输出规范；于 2026 年 10 月 20 日核查，构建版本为 0.1.27；文档说明了账号资料字段和观测背景信息，不涉及历史帖子或粉丝列表采集。](https://apify.com/chronometrica/tiktok-channel-scraper)
- [Chronometrica TikTok Channel Scraper 输入结构——于 2026 年 10 月 20 日核查；文档说明了 startUrls；文章中的输入用于展示当前输入结构，不能证明来源可访问，也不是经过核实的实时结果。](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema)
- [Chronometrica 公开 API 定价记录——于 2026 年 10 月 20 日核查；最新生效记录自 2026-07-16T22:51:35.105Z 起生效；Free 套餐列出的费用为每份可用账号资料 $0.0015，且没有 Actor 启动事件；API 费率与较早的 README 价格不同；仅指 Actor 事件费用，不含平台使用费用。](https://api.apify.com/v2/acts/chronometrica~tiktok-channel-scraper)
- [Novi TikTok User Info API——公开规范于 2026 年 10 月 20 日核查，构建版本为 0.1.90；返回更大的原始用户对象；具体所需字段仍需验证，文档未说明的支持情况仍待确认。](https://apify.com/novi/tiktok-user-info-api)
- [Novi TikTok User Info API 输入结构——于 2026 年 10 月 20 日核查；接受用户名、用户 ID 和 URL 形式的输入；支持这些输入，并不能证明会返回相应的可用输出。](https://apify.com/novi/tiktok-user-info-api/input-schema)
- [Novi 公开 API 定价记录——于 2026 年 10 月 20 日核查；最新生效记录自 2026-08-16T17:08:03.534Z 起生效；Free 套餐列出的费用为每条结果 $0.0055，另加每次启动 $0.001；仅指 Actor 事件费用，不含平台使用费用。](https://api.apify.com/v2/acts/novi~tiktok-user-info-api)
- [公开 TikTok 账号资料数据 API Task——于 2026 年 10 月 20 日在提供的公开证据中核查；它是保存好的输入预设，用作输入参考，不能证明账号资料当前可访问，也不能证明返回的数据。](https://apify.com/chronometrica/tiktok-channel-scraper/examples/tiktok-profile-data-api-dataset)
- [关于 TikTok 账号资料采集服务的公开讨论——本比较所审阅的来源证据日期为 2026 年 10 月 20 日；提问关注采集服务和稳定性，并非最便宜的服务；它支持对读者问题的理解，不能证明经过测量的价格偏好，也不能支持稳定性断言。](https://www.reddit.com/r/DevOpsLinks/comments/1vgwqze/what_do_you_think_works_for_pulling_public_tiktok/)