# Chronometrica 與 API Dojo 比較：不爬取貼文也能取得 TikTok 個人檔案資料 如果你的應用程式需要為每個提供的公開 TikTok 個人檔案取得一筆已配對的資料列，而且不需要貼文，請選擇 Chronometrica。如果所需結果包含貼文歷史、貼文日期控制或詳細貼文資料，請選擇 API Dojo。選擇的關鍵是應用程式必須收集哪些資料。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)、[API Dojo 規格](https://apify.com/apidojo/tiktok-profile-scraper)。 本指南適合已有公開個人檔案清單的應用程式開發者。你需要將已核查的資料加入清單。這個流程稱為資料擴充。它不會尋找新創作者，也不會判斷哪些創作者適合你的應用程式。 我們是 Chronometrica Actor 的發布者。Actor 是託管的資料收集程式。我們的建議依據是其文件所載的僅收集個人檔案規格。我們未曾測試這兩個 Actor 在速度、成本、準確度、成功率或長期可靠性方面的差異。 公開規格的核查日期為 2026 年 10 月 20 日。下方輸入範例已按照公開輸入結構規格進行檢查。輸入結構規格定義可接受的輸入。此範例並未執行。請用本比較選擇資料收集規格，再核查實際結果是否符合應用程式的需求。 ## 先確定應用程式需要的結果 一名開發者在[關於收集 TikTok 資料的公開提問](https://www.reddit.com/r/DevOpsLinks/comments/1vgwqze/what_do_you_think_works_for_pulling_public_tiktok/)中，描述了一個需要公開個人檔案資訊的應用程式。先前的資料收集方法已失效。這個情境引出一個實際問題：哪項服務適合處理已知的個人檔案清單？這則提問無法證明哪項服務日後會更可靠。 選擇 Actor 前，先寫下所需結果。對個人檔案清單而言，結果可能需要包含穩定的帳號識別碼、顯示名稱、追蹤者數和觀測時間。識別碼是用來將紀錄與帳號配對的值。觀測時間表示資料的核查時間。 需要貼文時，工作內容就會改變。如果應用程式必須顯示近期貼文說明文字、比較貼文或使用貼文日期控制，個人檔案資料列就無法提供所需依據。影片總數不包含影片本身或其文字。 這個區別也有助於訂立清楚的驗收規則。你可以檢查傳回的個人檔案是否包含應用程式所需的欄位。不必用傳回欄位的總數來判斷結果。 對僅收集個人檔案的情況，成功應定義為正確配對帳號，並取得所需資料。請為每個未能確認的輸入保留一筆紀錄。缺少結果的情況必須保持可見，讓應用程式能說明目前資料的限制。 ## 兩個 Actor 的規格各適合哪些需求 Chronometrica 透過 `startUrls` 接受公開 TikTok 個人檔案網址或使用者名稱。文件說明，每個不重複的輸入會對應一筆扁平的配對結果。扁平結果會將個人檔案欄位集中儲存在同一筆資料列中。此 Actor 不收集影片或追蹤者清單。這種僅收集個人檔案的設計適合處理已提供的個人檔案清單。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)、[輸入結構規格](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema)。 API Dojo TikTok Profile Scraper 在以貼文為主的工作流程中傳回個人檔案資料。其公開使用規則要求個人檔案至少有 10 篇貼文，並提醒避免設定過低的結果數量上限，或將日期界限設得太接近目前時間。請將這些視為適用條件；它們並不能證明每次收集空白個人檔案都會失敗。[API Dojo 規格](https://apify.com/apidojo/tiktok-profile-scraper)。 | 選擇要點 | Chronometrica | API Dojo | | --- | --- | --- | | 所需結果 | 所提供輸入的個人檔案資料 | 個人檔案資料及貼文收集 | | 是否需要貼文 | 不收集影片 | 貼文歷史及詳細貼文資料 | | 輸入規劃 | 提供公開網址或使用者名稱 | 檢查貼文與日期設定 | | 本比較中最適合的情境 | 已有個人檔案清單，且不需要爬取貼文 | 需要貼文的工作 | 這些是規格上的差異，並非實測的效能差異。設定工作前，請檢查最新的 [Chronometrica 輸入結構規格](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema)及 [API Dojo 輸入結構規格](https://apify.com/apidojo/tiktok-profile-scraper/input-schema)。 ## 選定資料列必須包含的個人檔案欄位 Chronometrica 文件所列的欄位涵蓋帳號身分、部分公開資料及觀測狀態。相關欄位包括 `input`、`channelId`、`secUid`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、`followersCount`、`followingCount`、`likesCount`、`videosCount`、`countPrecision`、`status`、`statusReason` 及 `observedAt`。缺失值會保留為 `null`，表示沒有可用值。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)。 為每個必要欄位訂明用途。例如，應用程式可以用帳號識別碼配對紀錄，用 `displayName` 標示個人檔案，並用 `followersCount` 顯示其公開追蹤者數。應用程式可以儲存其他資料，而不必將它們列為資料列可用的必要條件。 請區分帳號身分與標籤。顯示名稱方便使用者閱讀清單，但無法確認帳號身分。使用者名稱可能會改變。將新資料加入應用程式的現有紀錄前，請先檢查傳回的身分欄位。 也請保留原始輸入。這樣才能將傳回的資料列連回啟動檢查時使用的使用者名稱或網址。當傳回的標籤與應用程式先前儲存的標籤不同時，這點尤其重要。請先檢查帳號是否配對正確，不要在未檢查的情況下直接接受差異。 解讀計數時，請注意其限制。追蹤者數無法識別追蹤者，也無法衡量受眾品質。影片數無法反映貼文品質或創作者是否適合。如果使用 `accountRegion`，請將它視為公開帳號訊號。它不能證明某人的居住地。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)。 只將應用程式會使用的資料列為必要條件。如果應用程式需要帳號身分及追蹤者數，缺少個人簡介不一定會使資料列無法使用。開始收集前，驗收規則就應說明這一點。 ## 設定僅收集個人檔案的輸入 Chronometrica 目前的公開結構規格只有 1 個輸入欄位：`startUrls`。它接受要檢查的公開個人檔案網址或使用者名稱。無需加入貼文數量上限、日期篩選器或僅收集個人檔案的開關。此 Actor 的規格本來就只收集個人檔案。[Chronometrica 輸入結構規格](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema)。 這個最簡範例已通過結構規格檢查，但並未執行，也未測試範例個人檔案目前是否可用。請將網址換成應用程式需要檢查的公開個人檔案。 ```json { "startUrls": [ "https://www.tiktok.com/@mrbeast" ] } ``` 設定僅收集個人檔案的輸入 [TikTok Profile Data API Dataset Task](https://apify.com/chronometrica/tiktok-channel-scraper/examples/tiktok-profile-data-api-dataset) 提供已儲存的輸入預設。Task 是為 Actor 儲存的輸入預設。使用前，請檢查其輸入，確保其中包含你打算檢查的個人檔案。 完全相同的重複輸入只會檢查 1 次。如果應用程式的清單包含重複項目，請記住這項規則。先決定應用程式要按不重複的個人檔案，還是按自身的清單紀錄來計算覆蓋率，再於報告中清楚說明。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)。 ## 採用簡單的驗收方法 使用以下方法，將傳回的資料轉為可用的應用程式紀錄。此方法先確定所需結果，最後對每個提供的個人檔案作出判定。 1. 列明必要欄位及貼文需求。寫下簡短規則，讓其他人也能用同一規則判斷相同結果。例如，要求帳號身分配對成功，而且追蹤者數有可用值。說明是否需要貼文文字、貼文歷史或貼文日期。這會決定僅收集個人檔案的 Actor 能否完成工作。 2. 維持每個輸入與其應用程式紀錄的連結。收集前，先儲存原始使用者名稱或網址。如果應用程式有自己的紀錄識別碼，也請保留。不要只靠傳回的顯示名稱，將資料連回清單。處理重複輸入時，不要遺失依賴這些輸入的清單紀錄。 3. 加入資料前，先檢查帳號身分。將傳回的身分欄位與應用程式已知的資料比較。有穩定的帳號識別碼時，請使用該識別碼。如果無法確認配對，請將紀錄保留為未能確認。僅有看似合理的名稱，不足以將最新計數加入現有帳號。 4. 一併解讀觀測欄位。檢查 `status`、`statusReason`、`countPrecision` 及 `observedAt`。這些欄位有助於評估傳回的資料及其限制。不要自行解釋尚未核查的欄位值。判斷現有計數精度是否符合應用程式的規則。將未能確認的輸入保留在清單中，並保留其實際傳回狀態。[Chronometrica 規格](https://apify.com/chronometrica/tiktok-channel-scraper)。 5. 區分 0、缺失資料及是否符合條件。明確的 0 是一個計數。缺失計數表示沒有可用值。是否符合條件，則是應用程式對資料列是否符合規則的判定。這些概念各不相同。絕不能只為了方便計算或製作畫面，就將缺失的追蹤者數填成 0。 6. 連同觀測時間一起儲存資料。目前計數只能支持對目前這次觀測的陳述，不能證明過去的計數。如果應用程式需要比較不同時間的計數，請分開儲存後續觀測。如果更新失敗後仍保留舊值，請保留其原始時間，避免應用程式將舊值顯示為最新資料。 7. 需求改變時，重新檢查資料收集方式。可用的個人檔案資料列仍可能缺少新功能所需的依據。如果功能需要貼文文字或貼文成效，請定義所需欄位，並選擇貼文收集工具。不要從個人檔案內的彙總計數推斷缺失的依據。 首次檢查的規模應小到可以逐筆人工核查。將實際傳回的欄位與驗收規則比較。如果缺少必要欄位，請先記錄該結果，再增加輸入。擴大清單無法解決驗收規則不清楚的問題。 如需進一步了解缺失與不可用狀態，請參閱 [TikTok 個人檔案存取狀態指南](/zh-Hant/articles/%E4%BD%BF%E7%94%A8%E7%BC%BA%E5%A4%B1%E8%B3%87%E6%96%99%E5%89%8D%E5%85%88%E6%AA%A2%E6%9F%A5-tiktok-%E5%80%8B%E4%BA%BA%E6%AA%94%E6%A1%88%E7%8B%80%E6%85%8B/)。本文的核心選擇仍是：應用程式需要個人檔案資料，還是貼文。 ## 逐一分析虛構的應用程式個人檔案清單 本節整個範例均屬虛構，描述的是應用程式所提供的個人檔案清單。它不是 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 規格](https://apify.com/apidojo/tiktok-profile-scraper)、[輸入結構規格](https://apify.com/apidojo/tiktok-profile-scraper/input-schema)。 保留原本所需的個人檔案欄位，並加入明確的貼文需求。說明該功能必須接收哪些貼文資料，以及哪些日期控制重要。然後，按照所需結果評估收集工具。 已儲存的影片數無法回答關於貼文說明文字的問題。目前追蹤者數無法證明首次儲存觀測之前的追蹤者成長情況。請根據功能所需的依據選擇收集方法，而不是根據 Actor 列出的欄位數量。 對原本僅收集個人檔案的工作而言，這種僅收集個人檔案的設計仍是選擇 Chronometrica 的有力理由。它直接符合所需的工作單位：為一個已知輸入取得一筆已配對的個人檔案資料列。 ## 擴大清單前，先檢查 1 個真實個人檔案 使用 [Chronometrica TikTok Channel Scraper](https://apify.com/chronometrica/tiktok-channel-scraper)，按照應用程式的必要欄位清單，檢查 1 個已知的公開個人檔案。透過 `startUrls` 提供其網址或使用者名稱。先檢查傳回的帳號身分、必要資料及實際狀態，再判斷資料列是否符合條件。 儲存原始輸入、傳回的資料及 `observedAt`。保留缺失值，不要填入其他值。將任何未能確認的結果保留在應用程式清單中。當你能說明首筆結果如何符合或不符合已訂明的規則後，再擴大清單。 如果所需結果是個人檔案資料，而且無需爬取貼文，就可以有依據地選擇此 Actor。以是否需要貼文作為轉換選擇的條件：當應用程式需要貼文依據時，請選擇包含貼文的資料收集規格。 ## 來源與延伸閱讀 - [Chronometrica TikTok Channel Scraper 規格](https://apify.com/chronometrica/tiktok-channel-scraper) - [Chronometrica 輸入結構規格](https://apify.com/chronometrica/tiktok-channel-scraper/input-schema) - [TikTok Profile Data API Dataset Task](https://apify.com/chronometrica/tiktok-channel-scraper/examples/tiktok-profile-data-api-dataset) - [API Dojo TikTok Profile Scraper 規格](https://apify.com/apidojo/tiktok-profile-scraper) - [API Dojo 輸入結構規格](https://apify.com/apidojo/tiktok-profile-scraper/input-schema) - [開發者關於收集 TikTok 資料的公開提問](https://www.reddit.com/r/DevOpsLinks/comments/1vgwqze/what_do_you_think_works_for_pulling_public_tiktok/)