Chronometrica vs Herus13 Instagram Comment Scraper: Which Counts Top-Level Comments?

An export request does not define the comment unit

The reader’s question was how to export comments from an Instagram Reel. The question did not specify a statistical sample, a reply analysis, or a required number of top-level comments. Those are choices the reader must make for their own work. Original Reddit question

Start with the work you want the export to support. You might need direct responses to a Reel, exchanges between people, or a record for later review. These tasks can need different rows even when they use the same Reel URL.

A row cap sets a collection limit. It does not explain what the collector counts toward that limit. If your work requires 100 top-level comments, a setting of 100 is useful only when you know which rows use that allowance.

The denominator is the unit behind a count. Here, the important denominator is the type of comment counted toward the cap. Record it before collection. A note that says “limit: 100” leaves this unclear. A note that says “limit: 100 unique top-level comments per post” gives the number a clear meaning.

Also separate a cap from a target. A cap of 100 permits up to 100 qualifying rows. It does not promise that the source has 100 available comments or that the collection will return that many.

Compare the contracts that affect your choice

Chronometrica’s public input uses `postUrls` for public post or Reel URLs. Its `maxCommentsPerPost` setting limits unique top-level comments for each post. The default is 100. Its `repliesCount` value is a reply count, not reply text. These facts support a top-level collection workflow. Chronometrica contract

The table separates checked product facts from checks you must make for your own work.

Product evidence: Chronometrica and Herus13.

Herus13 also documents failure rows, flat CSV views, and public-only access. It can be filtered after collection. Herus13 contract

A narrower output unit does not prove better completeness. This evidence supports a choice about collection scope. It does not establish a winner for speed, accuracy, reliability, coverage, or total cost.

Filtering an export and setting a collection cap are separate operations. A later filter can remove unwanted rows. It does not, by itself, collect more rows to replace them. Check the size of the retained set before you use it in an analysis.

Fictional example: 100 rows can contain fewer than 100 top-level comments

This example is fictional. It is not a test, a customer result, or a measured dataset.

A researcher wants to study direct responses to one Reel. The study needs up to 100 top-level comments. Reply text is outside the study because it can respond to another person rather than directly to the Reel.

Suppose an export contains these rows:

• 70 top-level comments.
• 30 replies.
• 100 rows in total.

The arithmetic is correct: 70 + 30 = 100. But the export contains 70 top-level comments, not 100. If the researcher removes the replies, the retained set has 70 rows.

For this fictional task, Chronometrica’s declared unit fits the requirement. The cap and the study count refer to the same type of comment. This does not mean a run will find 100 comments. It means the requested limit has the right meaning. Chronometrica contract

Now change the research question. The researcher wants to understand how people answer each other. Reply text and the link between a reply and its parent become necessary. The choice must change because the required evidence has changed.

Do not use this example to predict either Actor’s results. The 70 and 30 counts only show why a mixed row total cannot stand in for a top-level count.

The same distinction applies when you report results. “We retained 70 top-level comments” is clear. “We analysed 100 comments” can hide the difference between the original export and the rows used in the study.

Use a short method before you collect

You can make the choice with five checks. Keep the answers with your collection notes so another person can understand the decision.

1. Define one accepted row. Write one sentence that states what belongs in the dataset. For example: “One accepted row is one top-level comment from one selected public Reel.” If replies belong in the work, state that instead. Do not choose the row type only because a tool makes it easy to collect.
2. Define the source list. Decide whether you already have the post or Reel URLs. Keep the selected URLs with the collection record. If you still need to discover posts from accounts, treat discovery as a separate input requirement. A comment collection tool must support the way you intend to identify sources.
3. Check the cap’s counting rule. Read the setting description, not only its name. Write down whether it applies per post or across the collection. Also record which row types count toward it. Keep the requested limit separate from the number actually returned.
4. List the fields you need. A field is a named value in a row. You might need comment text, a source reference, and an identifier for duplicate checks. Thread work may also need a parent identifier. Check the current output documentation before you assume any field exists. Do not treat a reply count as a substitute for reply text.
5. Set an acceptance rule. Decide how you will check the result before analysis. State which rows qualify, how you will handle duplicates, and which missing values make a row unusable for the intended question. Keep excluded rows or exclusion counts so you can explain the final dataset.

These checks keep the choice tied to the work. They also prevent a large row total from becoming the main reason to prefer an export.

If a required field is not confirmed, keep its status as unknown. Do not infer support from a product name. Do not infer that a feature is absent because a short comparison does not describe it. Check the current contract for the exact requirement.

Start Chronometrica with an explicit input

For the top-level workflow, the checked minimal input has this shape:

{
  "postUrls": [
    "https://www.instagram.com/reel/DIwcCZgxVZP/"
  ],
  "maxCommentsPerPost": 100
}

Replace the example URL with your intended public post or Reel URL. The example source is not a promise of current availability.

The supplied input passed a static check against the cached public input schema. A schema defines allowed input fields and values. A static check checks that input shape without collecting comments. No collection run was made for this comparison.

The checked schema requires at least one item in `postUrls`. It defines `maxCommentsPerPost` as an integer from 1 to 999999, with a default of 100. The cap is ignored when the option to remove the result limit is enabled. Check that option when your work depends on a fixed cap. Chronometrica input contract

The public Task is a useful starting preset. Its page check confirmed that the page loaded with the intended title. That check did not confirm its current saved input. Apply and inspect your intended values before a run. Chronometrica Task

Save the input you actually use. A link to a preset is useful, but the link alone does not show which values governed a particular collection.

Check the result before you treat it as a sample

After collection, compare the returned rows with the acceptance rule you wrote. Keep this review separate from any later text analysis.

First, check the row unit. Confirm that the records you retain match the intended comment type. For a top-level study, an available reply count can add context, but it does not add reply text to the dataset.

Second, record requested and returned counts separately. You might request a cap of 100 and receive fewer qualifying rows. Report the actual count. A short result alone does not show why rows are missing or whether the collector reached all available material.

Third, check duplicates using confirmed identifiers where available. Repeated text is not enough to prove duplication. Two people can write the same words. Preserve the original export before you make changes so you can review your decisions later.

Fourth, preserve missing values. An unknown reply count is not zero replies. An unavailable field is not evidence that the underlying event did not happen. If a required value is missing, record the gap and decide whether the row can still answer the question.

Fifth, check the scope of the conclusion. A capped collection is not automatically a random sample. Do not assume the selection order or claim that the retained rows represent all viewers. State how you selected sources and what you know about the collected set.

A useful collection record includes the source URLs, collection date, Actor, applied input, requested cap, returned count, retained count, and reasons for exclusions. Use the same row definition throughout that record.

For spreadsheet import and fuller documentation steps, continue with Export Public Instagram Comments to Excel for a Thesis. That guide covers work after the Actor and collection unit have been chosen.