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

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

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

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

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

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

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

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

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

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

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

Chronometrica 文档所列的账号资料输出包括 `input`、`channelId`、`secUid`、`shortId`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、公开计数、`countPrecision`、`status`、`statusReason` 和 `observedAt`。它采集账号资料，不采集历史帖子或粉丝列表。Chronometrica 输出规范

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

Novi 接受用户名、用户 ID 和 URL 输入，并返回一个更大的原始用户对象。原始对象保留了更广泛的源数据结构。请核实具体所需的字段及其含义。Novi 规范、Novi 输入结构

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

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

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

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

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

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

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

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

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

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

这些规则会影响结果是否可用。如果应用程序无法区分新近观测到的事实与尚未确认的值，仅有正确的字段名称还不够。相关指南 TikTok 账号资料访问状态与缺失值对此有更详细的说明。

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

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

本次核查的 Chronometrica 当前记录自 `2026-07-16T22:51:35.105Z` 起生效。Free 套餐列出的费用为每份可用账号资料 $0.0015。其当前事件列表不包含 Actor 启动事件。Chronometrica 公开 API 定价

本次核查的 Novi 当前记录自 `2026-08-16T17:08:03.534Z` 起生效。Free 套餐列出的费用为每条结果 $0.0055，另加每次启动 $0.001。Novi 公开 API 定价

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

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

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

算术已经核对的虚构示例

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

表格使用上述有生效时间的 Chronometrica API 费率和 Novi 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 输入结构

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

Task 是保存好的输入预设。已核查的公开 TikTok 账号资料数据 API Task提供了输入参考。保存好的预设不能证明你选定的账号资料会产生什么结果。

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

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

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

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

按 6 个步骤做决定

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

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

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