個人檔案卡片分別連到可用、部分及未解決的更新匣。
使用缺失值之前,先讀來源狀態。

使用你自己已知的個人檔案

Actor 是託管的資料收集程式。Task 是已儲存的輸入預設。TikTok Channel Scraper Actor 收集來源資料列。哪些資料列可供你的工作使用,由你決定。Actor 不會代你做這個決定。

目前的公開 Task 是 Bulk TikTok Profile Scraper。它已儲存的樣本輸入有兩個公開 URL:

json
{
  "startUrls": [
    "https://www.tiktok.com/@mrbeast",
    "https://www.tiktok.com/@nasa"
  ]
}
使用你自己已知的個人檔案

把那些樣本 URL 換成你自己已知的公開個人檔案 URL。公開 Task 只是起始輸入。它不能證明檢查或決定會自動完成。

公開組建 0.1.27 已在 2026-10-13 檢查。該檢查日期不是資料列時間。`observedAt` 是來源資料列上的時間。判斷一個值是否為目前值時,使用 `observedAt`。

只傳送已知個人檔案

輸入欄位是 `startUrls`。你可以傳送 1 至 1,000 個已知個人檔案 URL 或帳號代號。帳號代號是 @ 符號後面的公開名稱。只傳送你已經知道的個人檔案。

此輸入不會搜尋用戶。它不會發現國家。它不會收集貼文或留言。它不會取得私人聯絡資料。它不會登入。它不會繞過驗證碼或驗證挑戰。

重複的輸入字串只檢查一次。一列結果代表對一個個人檔案的一次嘗試。該列不一定是可用的個人檔案。傳送長清單之前,先執行一個預定的個人檔案。

先讀這些欄位

每一列都要查看 `input`、`channelId`、`channelUrl`、`handle`、`status`、`statusReason`、`isBillable` 和 `observedAt`。`channelId` 是該個人檔案的來源 id。`status` 是該次嘗試的來源結果。有原因時,`statusReason` 說明為甚麼設定該狀態。

可選欄位可以包括 `followersCount`、`bioLink`、`description`、`detectedEmails` 和 `accountRegion`。當 `countPrecision` 存在時,它說明一個計數的品質。要連同該計數一起讀。不要忽略它。

`isBillable` 是資料列上的計費資料。該資料說明此列是否符合收費資格。符合資格是指此列可以被收費。該資料不是實際收費的證明。計費收據才證明已收費。`isBillable` 不能證明個人檔案是誰。它不能證明每個欄位都完整。`billableRows` 計算符合收費資格的資料列數目。該數目不是已付款的證明。

每個來源狀態都要保持在目前的 schema 之下。狀態決定你下一步做甚麼:

  • `ok` 表示個人檔案已返回。你仍需要相符的身分,以及你要求的欄位。可選欄位仍可以是 null。
  • `partial` 表示個人檔案已返回,但該列不完整。在逐一檢查每個必要欄位之前,不要捨棄整列。
  • `private` 表示私人部分仍然無法取得。不要把該列當成公開的零。
  • `login_required` 表示來源要求登入。停止。此 Actor 不會登入。
  • `not_found` 表示在這次檢查中看不到該個人檔案。它沒有說明時間或原因。它不能證明帳戶已刪除。
  • `blocked` 表示來源存取被封鎖。不要填補缺失欄位。不要把封鎖讀成粉絲數為零。
  • `challenge` 表示來源顯示了驗證挑戰。不要解開它。
  • `rate_limited` 表示來源限制了這次檢查。儲存該列。你可以計劃稍後再檢查一次。不要循環重試。
  • `parser_miss` 表示這次檢查沒有讀到預期的事實。不要編造那些事實。
  • `invalid_input` 表示輸入格式無效。只修正你能指出錯誤的格式。
  • `failed` 表示這次嘗試因另一個來源原因而失敗。儲存原因和時間。不要編造缺失的事實。

無法取得的資料列不能證明帳戶已刪除。它也不能證明該帳戶沒有粉絲。

知道一次對照執行做了甚麼、沒有做甚麼

目前的 0.1.27 對照使用了一個個人檔案。該列與預定的 `channelId` 相符。它與預定的 `channelUrl` 或帳號代號相符。它與 `followersCount` 相符。其狀態是 `ok`。

可選的 `commerceCategory` 是 null。`isCommerce`、`isSeller` 和 `isPrivate` 是 false。Null 表示沒有給出該值。False 表示來源給出了真實的「否」。不要把 false 變成缺失。不要把 null 變成 false。不要把 false 的 `isCommerce` 抄進 null 的 `commerceCategory`。

該對照沒有測試私人個人檔案。它沒有測試被封鎖的個人檔案。它沒有證明每個個人檔案欄位都完整。隱藏或缺失的電郵不能被造出來。如果 `detectedEmails` 是 null 或空白,那不能證明擁有者沒有公開聯絡方式。

把執行總數與你的清單比較

這次執行的 OUTPUT 使用這些確切名稱:

  • `requestedChannels` 是一個數字。該數字計算已處理的輸入嘗試次數。該數字等於 `rows.length`。`rows.length` 是那些嘗試資料列的數目。這個數字不是原來的名冊清單。原來的名冊清單由你持有。該清單保持分開。
  • `acceptedProfileInputs` 是一個數字。該數字等於 `rows.length` 減 `rejectedInputs`。
  • `rejectedInputs` 是一個數字。該數字計算執行拒絕的輸入數目。執行會拒絕無效輸入和不支援的輸入。`rejectedInputs` 不是一份清單。
  • `datasetRows` 是返回的個人檔案資料列數目。這些列是已嘗試的個人檔案資料列。
  • `usefulRows` 是 Actor 標為可用的返回資料列數目。Actor 是為每一列加上標記的程式。
  • `billableRows` 是符合收費資格的返回資料列數目。符合資格是指一列可以被收費。該數字不是已付款的證明。
  • `nonUsefulRows` 是不可用的返回資料列數目。
  • `statusCounts` 是每個狀態中返回資料列的數目。`datasetRows` 和 `statusCounts` 描述返回的資料列。它們不描述原來的名冊清單。

`datasetRows` 不是資料完整的已檢查個人檔案數目。一次執行可以完成,但仍包含失敗的目標。可用的資料列仍可能缺少你要求的欄位。可計費的資料列仍可能缺少可選欄位。要讀該列。不要停在總數。

寫下你的工作需要的欄位

捨棄資料不完整的個人檔案之前,先列出下一項工作需要的欄位。你不需要的欄位可以保持 null。你需要的欄位必須存在,才可接受該列。

對每個必要欄位,儲存來源值和一個可用性狀態。只在來源確實支援該狀態時才使用:

  • `present` 表示有值返回。False 是存在的。只有來源返回零時,零才算存在。
  • `explicitly_empty` 表示來源返回了空值,例如空清單。
  • `absent_or_unavailable` 表示該欄位是 null,或該列無法提供它。
  • `not_requested` 表示這項工作不使用該欄位。

空清單與 null 不同。Null 是未知。不要把未知儲存為零。

這是你自己寫的紀錄。它不是 Actor 的輸出資料列:

text
field: followersCount
source_value: null
availability: absent_or_unavailable
observedAt: the time on that source row
寫下你的工作需要的欄位

按此順序檢查每個個人檔案

  1. 保留你原來的已知個人檔案名冊。名冊是你的本機清單。給每個名冊列自己的本機鍵。讀取返回的狀態。不要承諾可以取得隱藏的電郵。不要承諾繞過封鎖的方法。不要承諾修復每一次來源失敗。相同的輸入字串只檢查一次。你的名冊數目與不重複的嘗試次數可以不同。本機鍵使每個名冊列對應正確的觀察。
  2. 先執行一個預定的個人檔案。讀取返回的身分、狀態和 `observedAt`。有 `channelId` 時要檢查它。檢查預定的帳號代號和 URL。熟悉的顯示名稱不足以修正錯誤目標。先核對身分。本文不教你如何合併同一創作者的其他名稱。身分相符之後,由你決定資料是否可用。
  3. 把不良狀態與空欄位分開。狀態 `ok` 或 `partial`,加上相符的身分,仍可以有 null 的可選 `bioLink`。該個人檔案仍可以有用。`blocked`、`challenge` 和 `login_required` 表示來源沒有給予存取。`private` 表示私人部分仍然無法取得。`not_found` 沒有告訴你個人檔案在何時不再可見。它也沒有告訴你原因。
  4. 各自判斷每個必要欄位。儲存來源值和可用性狀態。false 保持為 false。null 保持為未知。空清單與 null 分開。如果你的工作不需要該欄位,使用 `not_requested`。不要因為你沒有要求使用的欄位而判定個人檔案失敗。
  5. 把 OUTPUT 與名冊比較。把 `acceptedProfileInputs` 與你的不重複輸入比較。把已嘗試的資料列與 `datasetRows` 比較。同時讀取 `usefulRows`、`nonUsefulRows`、`rejectedInputs` 和 `statusCounts`。不要把 `datasetRows` 報告為完整個人檔案。不要假定 `billableRows` 包含每個可選欄位。
  6. 為每次不重複的嘗試選擇一個下一步狀態。身分相符且每個必要欄位都存在時,使用 `accepted_for_required_fields`。身分相符但缺少必要欄位時,使用 `useful_but_required_gap`。來源沒有返回可用個人檔案時,使用 `source_unavailable`。id、帳號代號或 URL 不是預定個人檔案時,使用 `identity_mismatch`。格式本身錯誤時,使用 `invalid_input`。只修正你能指出無效的格式。來源失敗可以支持稍後計劃一次再檢查。它不支持循環重試。它不支持解開驗證挑戰。把 `observedAt` 和 `statusReason` 與該次觀察一起保留。
  7. 在稍後的更新中,使用相同的來源身分和相同的必要欄位。如果較舊的資料列有一個值,而新的資料列無法取得,你就沒有目前的觀察。舊值是歷史。保留它的日期。把目前值標為未知。新觀察無法取得時,不要把較早的值再用作目前值。不要把它改成零。不要把缺少目前值說成該值已完全下降。
  8. 寫一份可用性報告。該報告列出每個個人檔案、必要欄位,以及每個未解決狀態。只把資料列用於其必要欄位已存在的工作。收集缺口要與關於擁有者的聲稱分開。缺口不表示擁有者缺少該事實。它也不表示擁有者缺少該帳戶類型。

選擇接受、部分、重試或覆核

下一步狀態告訴你資料狀況。讀者決定告訴你要做甚麼。使用這四個決定之一:接受、部分、重試或覆核。

選擇接受、部分、重試或覆核
讀者決定下一步狀態原因你要做甚麼
接受accepted_for_required_fields身分相符。每個必要欄位都存在。只把該列用於該項工作。
部分useful_but_required_gap身分相符。一個必要欄位為未知。保留該列。不要填補缺口。不要在需要該欄位的地方使用它。
重試source_unavailable,而且只可作為稍後一次已計劃的再檢查輸入仍可以有效,但這次嘗試沒有完成。`rate_limited` 或 `failed` 可以符合。儲存狀態、原因和 `observedAt`。計劃稍後再檢查一次。不要循環。
覆核identity_mismatch、invalid_input,或一個你不可強行處理的來源狀態這包括 `private`、`blocked`、`challenge`、`login_required`、`not_found` 和 `parser_miss`。把該列放在覆核清單上。只修正已證明錯誤的格式。

在考慮另一次執行之前,先把該列放上覆核清單。稍後再檢查只允許用於來源失敗,例如 `rate_limited` 或 `failed`。不要用該次再檢查去解開驗證挑戰。不要用它來登入。不要用它來打開私人個人檔案。`challenge` 留在覆核,因為此 Actor 不解驗證挑戰。`login_required` 留在覆核,因為此 Actor 不會登入。`private` 仍然無法取得。第二次呼叫不會使私人資料變成公開。

用原創虛構例子學習這些決定

本節的表格和計數是原創虛構。它們不是產品結果。它們不顯示真實成功率。

虛構名冊有五個本機列:

用原創虛構例子學習這些決定
本機鍵輸入它是甚麼
R1@green一個已知公開帳號代號的第一個複本
R2@green與 R1 完全相同的重複項
R3@blue第二個已知公開帳號代號
R4@closed返回結果為私人的已知帳號代號
R5@unknown返回結果為被封鎖的已知帳號代號

R1 和 R2 使用相同的輸入字串。檢查只接受該字串一次。你仍然保留五個本機鍵。這次執行有四次已接受的不重複嘗試,以及四列狀態。此虛構中的 `acceptedProfileInputs` 是 4。此虛構沒有顯示被拒絕的輸入。真實執行仍可以把 `rejectedInputs` 給成一個數字,所以你也必須讀該計數。

虛構的狀態資料列如下:

用原創虛構例子學習這些決定
嘗試本機鍵channelIdstatusfollowersCountbioLink下一步狀態
1R1 和 R2ID100ok1,000nullaccepted_for_required_fields
2R3ID200partialnullpresentuseful_but_required_gap
3R4不可用private不可用不可用source_unavailable
4R5不可用blocked不可用不可用source_unavailable

這項虛構工作需要兩件事。`channelId` 必須與預定個人檔案相符。目前的 `followersCount` 必須存在。

R1 符合兩項規則。id 是 ID100。目前粉絲數是 1,000,所以該值存在。`bioLink` 是 null。這項工作沒有要求 `bioLink`,所以該 null 連結保持未知。你不要編造連結。R1 是你可為此工作接受的唯一一個不重複個人檔案。讀者決定是接受。

R2 不是第二個創作者。它與 R1 是相同輸入,並對應同一次觀察。保留 R2 鍵,名冊才能解釋這個重複。不要把 R2 計成另一個有另外 1,000 名粉絲的個人檔案。

R3 與 ID200 相符,所以身分正確。狀態是 `partial`。粉絲數是 null。Null 不是零,而這項工作要求該計數。個人簡介連結存在,但它不能填補缺失的計數。R3 是 `useful_but_required_gap`。讀者決定是部分。保留 R3,不要把它用於需要目前粉絲數的工作。可用的來源資料列仍可能不符合你自己的欄位規則。

R4 的狀態是 `private`。它的必要事實不可用。R5 的狀態是 `blocked`。它的必要事實不可用。兩者都是 `source_unavailable`。讀者決定是覆核。不要把任一列讀成已刪除的帳戶。不要把任一列讀成粉絲數為零。此虛構沒有給出 R4 或 R5 的 `channelId`。不要編造一個。

虛構的 `statusCounts` 跟隨這四列:一個 `ok`、一個 `partial`、一個 `private`,以及一個 `blocked`。如果這四列就是你的 `datasetRows`,數目是 4 次嘗試。該數目仍然不是 4 個完整個人檔案。一個不重複個人檔案符合 id 與目前粉絲數規則。一列,即 R3,有必要欄位缺口。兩列,即 R4 和 R5,無法取得。不要把 4 次嘗試中有 1 個已接受個人檔案,變成真實成功率。

第二次對 ID100 的虛構觀察返回 `blocked`。保留較早的粉絲數 1,000。保留該較早觀察的日期。目前計數是未知。不要報告零。不要報告 100% 下降。舊的 1,000 是歷史。它不是目前計數。新觀察無法取得時,不要把較早的 1,000 再用作目前計數。

再用一組虛構配對,使 false 與 null 保持分開。另一個 `isSeller` 值 false 是存在的。來源說了否。另一個 `isSeller` 值 null 是未知。它不表示否。此虛構中沒有任何狀態能證明擁有者沒有公開聯絡方式。

停留在個人檔案接受範圍內

本文只教如何接受個人檔案資料。你檢查身分、狀態、時間,以及你的工作需要的欄位。然後你接受該列、保持它為部分、計劃一次再檢查,或覆核它。

按帳戶類型排序個人檔案是另一項工作。回饋是另一項工作。舊貼文計數是另一項工作。此方法不會擷取私人個人檔案。它不會返回粉絲清單。它不會發現聯絡方式。它不會建立增長歷史。缺失的目前值是這次檢查中的缺口。它不是已量度的變化。

來源與延伸閱讀

作者 Chronometrica · 更新日期

返回頂端 ↑