How to Size an Instagram Research Collection Before You Run It

Setting up a finite post frame

An Actor is a hosted data collection program. A Task is a saved input preset. The Instagram Metrics public build 1.0.35 supports mode contentUrls with startUrls containing known public post or Reel URLs and an optional total maxItems cap. For the first check, replace the Task sample with one intended known content URL, mode contentUrls, and maxItems 1, replacing the saved preset maxItems 100. Do not add an invented maxItemsPerProfile flag. Profile discovery is a separate mode; its current source pilot was blocked and is not accepted.

Relevant native fields are inputUrl, postUrl, postId, shortCode, mediaType, publishedAt, profileId, profileUrl, likes, comments, views, plays, postMetricStatus, status, statusReason, and scrapedAt. The current accepted direct known-Reel retry returned matching identity/date and public likes/comments/views with metric status; plays was null. Native postMetricStatus separates metric availability and precision.

OUTPUT providedInputs, contentUrls, profileUrls, inputUrls, maxItems, resolvedUrls, metricRows, noPublicMetricRows, blockedRows, failedRows, invalidRows, unsupportedRows, statusCounts, and stopReason are collection accounting, not a planned, usable, or billed project ledger.

Calculating planned volume

1. Define the unit and needed public fields. A company-level model, a post-level description, and a repeated-change study require different frames. Do not turn assumed profile/post counts into observed availability or promise a free high-scale workaround.
2. Write the frame/inclusion rule and how known public profile/post URLs were obtained. The accepted route starts from preconfirmed post URLs. It cannot discover assumed millions of company profiles. If no valid frame exists, obtaining an appropriate permitted existing dataset or changing the research question is a prerequisite.
3. Calculate planned volume from explicit assumptions: selected profiles times distinct supplied posts per profile times saved observation boundaries. Repeated observations of the same post are not new posts. Account for duplicate or shared posts under stable identity checks. Profile checks are separate acquisition records.
4. Compare a declared finite scope with the proposed census. Select accounts and posts using a written design appropriate to the question; if purposive or convenient, state that limitation. Source gaps and unequal visibility alter eligibility. No population estimate follows from merely lowering the row count.
5. Choose one boundary or a repeated prospective schedule. The current Actor gives current public observations, not past counts. Three future boundaries triple planned metric observations for the same selected post frame. Missing source outcomes remain missing, not zero. A study requiring past monthly histories needs saved history or an appropriate existing source, not fabricated backfill.
6. Check current pricing/charging rules and set a finite per-run charge limit in the run settings where supported. A row cap and a charge cap are different controls. Include documented start and result events and any separately charged usage or storage in the budget. No general rate or real retail price is assumed here.
7. Use the one-known-post pilot to check required fields, source identity and status, and count precision before expansion. Separate processing time from source delays. One fast result does not establish linear throughput over millions of inputs or future source availability.
8. Keep a plan-versus-receipt table. Planned observations describe intended work; attempted inputs describe execution; saved records include what reached storage; usable records satisfy the field rule; billable events come from the actual billing receipt event definition. Do not assume saved equals usable equals billed. If the needed scope exceeds funding, seek an appropriate dataset or narrow the question.

Building the project ledger and budget

This section uses original fiction as a teaching example.

For the historical source-assumption illustration, take 1,000,000 companies multiplied by 60 percent with profiles multiplied by 60 posts, giving 36,000,000 posts. At 10 seconds per post, this equals 360,000,000 seconds, or 4,166.6667 days at 86,400 seconds per day. This is a reader source-assumption illustration, not measured availability, Actor delay, or a runtime forecast. An alternate 80 percent assumption changes the estimate and must not be blended.

For the original finite fiction study, take 40 preconfirmed profiles and 5 distinct known post IDs each, totaling 200 distinct posts. Three planned prospective boundaries produce 600 planned metric observations. Forty profile checks are separate records. Stable identities verify distinctness. A purposive or convenience frame is not a million-company population inference.

Below is the actual 5-category project ledger and 2-row budget table under an invented rate of USD 0.002 per billable observation and a USD 0.001 start fee per run across three runs.

Table: Original fiction project ledger

Thirty attempts had no saved record, and thirty saved records failed the usable-field rule. A missing public view counter remains unknown even when likes and comments are usable.

Table: Original fiction budget rows

Actual billing follows real event definitions and receipts, not a saved equals usable equals billed assumption. A per-run charge control is not a whole-project cost cap.