How to Export a Monthly Instagram Post Report With Only the Counts You Need

1. Define the month and the count time

Write the publication month, year, and time zone before you select posts. The publication time is when the post was published. The observation time is when you collected its counts.

Use the first instant of the month as the start. Use the first instant of the next month as the end. Include the start and exclude the end. This rule prevents a post at the next month’s start from entering both reports.

Choose which question the spreadsheet must answer:

1. What are the current public counts for posts published in the selected month?
2. How much activity occurred during the selected month?

This method answers the first question. A post published in September can have counts collected on October 25. The September publication date selects the post. The October observation time describes the counts.

If the request means activity during September, change the evidence request before you collect current counts. A current count cannot establish what the count was on September 30. Do not rename an October observation as a September month-end reading.

Also define the account and the source list. A report for a limited list must say so. A suitable report title is “Current observations of known September posts.” Add the year and the actual observation date in your own report.

2. Build a checked post list

A roster is the list of posts you intend to include. Start with the owner’s checked publication register or an existing export. A publication register records which posts were published and when.

Check whether that source covers the requested account and month. Keep a note about its coverage. Coverage means how much of the requested post list the source supports. Do not assume that an export contains every post because it has many rows.

If no owner list is available, prepare a limited list of known public post URLs by hand. Label it as a limited list. Do not promise all monthly account posts from that evidence.

For each candidate post, save its requested URL and the publication evidence. Use a stable post ID when you have one. A post ID identifies one content item. A URL is its web address.

Keep these decisions visible:

Do not use the day you found a post as its publication date. Do not treat an unknown date as proof that the post falls outside the month.

Use one row per content item. If two URLs resolve to the same checked post ID, keep the requested URLs in your source record and report the post once. Matching captions alone do not prove that two rows are the same post.

The guide to a checked Instagram posting inventory explains the related date and coverage boundary. For this report, use the checked identities and dates. You do not need its format or posting-rate analysis.

3. Check one known public URL

An Actor is a hosted program that collects data. The Instagram Metrics Scraper documents direct collection from known public content URLs. Its checked public input accepts `mode` set to `contentUrls`, a list in `startUrls`, and an optional total row cap in `maxItems`.

A cap is a maximum, not a promised result count. The documented input also supports profile discovery. This method uses your checked content list. It does not rely on profile discovery to establish a complete monthly history. See the public build contract, checked October 25, 2026; documented input and output only.

Use this supplied small input for the first check:

{"maxItems":1,"mode":"contentUrls","startUrls":["https://www.instagram.com/reel/DIwcCZgxVZP/"]}

Before you run it:

1. Replace the sample URL with one known public post or Reel URL from your list. A Reel is an Instagram video post.
2. Keep `mode` set to `contentUrls`.
3. Keep `maxItems` set to `1` for this one-item check.
4. Compare the returned identity, date, counts, and states with the requested post.

The supplied input has a valid documented shape. No run was made for this guide. The sample URL is not evidence for your monthly report.

For a larger checked roster, replace the sample list with your intended URLs. Choose a cap large enough for those items. Then match every requested post to the returned data. A larger cap does not guarantee that every post will have usable counts.

The public Instagram Brand Campaign Metrics Task, checked October 25, 2026; page presence only is a possible starting page. A Task is a saved input preset. Its saved settings were not checked through an authenticated account, and it was not run. Check the input yourself before use.

4. Keep the fields that explain each count

Keep the count fields and the evidence needed to read them. The documented output includes the following fields. Their presence in the contract does not mean every returned row will contain every value.

Precision describes how exact a count is. The documented `postMetricStatus` can distinguish exact, rounded, unavailable, and unknown precision. It also records whether a metric is present, unavailable, or not attempted.

Read the likes and comments entries separately. A row can have a usable value for one count and a gap for the other. A returned row is therefore not enough to prove that both counts are usable.

Keep missing counts empty. Enter zero only when the source actually provides zero. An empty cell means you do not have that value. Zero means the observed count is zero.

Keep rounded values identified as rounded. Do not present a total from rounded values as exact. If you need an exact-only total, select rows with documented exact precision and state that rule.

Add your own report columns for the publication-month decision, publication evidence, and coverage note. These are checks you perform. Do not describe them as analysis produced by the Actor.

Public likes and comments are counts, not a count of unique people. This method does not provide private reach, saves, shares, or a paid-versus-organic split. Organic means activity not attributed to paid advertising. If the request needs owner-only records, ask for the appropriate owner source instead of filling those columns from public counts.

5. Match every requested post to the output

Reconciliation means matching your requested list to the returned rows. Start from the roster so that a missing result remains visible.

For every requested post:

1. Look for a matching `inputUrl`, checked `postId`, or returned `postUrl`.
2. Read `status` and `statusReason` when a row exists.
3. Confirm the publication-month decision from the checked evidence.
4. Inspect likes and comments separately, including their metric states.
5. Retain the actual `scrapedAt` value.
6. Keep a report row even if no usable counts were returned.

If a post has no returned row, preserve its requested identity from the roster. Do not invent an Actor status or collection timestamp. Record that the result was absent in your own report note.

A cap that is too small can leave requested items unprocessed. A cap that is large enough still does not prove that all counts were available. Read the returned evidence rather than treating the number of output rows as proof of success.

Preserve the source rows when you resolve a conflict. Your delivered file should have one count row per post, with enough evidence to explain each decision.

6. Export and inspect the spreadsheet

Export the selected columns to CSV or use the platform’s spreadsheet export. CSV means comma-separated values. It is a text file that stores data in rows and columns.

Import post IDs as text. They identify posts; they are not quantities for calculation. Keep timestamps with their time zone. Do not discard the zone when you format the date cells.

Check the imported file before you calculate:

1. Inspect the first and last rows for column alignment.
2. Compare every requested identity with the delivered rows.
3. Confirm that unavailable posts remain present.
4. Check that empty count cells did not become zero.
5. Check that IDs remain text and timestamps remain readable.
6. Confirm that metric-quality information survived the export.

If `postMetricStatus` is difficult to read in one spreadsheet cell, make separate likes and comments quality columns. Copy the documented state and precision into them. Keep the source values available so another reader can check your summary.

Define which rows can enter each calculation. These are eligible rows. The denominator is the number you divide by when you calculate a mean. A mean is the total divided by the eligible row count.

Report the number of posts with usable likes separately from the number with usable comments. If the two counts differ, their means need different denominators. If no rows qualify, report the result as unavailable rather than zero.

7. Worked example: original fiction

This example is original fiction. P1, P2, and P3 are invented reader records. They are not Actor output.

The fictional roster contains three checked September posts. Their counts were observed on October 25. The example does not supply individual publication timestamps, an observation clock time, a time zone, or metric-precision records. It teaches missing-row handling and arithmetic. It is not a fully accepted production file.

Keep all three rows in the delivered CSV. The empty cells for P3 mean unavailable counts. They do not mean zero likes or zero comments.

The calculations for these fictional usable rows are:

1. Usable likes coverage: 2 posts out of 3 requested posts.
2. Observed likes total: 100 likes + 200 likes = 300 likes across 2 usable posts.
3. Mean observed likes: 300 likes / 2 usable posts = 150 likes per usable post.
4. Usable comments coverage: 2 posts out of 3 requested posts.
5. Observed comments total: 10 comments + 20 comments = 30 comments across 2 usable posts.
6. Mean observed comments: 30 comments / 2 usable posts = 15 comments per usable post.

A suitable report note is: “The two usable rows contain 300 observed likes and 30 observed comments on October 25. The three-post roster includes one unavailable row.”

Do not describe 300 as all September likes. It excludes P3’s unknown value. It also describes an October observation of September publications. Do not call it a September month-end total.

Do not divide 300 by 3 to report a three-post mean. That calculation would treat the missing count as zero. The supported mean uses the two usable rows only.

8. Accept the report with its limits

Accept the file when each included post has a checked identity, a publication-month decision, a known observation time for returned counts, and a clear count state. Keep unresolved candidates visible until their membership can be checked.

Your report note must name the source list and its coverage. It must also state the count observation time, the usable-row count for each metric, and the rule used for totals or means. Do not describe a partial known-post list as complete account history.

If the request changes to month-boundary activity, use different evidence. The guide to saved month-boundary observations explains that separate requirement. A publication-month label cannot turn current counts into historical readings.

This is a proposed workflow based on checked public documentation. The supplied evidence includes no paid run or measured reliability result. It supports the documented collection fit, not a claim that the Actor completes or validates the report for you.