Chronometrica 與 Novi 比較：TikTok 個人檔案欄位與 Actor 事件費用

先列出應用程式需要的欄位

寫下應用程式必須如何使用每個個人檔案。接著列出完成該操作所需的欄位。這樣就能依明確需求進行比較。

以虛構的個人檔案目錄為例，必要欄位可能包括帳號名稱、顯示名稱、個人檔案 URL、簡介及追蹤者數量。更新已儲存記錄的流程，可能還需要身分識別欄位、觀察時間及明確狀態。這些只是需求範例，不能證明 2 個服務會提供相同的值。

區分必要欄位與有用的額外欄位。缺少必要欄位會使必要操作無法執行。額外欄位能補充背景資訊，但缺少它不會使該操作無法執行。先做出這個區分，再查看費用差異。否則，低價可能讓不完整的結果看起來已經足夠。

為每個必要欄位記錄 3 件事：

1. 含義：這個欄位必須代表什麼事實？
2. 接受規則：應用程式可以使用哪些值？
3. 缺失值規則：事實未知時，必須如何處理？

不要只依賴欄位名稱。名稱相似的 2 個欄位，可能代表不同事實，或使用不同格式。將任一欄位對應至已儲存的記錄前，先檢查文件所述的含義。

也要定義什麼才算 1 筆有用的結果。你的應用程式可能要求確認個人檔案身分，且具備所有必要欄位。它也可能接受部分記錄，前提是狀態能說明缺少哪些資訊。這 2 種規則都可能合理。比較結果數量前，先訂好規則。

讓需求與用途保持關聯。如果應用程式需要比對現有記錄，就指出它用哪個欄位進行比對。如果需要顯示計數值，就定義未知值或精確度有限的值應如何顯示。這樣，後續檢查才會夠明確，能夠重複執行。

依必要欄位檢查 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 份規格都符合需求，這個模型就能提供有效但範圍有限的費用依據。如果只有其中一個服務符合某項必要欄位需求，就先依該需求選擇。

執行次數也應納入模型。相同數量的有用結果，可能分散在不同的執行次數中。請同時列明這 2 個數量，讓其他開發者能重現計算，無須猜測你如何收集這些個人檔案。

用少量公開資料輸入檢查 1 個必要欄位

先檢查最可能改變你選擇的欄位。它可能是用來將個人檔案與資料庫記錄比對的身分識別值。也可能是缺失值處理方式會影響報告的計數值。開始收集任何資料前，先定義通過條件。

Chronometrica 文件記載的結構定義接受 `startUrls`。結構定義說明可接受的輸入欄位。以下是現行結構定義的範例，不是付費執行，也不是已核實的即時結果。使用前，請將 URL 換成相關的公開個人檔案。這個範例不能證明來源目前可供存取。Chronometrica 輸入結構定義

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

Task 是已儲存的輸入預設組態。經核查的公開 TikTok 個人檔案資料 API Task可作為輸入參考。已儲存的預設組態，不能證明你選擇的個人檔案會產生什麼結果。

檢查少量結果時，請使用事先準備的欄位對照表：

1. 確認結果對應的是預期的個人檔案。
2. 檢查必要欄位的含義、格式及可用值。
3. 檢查狀態與觀察時間。
4. 適用時，保留計數值的精確度。
5. 將未知值記錄為未知。

如果欄位仍未釐清，請指出還有哪些不明之處。可能是文件所述的含義、傳回的值，或應用程式的接受規則。在決策記錄中保留這個區分。這能避免把不明確的需求，變成對服務的斷言。

1 次成功的檢查可支持下一個小步驟，但不能證明每個個人檔案都會成功。結果提供應用程式所需的證據後，再擴大清單。保留已接受的欄位對照表，讓後續變更能依相同需求接受審查。

依 6 個步驟做出決定

1. 定義必要事實。列出必要的個人檔案欄位、可接受格式及缺失值規則。說明什麼才算有用的結果。
2. 建立 2 份規格的對照。將每項必要事實對應到文件記載的輸出。比較數量前，先釐清含義上的差異。
3. 設定模型輸入。記錄有用結果數量、執行次數及相同的方案等級。將假設的數量標示為虛構。
4. 檢查現行定價。選取最新生效的 API 記錄。列出每個適用的結果事件與啟動事件，以及各自的費率、單位和核查日期。
5. 計算 Actor 事件費用。將每種事件的次數乘以其費率，再加總金額。所述金額不包含平台使用費。
6. 核實必要欄位。檢查少量相關結果。擴大清單前，先保留未知值與觀察背景資訊。

決策記錄可以保持簡短。它需要包含必要欄位、尚未釐清的問題、證據連結、註明日期的費率、假設及計算。其他開發者應能審查及更新這項選擇，而無須重新推敲你的判斷過程。

先選擇規格能提供必要欄位的服務，再把費用計算作為決策因素之一。除非另有證據回答相關問題，否則應將穩定性、執行時間及擷取成功情況保留為尚未釐清。