Chronometrica 與 API Dojo 比較：不爬取貼文也能取得 TikTok 個人檔案資料

先確定應用程式需要的結果

一名開發者在關於收集 TikTok 資料的公開提問中，描述了一個需要公開個人檔案資訊的應用程式。先前的資料收集方法已失效。這個情境引出一個實際問題：哪項服務適合處理已知的個人檔案清單？這則提問無法證明哪項服務日後會更可靠。

選擇 Actor 前，先寫下所需結果。對個人檔案清單而言，結果可能需要包含穩定的帳號識別碼、顯示名稱、追蹤者數和觀測時間。識別碼是用來將紀錄與帳號配對的值。觀測時間表示資料的核查時間。

需要貼文時，工作內容就會改變。如果應用程式必須顯示近期貼文說明文字、比較貼文或使用貼文日期控制，個人檔案資料列就無法提供所需依據。影片總數不包含影片本身或其文字。

這個區別也有助於訂立清楚的驗收規則。你可以檢查傳回的個人檔案是否包含應用程式所需的欄位。不必用傳回欄位的總數來判斷結果。

對僅收集個人檔案的情況，成功應定義為正確配對帳號，並取得所需資料。請為每個未能確認的輸入保留一筆紀錄。缺少結果的情況必須保持可見，讓應用程式能說明目前資料的限制。

兩個 Actor 的規格各適合哪些需求

Chronometrica 透過 `startUrls` 接受公開 TikTok 個人檔案網址或使用者名稱。文件說明，每個不重複的輸入會對應一筆扁平的配對結果。扁平結果會將個人檔案欄位集中儲存在同一筆資料列中。此 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` 顯示其公開追蹤者數。應用程式可以儲存其他資料，而不必將它們列為資料列可用的必要條件。

請區分帳號身分與標籤。顯示名稱方便使用者閱讀清單，但無法確認帳號身分。使用者名稱可能會改變。將新資料加入應用程式的現有紀錄前，請先檢查傳回的身分欄位。

也請保留原始輸入。這樣才能將傳回的資料列連回啟動檢查時使用的使用者名稱或網址。當傳回的標籤與應用程式先前儲存的標籤不同時，這點尤其重要。請先檢查帳號是否配對正確，不要在未檢查的情況下直接接受差異。

解讀計數時，請注意其限制。追蹤者數無法識別追蹤者，也無法衡量受眾品質。影片數無法反映貼文品質或創作者是否適合。如果使用 `accountRegion`，請將它視為公開帳號訊號。它不能證明某人的居住地。Chronometrica 規格。

只將應用程式會使用的資料列為必要條件。如果應用程式需要帳號身分及追蹤者數，缺少個人簡介不一定會使資料列無法使用。開始收集前，驗收規則就應說明這一點。

設定僅收集個人檔案的輸入

Chronometrica 目前的公開結構規格只有 1 個輸入欄位：`startUrls`。它接受要檢查的公開個人檔案網址或使用者名稱。無需加入貼文數量上限、日期篩選器或僅收集個人檔案的開關。此 Actor 的規格本來就只收集個人檔案。Chronometrica 輸入結構規格。

這個最簡範例已通過結構規格檢查，但並未執行，也未測試範例個人檔案目前是否可用。請將網址換成應用程式需要檢查的公開個人檔案。

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

TikTok Profile Data API Dataset Task 提供已儲存的輸入預設。Task 是為 Actor 儲存的輸入預設。使用前，請檢查其輸入，確保其中包含你打算檢查的個人檔案。

完全相同的重複輸入只會檢查 1 次。如果應用程式的清單包含重複項目，請記住這項規則。先決定應用程式要按不重複的個人檔案，還是按自身的清單紀錄來計算覆蓋率，再於報告中清楚說明。Chronometrica 規格。

採用簡單的驗收方法

使用以下方法，將傳回的資料轉為可用的應用程式紀錄。此方法先確定所需結果，最後對每個提供的個人檔案作出判定。

1. 列明必要欄位及貼文需求。寫下簡短規則，讓其他人也能用同一規則判斷相同結果。例如，要求帳號身分配對成功，而且追蹤者數有可用值。說明是否需要貼文文字、貼文歷史或貼文日期。這會決定僅收集個人檔案的 Actor 能否完成工作。
2. 維持每個輸入與其應用程式紀錄的連結。收集前，先儲存原始使用者名稱或網址。如果應用程式有自己的紀錄識別碼，也請保留。不要只靠傳回的顯示名稱，將資料連回清單。處理重複輸入時，不要遺失依賴這些輸入的清單紀錄。
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 的有力理由。它直接符合所需的工作單位：為一個已知輸入取得一筆已配對的個人檔案資料列。