How to Keep a Register of Newly Observed Instagram Comments

1. Define the posts and the collection limits

Start with a written list of known public post URLs. A URL is a web address. Keep the same list when you compare runs, or record each change to the list. A run is one execution of a collection program with one set of inputs.

Write down these choices before collection:

1. List the public posts you will check.
2. Choose the interval between checks.
3. State how much delay or missed coverage your use can accept.
4. Set the maximum number of saved comments per post.
5. Choose the comment order.
6. Record any publication-date filters.
7. Give each collection a reference that you can retain with its export.

A cap is the maximum number of records you ask to save. It is not a promised result count. A collection interval tells you when you plan to check again. It does not prove that every comment between checks will appear.

If your use requires proof that every new comment was captured, this method cannot provide that proof. It provides a record of observed comments and visible collection limits.

Chronometrica’s Instagram Comments Scraper is an Actor, meaning a hosted collection program. Its checked public contract documents known public post inputs, top-level comment records, date filters, and a per-post cap. It has no documented since-last-run or new-comment-only input. Your own comparison process must identify unseen IDs. Instagram Comments Scraper, checked October 25, 2026; documented public collection fit, no runtime test for this guide.

This guide uses public records. It does not obtain private account records or owner-only account reports. Do not describe the register as a complete account notification history or a user’s full Instagram comment history.

2. Keep a register and a separate observation log

Use two saved tables. A table holds records in rows and named values in columns. A key is a value, or combination of values, that identifies one record.

The comment register uses `commentId` as its key. The documented contract describes this field as the stable Instagram ID of a top-level comment. Store IDs as text so their exact characters remain unchanged.

The observation log records each collection in which you saw that ID. Use the combination of `commentId` and your collection reference as its key. This lets one comment appear in several collections without becoming several comment identities.

The following tables propose fields for your storage. Fields such as `first_seen_at` and `collection_ref` belong to your process. They are not additional Actor output fields.

Keep the complete original export as well. JSON is a text format for structured records. Retaining the original JSON helps you check values after you build the tables.

Keep the three times distinct

`createdAt` records when the source says the comment was published. It can be null, meaning unavailable.

`collectedAt` records when the Actor collected the comment, in UTC. UTC is a common time standard. Preserve this time from the source row.

`first_seen_at` records when your register first accepts the comment ID. State this rule in your method note. If you import an older export today, its collection time remains the older time. Its first acceptance in your register occurs today. Do not make the times appear equal unless they actually are equal under your stated rule.

The checked output also documents author details, like counts, and reply counts. A reply count is not reply text. Keep zero counts separate from unavailable counts. Keep `ownerVerified` false separate from null. A missing author ID does not mean author ID zero, and it does not erase a valid comment ID. Public build 0.1.21, checked October 25, 2026; documented fields and null rules, not a current runtime result.

This register counts comment identities. It does not count distinct accounts or people. If you also need a checked working file, the public comment sample guide explains a separate export and import workflow. Keep that work separate from deciding whether an ID is newly observed.

3. Check one post with a small input

Start with one known public post and a cap of 10. Use the supplied input:

{"collectAllAvailable":false,"commentSortMode":"default","maxCommentsPerPost":10,"postUrls":["https://www.instagram.com/reel/DZu6dkVyImf/"]}

Replace the sample Reel address with your intended public post or Reel address. Replace the sample rather than adding your address beside it.

`postUrls` contains the target addresses. `maxCommentsPerPost` limits saved unique top-level comments for each post. `commentSortMode` selects the order. The value `default` keeps Instagram’s default order. `collectAllAvailable` false keeps the numeric cap in effect.

This supplied input passed a static schema check. A schema defines accepted input fields and value types. The check confirms the input’s form. No run was made for this guide, and the check does not confirm live availability. Public input contract, checked October 25, 2026; static validation only, no paid run.

After your own run, follow these steps:

1. Save the exact input and collection reference.
2. Retain the unchanged export.
3. Compare each returned post address and short code with the requested post.
4. Check comment IDs, text, and times against the original records.
5. Separate records whose comment identity or post match cannot be confirmed.
6. Add accepted IDs to the initial register.

A null `postId` is allowed by the documented output. Check the available post address and short code rather than inventing a post ID. A missing `commentId` prevents a reliable register match. Keep that row unresolved, meaning it needs review before acceptance. Identical words do not repair a missing ID.

Treat the first collection as your starting register. Its IDs are newly known to that register. Their presence does not prove that the comments were recently posted.

4. Compare the next export by ID

For each later collection, compare accepted comment IDs with the register as it existed before that update.

1. If an ID is absent from the register, add one comment entry.
2. Set its `first_seen_at` under your stated first-acceptance rule.
3. Preserve its source `createdAt`, including null when unavailable.
4. Add the observation with its collection reference and `collectedAt`.
5. If the ID already exists, keep the register entry and add the new observation.
6. Compare its text with the prior saved text.
7. Keep changed text as another dated version and flag the difference.

“Newly observed” means the ID was previously unknown to your register. “Repeated” means the ID was already known before this collection’s update. Neither label depends on the comment’s publication date.

Two comments can have identical words and different IDs. Keep both. One ID can appear in several collections. Keep one register entry and several observation references.

If text differs for a known ID, retain the earlier wording used in any prior report. The comparison establishes a difference between saved records. It does not, by itself, establish who changed the wording or why.

Keep the update result linked to its collection reference. On replay, reuse that result rather than presenting the original new IDs as fresh discoveries again. Replay means processing the same saved export again.

Metric history has a different unit: a saved reading of a count. The Instagram snapshot guide covers that separate problem. Here, a later observation of the same comment adds evidence about one identity. It does not add another comment identity.

5. Work through a late discovery

The following worked example is original fiction. It is not Actor output, a customer result, or a test result. All times refer to the same fictional day in UTC. Assume the register accepts each export at the stated check time.

At 10:00, the first bounded export contains C1 and C2. Both IDs enter the empty register.

At 11:00, the second export contains C2 and C3. C3 has a source publication time of 09:30. It was published before the first check, but the first export did not contain it.

The register arithmetic is:

• After the first update: 0 known comment identities + 2 new identities = 2 known identities.
• Second update: 2 known identities + 1 new identity = 3 known identities.
• Second export: 1 repeated ID + 1 newly observed ID = 2 distinct exported IDs.

The register now contains C1, C2, and C3. These are three known comment identities. They are not a count of three people.

C3 keeps `createdAt` 09:30 and `first_seen_at` 11:00. Do not describe it as posted after 10:00. “Not specified” for C1 and C2 means this fictional example gives no publication time. It does not mean midnight or zero.

C1 remains in the register. Its absence from the second export does not prove deletion or moderation. This example does not establish why it was absent.

The two collections contain four observation records: 2 observations + 2 observations = 4 observations. The register contains three comment identities. Those totals measure different things.

Now replay the second export with the same collection reference. The expected register result is:

• 3 existing comment identities + 0 new identities = 3 known identities.
• 0 new first-seen entries.
• 0 additional observation records for the same comment-and-collection keys.

C3’s first observation remains 11:00. Reprocessing the file does not create another discovery.

6. Use date filters with an explicit overlap

The Actor documents `commentsFrom` and `commentsUntil` as filters on comment dates. They do not filter on your register’s first observation time. Public input contract, checked October 25, 2026; documented date inputs, no since-last-run switch or runtime test.

If you use date filters, allow a stated overlap between collection windows. An overlap means the next date window includes part of the earlier window. Compare IDs to prevent those repeated records from creating new register entries.

Choose and record the overlap for your use. The frozen evidence does not establish a universally safe overlap length.

The fictional C3 shows the remaining risk. A later request that excludes publication times before 10:00 would exclude C3’s 09:30 publication time. That comment would remain undiscovered even though your register had never seen it.

An overlap can include older publication dates. It cannot prove complete discovery. Comments outside the chosen window can still be absent from the result.

The order setting also has limits. `newest` and `oldest` sort the collected top-level comment sample by date. They do not establish that every eligible comment reached the sample. Default order does not establish chronological collection.

Setting `collectAllAvailable` true removes the numeric cap. The documented run can still stop when the public feed ends, time runs out, or the source fails. Removing the cap therefore does not prove complete source coverage and may cost much more. Keep the bounded setting while you check the register method.

7. Record gaps for every requested post

Keep a coverage note beside each collection. Coverage means the part of the requested source that the saved result can support. Compare the requested post list with each export, including requests that produce no accepted rows.

Do not convert an unknown state into a successful result. If you cannot confirm why collection stopped, record that the reason is unknown.

Keep these failure states separate:

• No returned rows: No comments were observed in that result. This does not prove the post had zero comments.
• Missing comment identity: Preserve the raw row for review. Do not match it by text or author name.
• Unconfirmed post match: Keep the row unresolved until its target is confirmed.
• Known cap reached: Report the cap as a coverage limit. Do not treat it as the post’s total comment count.
• Known ID absent later: Retain the register entry. Do not assert deletion or moderation.
• Unavailable time: Keep it missing. Do not substitute a publication time or first observation time.
• Changed input: Record the change. A different cap, order, or date window changes the comparison’s scope.

The output documents public like and reply counts. Zero is a known zero. Null is unavailable. Neither a missing reply count nor a nonzero reply count supplies reply text. Keep these meanings when you retain the raw records.

8. Check the update before using it

Deliver four separate results for each collection: newly observed IDs, repeated IDs, changed-text cases, and unresolved coverage. Changed-text cases can also be repeated IDs. Do not add overlapping groups as though they were separate comment totals.

Accept the update only after these checks:

1. Trace each accepted ID to its source post and raw export.
2. Confirm that new IDs were absent from the register before the update.
3. Confirm that older publication times remain unchanged.
4. Confirm that known IDs retain their original first observation.
5. Confirm that changed text retains its dated versions.
6. Replay the same export with the same collection reference.
7. Confirm zero new comment identities and zero new first-seen entries on replay.
8. Check that every requested post has a result or a stated gap.

These are proposed checks for your process. They are not results from a run performed for this article.