# 執行前如何設定 Instagram 研究蒐集的規模

在大規模蒐集資料之前，先把研究問題收窄為已提供的有限網址抽樣框，以及明確的觀察預算。把不同貼文的數目與重複觀察分開計算。計劃、嘗試、已儲存、可用和已計費的數量要分開保存。規模較小的研究只回答一個較窄的問題。它不會使便利樣本代表一百萬間公司。

## 建立有限的貼文抽樣框

Actor 是託管的資料蒐集程式。Task 是已儲存的輸入預設。Instagram Metrics 公開組建 1.0.35 支援 mode contentUrls，其 startUrls 可包含已知的公開貼文或 Reel 網址，並可選用 maxItems 總上限。第一次檢查時，把 Task 樣本換成一條預定的已知內容網址、mode contentUrls，以及 maxItems 1，以取代已儲存預設的 maxItems 100。不要加入虛構的 maxItemsPerProfile 旗標。個人檔案探索是另一個模式；其目前的來源試行已被阻擋，且不被接受。

相關的原生欄位包括 inputUrl、postUrl、postId、shortCode、mediaType、publishedAt、profileId、profileUrl、likes、comments、views、plays、postMetricStatus、status、statusReason 及 scrapedAt。目前已接受的直接已知 Reel 重試，傳回相符的身分／日期，以及帶有指標狀態的公開 likes／comments／views；plays 為 null。原生 postMetricStatus 把指標是否可用與精確度分開。

OUTPUT 的 providedInputs、contentUrls、profileUrls、inputUrls、maxItems、resolvedUrls、metricRows、noPublicMetricRows、blockedRows、failedRows、invalidRows、unsupportedRows、statusCounts 及 stopReason 是蒐集記帳，不是計劃、可用或已計費的專案分類帳。

## 計算計劃數量

1. 界定單位與所需的公開欄位。公司層級模型、貼文層級描述，以及重複變化研究，需要不同的抽樣框。不要把假設的個人檔案／貼文數目當成已觀察到的可得性，也不要承諾免費的大規模替代做法。
2. 寫下抽樣框與納入規則，以及已知的公開個人檔案／貼文網址是如何取得的。已接受的路線從預先確認的貼文網址開始。它不能發現假設中的數百萬個公司個人檔案。如果沒有有效的抽樣框，先取得合適且獲准使用的現有資料集，或更改研究問題，是先決條件。
3. 按明確假設計算計劃數量：已選個人檔案數，乘以每個個人檔案已提供的不同貼文數，再乘以已儲存的觀察時間截點數。對同一則貼文的重複觀察不是新貼文。在穩定身分檢查下記入重複或共用貼文。個人檔案檢查是分開的取得紀錄。
4. 把已聲明的有限範圍與所提議的普查作比較。按適合該問題的書面設計選取帳戶與貼文；若屬立意或便利抽樣，要說明該限制。來源缺口與可見程度不相等會改變符合資格的條件。單是降低列數，得不出母體估計。
5. 選擇一個觀察時間截點，或重複的前瞻時間表。目前的 Actor 提供當前的公開觀察，不是過去的計數。三個未來的觀察時間截點會使同一個已選貼文抽樣框的計劃指標觀察增至三倍。缺失的來源結果仍然是缺失，不是零。若要研究過往每月歷史，就需要[已儲存歷史](/zh-Hant/articles/%E6%AF%8F%E6%9C%88instagram%E8%A7%80%E7%9C%8B%E5%A0%B1%E5%91%8A-%E6%8C%89%E7%99%BC%E5%B8%83%E6%97%A5%E6%9C%9F%E5%88%86%E9%96%8B%E8%88%8A%E8%88%87%E6%96%B0%E8%B2%BC%E6%96%87/)或合適的現有來源，不能使用編造的回填。
6. 查核目前的定價／收費規則，並在有支援的執行設定中，設定有限的每次執行收費上限。列數上限與收費上限是不同的控制。預算要包括已記錄的開始事件與結果事件，以及任何分開收費的用量或儲存。此處不假設一般費率或真實零售價格。
7. 在擴展之前，用單一已知貼文試行檢查所需欄位、來源身分與狀態，以及計數精確度。把處理時間與來源延遲分開。一次快速結果不能確立對數百萬項輸入的線性吞吐量，也不能確立未來的來源可得性。
8. 保留一份計劃與收據對照表。計劃觀察描述預定的工作；嘗試輸入描述執行情況；已儲存紀錄包括已到達儲存的內容；可用紀錄符合欄位規則；可計費事件來自實際計費收據的事件定義。不要假設已儲存等於可用等於已計費。如果所需範圍超出經費，應尋找合適的資料集，或收窄問題。

## 建立專案分類帳與預算

本節以原創虛構內容作為教學例子。

就歷史來源假設的說明而言，取 1,000,000 間公司，乘以百分之 60 有個人檔案，再乘以 60 則貼文，得出 36,000,000 則貼文。以每則貼文 10 秒計算，等於 360,000,000 秒，即按每天 86,400 秒計算的 4,166.6667 日。這是給讀者的來源假設說明，不是已量度的可得性、Actor 延遲，或執行時間預測。改用百分之 80 的假設會改變估計，兩者不得混合。

就原創的有限虛構研究而言，取 40 個預先確認的個人檔案，每個有 5 個不同的已知貼文 ID，合共 200 則不同貼文。三個計劃的前瞻觀察時間截點產生 600 次計劃指標觀察。四十次個人檔案檢查是分開的紀錄。穩定身分用來核實彼此是否不同。立意或便利抽樣框不是對一百萬間公司母體的推論。

以下是實際的 5 類專案分類帳，以及 2 列預算表。所用費率是虛構的：每次可計費觀察 USD 0.002，每次執行的開始費 USD 0.001，共三次執行。

表格：原創虛構專案分類帳

| 專案分類帳 | 數目 |
| --- | --- |
| 計劃觀察： | 600 |
| 嘗試輸入： | 600 |
| 已儲存紀錄： | 570 |
| 可用觀察： | 540 |
| 可計費事件： | 540 |

三十次嘗試沒有已儲存紀錄，另有三十筆已儲存紀錄未通過可用欄位規則。缺失的公開觀看計數仍然未知，即使 likes 與 comments 可用。

表格：原創虛構預算列

| 預算 | 計算 |
| --- | --- |
| 第 1 列（計劃範圍）： | 若全部 600 次計劃觀察均被計費，計算為 600 乘 0.002 加 3 乘 0.001，等於 USD 1.203。 |
| 第 2 列（結果收據）： | 另一份虛構的結果分類帳有 540 個可計費事件。在相同的虛構費率與費用下，540 乘 0.002 加 3 乘 0.001 等於 USD 1.083。 |

實際計費遵循真實的事件定義與收據，而不是已儲存等於可用等於已計費的假設。每次執行的收費控制，不是整個專案的成本上限。

## 下一步

在擴展到超出單一已知輸入的檢查之前，先寫下有限的貼文抽樣框、觀察時間截點、必要欄位規則，以及觀察／預算計劃。做法是設定 [Instagram Metrics Scraper](https://apify.com/chronometrica/instagram-metrics-scraper) Actor，並用 [Instagram Post Metrics Tracker](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker) Task 測試。

## 來源與延伸閱讀

- [Instagram Post Metrics Tracker Task](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker)
- [Instagram Metrics Scraper Actor](https://apify.com/chronometrica/instagram-metrics-scraper)
- [Apify Actor Store 定價文件](https://docs.apify.com/actors/running/actors-in-store)
- [Reddit Instagram 抓取問題](https://www.reddit.com/r/learnpython/comments/qq22zy/question_about_instagram_scraping_problem_for/)