# 如何從創作者名單移除重複的 Instagram 個人檔案

以穩定的 channelId 值把創作者紀錄分組，以清理重複的個人檔案。Actor 是一個託管的資料收集程式，會收集來源列。Task 是一個已儲存的輸入預設，用來保存你的搜尋設定。Build 0.1.26 的 startUrls 接受 1 至 1,000 個已知公開個人檔案、@handles 或不帶符號的 handles。預設中的兩個樣本輸入，會被一個擬使用的個人檔案取代。完全相同的重複輸入會由 Actor 自動合併。一列代表一次已嘗試的輸入，包括未能取得的列。原生欄位包括 input、channelId、eimuId、fbid、channelUrl、handle、status、statusReason 和 observedAt。eimuId 欄位必須完全一致。fbid 欄位是與 Meta 連結的識別碼，不是 Facebook 專頁 ID。OUTPUT 會報告 requestedChannels、acceptedProfileInputs、rejectedInputs、datasetRows、usefulRows、billableRows、nonUsefulRows 和 statusCounts。以 NASA 做的單一個個人檔案對照，status 為 ok，回傳了正確的身分、標準 channelUrl、handle、5 個 bioLinks、detectedEmails 為空陣列，以及 businessEmail 和 businessPhoneNumber 為 null。這只證明身分與連結方面的支援。此方法不包括年齡或地點的發現、貼文存檔、過往 handle 紀錄，或跨平台的人物配對。

1. 先從已知的個人檔案名冊開始，並保留你的原始輸入。Actor 接受已知個人檔案，不能按年齡、地點或追蹤者人數搜尋所有個人檔案。你必須先備有人手清單。
2. 先執行一個公開個人檔案，以測試你的設定。對照公開來源，檢查其標準 channelUrl、handle、channelId、status、statusReason 和 observedAt。有用的列可以只是部分資料，單靠名稱相符不能修正錯誤的目標。
3. 把識別碼儲存為文字字串，並把命名空間定義為 instagram:channelId。不要只因數字相同，就把 Instagram 的 channelId 與其他平台 ID 混在一起。fbid 欄位是與 Meta 連結的識別碼，不是 Facebook 專頁 ID。
4. 從安全的個人檔案 URL 和 @handles 建立已正規化的輸入別名表，同時保留原始輸入。為了比較，移除一般的結尾斜線和查詢標記，但不要把限時動態或登入路徑變成個人檔案身分。別名正規化與 Actor 的完全相同字串重複合併是分開的。
5. 按非空白的 channelId 值，把目前的觀察分組。保留輸入至 channelId 的邊，以及標準 channelUrl 值。當同一個 handle 在不同觀察時間對應到不同的 channelId 值時，保留兩筆紀錄，並檢查公開來源，不要盲目覆寫舊資料。缺少的歷史不能解釋衝突為何發生。
6. 處理缺少的 channelId 值時，把標準 channelUrl 或 handle 保留為較弱的暫定證據。絕不可只按顯示名稱合併帳戶。把 blocked、private 或 parser_miss 的列留在已核實身分表之外。本機暫定鍵是追蹤用的元資料，不是編造出來的穩定身分。
7. 把結果分成已核實身分、輸入別名、未解決的觀察和衝突。已知身分要與輸入列、有用列和已觀察的 handles 分開計數。在加入額外事實之前，先解釋來源狀態與已收集資料之間的任何差距。
8. 為日後重新更新，附加一筆帶有 observedAt 的新觀察。Actor 不會自動回傳歷史變更，因此在比較數目或[隨時間變化的連結清單](/zh-Hant/articles/%E5%A4%96%E5%B1%95%E5%89%8D%E6%AA%A2%E6%9F%A5%E5%85%AC%E9%96%8Binstagram%E7%B0%A1%E4%BB%8B%E9%80%A3%E7%B5%90/)之前，你必須先檢查身分。

## 逐步範例與表格

以下表格展示原創虛構內容，用來說明此方法如何運作。

### 名冊至 ID 別名表

| 名冊列 | 原始輸入 | 原始來源 channelId | 狀態 | 標準 channelUrl | observedAt | 覆核狀態 |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | @greenstudio | 10001 | ok | https://www.instagram.com/greenstudio | 2026-03-01 | 已核實別名 |
| R2 | https://www.instagram.com/greenstudio/?ref=sheet | 10001 | ok | https://www.instagram.com/greenstudio | 2026-03-01 | 已核實別名 |
| R3 | @green_studio | 20002 | ok | https://www.instagram.com/green_studio | 2026-03-01 | 已核實別名 |
| R4 | @summerlab | null | partial | https://www.instagram.com/summerlab | 2026-03-01 | 暫定 |
| R5 | @private_notes | null | private | null | 2026-03-01 | 未解決 |

### 兩個已知 ID 登記冊

| channelId | 相關別名／輸入 | 狀態摘要 | 覆核狀態 |
| --- | --- | --- | --- |
| 10001 | @greenstudio, https://www.instagram.com/greenstudio/?ref=sheet | ok | 已核實身分 |
| 20002 | @green_studio | ok | 已核實身分 |

### 衝突與覆核列

| 原始輸入 | 原始來源 channelId | 狀態 | observedAt | 覆核狀態 |
| --- | --- | --- | --- | --- |
| @greenstudio | 30003 | ok | 2026-06-01 | 與 10001 衝突（沒有改名或出售證明） |

已核實的表有兩個不同且各自只計一次的已知身分，不是五個身分，也不是一個顯示名稱身分。列 R1 和 R2 是 channelId 10001 的兩個輸入別名。列 R4 是暫定，因為它沒有 channelId；列 R5 是未解決，因為它是 private。在較後的一筆虛構觀察中，@greenstudio 對應到 channelId 30003。把這筆儲存為帶有 observedAt 時間戳的身分衝突。它不能證明改名、帳戶出售或冒充。在合併任何衝突列之前，你必須檢查邊表和來源事實。

## 下一步

要執行你自己的去重工作流程，使用 Apify 的 [Instagram Channel Scraper](https://apify.com/chronometrica/instagram-channel-scraper) Actor 和 [Instagram Identity Map](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-identity-map) Task。

## 來源與延伸閱讀

- [Reddit 上的 Instagram 個人檔案資料擷取討論](https://www.reddit.com/r/instagramAsk/comments/1u1275c/instagram_profile_scrapping/)
- [Reddit 上關於擷取 Instagram 個人檔案的討論](https://www.reddit.com/r/n8n/comments/1pac74m/scraping_instagram_profiles/)