How to Audit Instagram Content Formats and Posting Cadence

What you collect

An Actor is a hosted data collection program. A Task is a saved input preset. The Instagram Metrics Scraper Actor collects source rows. You build the calendar, the counts, and the schedule choice.

The current public build is 1.0.35. That build was checked on 2026-10-13. The accepted modes are auto, contentUrls, and profileUrls. Use contentUrls for this audit. That mode means you supply content URLs. profileUrls takes account names. Put the URLs in startUrls. maxItems is an optional cap on the total number of rows.

A content row is one public content item with at least one public metric. A failed URL may show up as a gap instead of a content row. Use these fields:

scrapedAt is not the publication time. Do not use it as the post date.

You may see these public counters. They can be absent. They are views, plays, playsInstagram, likes, and comments. Keep each counter in its own field. Do not add them together. Do not turn them into a private audience size. This audit uses the date and the format.

A date can be missing. A format label can be missing. Missing is unknown. Unknown is not zero.

The current saved Task is Instagram Content Publishing Cadence Source Data. A Task is only a starting input. It does not mean the count is automatic. The saved input is:

{
  "mode": "profileUrls",
  "startUrls": ["@nike", "@adidas", "@playstation"],
  "maxItems": 60
}

Change that input before this audit. Set mode to contentUrls. Replace @nike, @adidas, and @playstation with known public post URLs or Reel URLs. A Reel is a public Instagram video post. In a saved row, the format label reel names a Reel. A pilot is a small first test. For the pilot, set maxItems to 3. Use three URLs so the cap matches the list.

{
  "mode": "contentUrls",
  "startUrls": [
    "FIRST_KNOWN_PUBLIC_POST_OR_REEL_URL",
    "SECOND_KNOWN_PUBLIC_POST_OR_REEL_URL",
    "THIRD_KNOWN_PUBLIC_POST_OR_REEL_URL"
  ],
  "maxItems": 3
}

Replace the three stand-in texts with real public URLs. Do not leave the example account names in startUrls.

The saved profile preset is not accepted for account discovery. It is not accepted as full history. A profile-mode pilot on @nike returned no_profile_content. The discovery record was blocked_or_challenged. That result does not prove that @nike had no posts. blocked_or_challenged does not mean the account is empty.

A separate test used one known public Reel URL. That is the accepted route for this audit. The saved row had a postId. It included account fields. Its mediaType was reel. It had publishedAt. A caption was present. Public metrics were present. That one Reel does not prove full history. These are checked product facts. They are not the fictional calendar later in this article.

There is no checked complete archive. There is no checked search by date range. A full-looking page does not prove full coverage. A reached cap does not prove full coverage. Success on metrics does not prove that you listed every post.

The current README is the Actor's public instructions. Those instructions mention maxItemsPerProfile. The current input schema is the list of accepted input fields. That list does not include maxItemsPerProfile. Do not set that field.

maxItems counts rows across the whole collection. It does not count one account at a time. A small cap can cut a longer URL list. In the saved output, inspect providedInputs, contentUrls, inputUrls, resolvedUrls, metricRows, stops, and statuses. Match those parts to the URL list you planned to collect.

Do the audit in eight steps

1. Choose two or three known competitor accounts. Choose one UTC window for all of them. UTC is the world clock used for every date here. One clock keeps a late post on one date. The same window keeps the compare fair. A busy month against a quiet month would not be fair. Example length: 28 days, which is 4 weeks. Write the end time as exclusive. Exclusive means the end instant is outside the window. The next window can start at that same instant. One post is then not in both windows. Use one inclusion rule for every account. Include ordinary public posts and Reels with a known time inside the window. Exclude Stories. A Story is a short-lived Instagram item. This Actor does not collect Stories. Say how you treat pinned posts. Include a pinned post by its publication date. Do not use its place on the screen. A pin can be old.
2. Build the URL inventory by hand. An inventory is the list of known content URLs you plan to collect. Use the public accounts you chose, or another listing method you already verified. This article does not give a way to discover accounts. Save inventory_date, the account key, the content URL, and a short collection note. inventory_date is the date you built the list. Mark coverage complete_for_checked_source only when evidence supports that mark. That mark means the checked source is covered. It does not by itself mean the whole account history is covered. Otherwise mark partial/unknown. A full-looking page is not enough evidence. A reached cap is not enough evidence.
3. Send known content URLs in mode contentUrls. Use a small total cap first. The pilot cap is maxItems 3 with three known URLs. Compare each saved row with the URL you sent. Look at postId, the account fields, mediaType, publishedAt, status, and statusReason. Use only input fields the current schema accepts. Do not add maxItemsPerProfile. A small pilot shows that the route works before a long list. The one known Reel above is the success example. The @nike profile result is not that example.
4. Match every planned URL to a saved row or to a gap. Keep failed and unavailable inputs on a separate list. Read a known publishedAt as UTC. Keep the row when that time is inside the window. If publishedAt is missing, put the row on an unresolved side list. Do not call a missing date outside the window. Outside would hide a row that might belong inside. Inside would invent a date. scrapedAt does not choose the window. A row with metrics can still be outside your inventory. Metrics do not prove the list is complete. Use a match table like this. Fill it from your collection. The calendar later in this article is fiction, not this table.

1. Count the same post once. Use a postId that is present and that you verified. If postId is missing, review the resolved post URL before you count the row. A missing identity needs review. Do not delete it without a note. Do not treat it as a sure duplicate. Equal titles or captions do not prove a duplicate. Two captions can match by chance. A collaboration duplicate is the same content ID saved more than once. Count that ID once inside one account inventory. Keep the source rows. Keep a note when two rows conflict.
2. Keep the mediaType text that the row already has. Do not rename a label. If the label is missing, keep the format unknown. Build one daily calendar for each account. Build one format-count table. A day with no included row means no included record for that day. It proves the account published nothing only when that day's coverage is good enough. If coverage is partial/unknown, write "no included record". Do not write that nothing was published.
3. Divide included known-date posts by the weeks in the window. That result is the observed posting rate. Use this plain formula. posts per week = included known-date posts / weeks in the window. For format share, use all included posts as the bottom number. Share means one format's part of that bottom number. format share = count for that format / all included posts. Keep unknown formats in that bottom number. You can also make a second mix that uses only known formats. Say that the bottom number changed. Do not call either mix a best mix. Do not call the rate a best rate for every team. A rate on a partial list is the rate for that list. It is not the full account rate.
4. Compare the rate, the longest observed gap, and the format mix. Put a coverage note on each compare. Keep every publication time in UTC. A gap between two known dates is an inter-post gap. A gap from the window start or window end to the nearest included post is a boundary gap. Keep boundary gaps separate. Do not average the two kinds unless you write the rule first. An average without a rule makes up a new number. Save a planning question with the table. Ask whether your team can keep the schedule. Do not claim how many people saw the posts. Do not claim that the same people follow both accounts. Do not claim you know how Instagram orders posts. Do not claim that the dates caused better results.

Worked example in original fiction

The calendar below is original fiction. It teaches the counts. It is not an Actor result. It is not the @nike pilot. It is not the known Reel test. No counter in this fiction shows that Reels are better. No counter shows that a higher rate is better.

The fictional window starts at 2026-09-01 00:00 UTC. It ends at 2026-09-29 00:00 UTC. The end is exclusive. The length is 28 days. 28 / 7 = 4 weeks.

Account A has six included posts with known dates. The dates are Sep 2, Sep 5, Sep 9, Sep 13, Sep 20, and Sep 27. Four rows use the label reel. Two rows use the label carousel. Carousel is a fictional format label here. It is not a claim about every live label list. Account A also has one observed row with no date. That row stays off the six.

Account B has four included posts. The dates are Sep 3, Sep 10, Sep 17, and Sep 24. One row uses reel. Two rows use image. One row has no format label, so the format stays unknown. Account B's list is a partial public inventory. Sample here means that partial list. It does not mean a scientific sample. B's rate is the rate for the partial list. It is not a confirmed full-account rate.

Both accounts are partial/unknown. The fiction does not support complete_for_checked_source. It does not support a full-account complete mark.

Eleven fictional rows

Row 7 is the undated side-list row. It is not one of the six known-date posts. The window total for Account A can change after review. The fiction does not give row 7 a format. The format stays unknown.

The eleven rows are 6 included for A, plus 1 unresolved for A, plus 4 included for B.

Calendar by week

Week 1 is 2026-09-01 through 2026-09-07. Week 2 is 2026-09-08 through 2026-09-14. Week 3 is 2026-09-15 through 2026-09-21. Week 4 is 2026-09-22 through 2026-09-28. The end instant on 2026-09-29 is outside all four weeks.

A day in the last column is an observed zero record. It means no included row on that day. It does not prove that the account published nothing. Coverage is partial/unknown for both accounts. For Account A, Sep 1 has no included record. The boundary gap from Sep 1 to Sep 2 is a different note. It is not a second post. A-07 does not fill any day. Its date is unknown, not a zero day.

Format counts by week

A zero in this table means no included record for that format in that week. It is not proof that nothing was published.

Check the totals. Account A weeks are 2 + 2 + 1 + 1 = 6. Account B weeks are 1 + 1 + 1 + 1 = 4. A reel is 2 + 1 + 1 + 0 = 4. A carousel is 0 + 1 + 0 + 1 = 2.

Rate, share, and coverage

The share math is:

• A reel: 4 / 6 = 0.667, which is 66.7 percent.
• A carousel: 2 / 6 = 0.333, which is 33.3 percent.
• B reel on all included posts: 1 / 4 = 0.25, which is 25 percent.
• B image: 2 / 4 = 0.5, which is 50 percent.
• B unknown: 1 / 4 = 0.25, which is 25 percent.
• B known formats are 1 reel + 2 images = 3. The unknown row is left out of this second mix.
• B reel on known formats only: 1 / 3 = 0.333, which is 33.3 percent.

Do not place A's 66.7 percent beside B's 33.3 percent as the same kind of share. A's bottom number is 6 included posts. B's 33.3 percent uses 3 known-format posts. Name the bottom number every time.

Gaps

Account A known-date gaps, in order, are 3, 4, 4, 7, and 7 days. The longest observed inter-post gap is 7 days.

B's inter-post gaps use the same subtraction as A's gaps. They are gaps in the partial list. They are not proof that Account B published nothing in between. A's 7-day gap is the longest gap among its known dates. It is not proof of an empty week unless coverage for those days is good enough. This fiction does not have that coverage.

Do not average the boundary gaps into the inter-post gaps. For Account A, the boundary gaps are 1 day and 2 days. They answer a different question. They show the wait from the window start or window end. They do not show the wait between posts.

A planning choice from this fiction

Account A's checked rate is 1.5 posts per week. Account B's partial-list rate is 1 post per week. A team that cannot keep 1.5 should not adopt 1.5. A fair trial inside this fiction is 1 post per week for 4 weeks. That matches the lower observed list. Record the format of each of the 4 posts. You may look at A's mix, which is 4 reel rows out of 6 included posts. Do not set that mix as a goal that improves results. This fiction does not show a winning format. Ask if the team can keep the chosen format for the whole window. If the answer is no, choose a slower schedule. Then repeat the same window rules on the next 28 days.