# 运行前如何确定 Instagram 研究采集的规模

在大规模采集数据之前，先把研究问题收窄为已提供的有限 URL 框架和明确的观察预算。把不同帖子与重复观察分开计数。把计划数量、尝试数量、已保存数量、可用数量和计费数量分开。规模更小的研究回答的是范围更窄的问题。它不会让便利样本代表一百万家公司。

## 建立有限的帖子框架

Actor 是托管的数据采集程序。Task 是已保存的输入预设。Instagram Metrics 公开版本 1.0.35 支持 contentUrls 模式：startUrls 包含已知的公开帖子或 Reel URL，并可选择设置 maxItems 总上限。第一次检查时，用 1 条预定的已知内容 URL、contentUrls 模式和 maxItems 1 替换 Task 示例，以替换已保存预设中的 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. 写下框架与纳入规则，以及已知公开主页或帖子 URL 是如何取得的。已接受的路径从预先确认的帖子 URL 开始。它不能发现假定的数百万个公司主页。如果不存在有效框架，先决条件是取得一份适当且已获许可的现有数据集，或改变研究问题。
3. 根据明确假设计算计划体量：选定主页数乘以每个主页已提供的不同帖子数，再乘以已保存的观察边界数。对同一帖子的重复观察不是新帖子。在稳定身份检查下计入重复或共享的帖子。主页检查是单独的获取记录。
4. 把声明的有限范围与提议的普查相比较。用与问题相称的书面设计选择账号和帖子；如果是立意抽样或便利抽样，要写明这一限制。来源缺口和可见性不均会改变纳入资格。仅仅降低行数，并不能由此得出总体估计。
5. 选择 1 个边界，或 1 份重复的前瞻性时间表。当前 Actor 提供的是当前公开观察，不是过去的计数。对同一选定帖子框架，3 个未来边界会使计划的指标观察变为 3 倍。缺失的来源结果仍然缺失，不是零。需要过去每月历史的研究，必须使用[已保存的历史](/zh-Hans/articles/%E6%9C%88%E5%BA%A6-instagram-%E6%B5%8F%E8%A7%88%E6%8A%A5%E5%91%8A-%E5%8C%BA%E5%88%86%E6%97%A7%E5%B8%96%E4%B8%8E%E6%96%B0%E5%B8%96/)或适当的现有来源，不能使用编造的回填。
6. 检查当前定价与计费规则，并在支持该设置的运行设置中，设置有限的单次运行费用上限。行数上限和费用上限是不同的控制。把已记录的启动事件和结果事件，以及任何单独计费的用量或存储，计入预算。此处不假定一般费率或真实零售价格。
7. 在扩大规模之前，用单条已知帖子的试点检查所需字段、来源身份和状态，以及计数精度。把处理时间与来源延迟分开。1 次快速结果不能证明数百万条输入上的线性吞吐，也不能证明未来来源仍然可得。
8. 保留一份计划与收据对照表。计划观察描述的是预定工作；尝试的输入描述的是执行；已保存记录包括已进入存储的内容；可用记录满足字段规则；可计费事件来自实际计费收据的事件定义。不要假定已保存等于可用等于已计费。如果所需范围超出经费，应寻找适当的数据集，或收窄问题。

## 建立项目账本和预算

本节使用原创虚构内容作为教学示例。

就历史来源假设的示例而言，取 1,000,000 家公司乘以 60% 有主页，再乘以 60 条帖子，得到 36,000,000 条帖子。按每条帖子 10 秒计算，等于 360,000,000 秒，即按每天 86,400 秒计算为 4,166.6667 天。这是给读者的来源假设示例，不是测得的可得性、Actor 延迟或运行时间预测。另一种 80% 的假设会改变该估计，不得与前者混合。

就这份原创的有限虚构研究而言，取 40 个预先确认的主页，每个主页 5 个不同的已知帖子 ID，合计 200 条不同帖子。3 个计划中的前瞻边界产生 600 次计划指标观察。40 次主页检查是单独的记录。稳定身份用于核对不同性。立意或便利框架不是对一百万家公司总体的推断。

下面是实际的 5 类项目账本和 2 行预算表。虚构费率为每次可计费观察 USD 0.002，每次运行启动费 USD 0.001，共 3 次运行。

表：原创虚构项目账本

| 项目账本 | 数量 |
| --- | --- |
| 计划观察： | 600 |
| 尝试的输入： | 600 |
| 已保存记录： | 570 |
| 可用观察： | 540 |
| 可计费事件： | 540 |

30 次尝试没有已保存记录，另有 30 条已保存记录未通过可用字段规则。即使点赞和评论可用，缺失的公开观看计数仍然未知。

表：原创虚构预算行

| 预算 | 计算 |
| --- | --- |
| 第 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/)