
The main question is simple: must you read what people wrote in the replies? A count can tell you that a question received responses. It cannot tell you whether those responses contain a correction, another question, or a useful answer.
That difference matters when you compile comments from a tutorial. The public question that prompted this comparison asks how to collect a tutorial’s comments. It does not establish that every review needs replies. Start with your own review question before you choose a tool. Public discussion
This guide compares the documented public contracts checked on 20 October 2026. It shows how to choose a result type, set collection limits, and count the returned rows. It does not report a collection test.
Choose the evidence your review needs
A top-level comment starts a thread. A reply responds within that thread. The parent comment is the comment to which a reply belongs.
For a tutorial review, these two row types can answer different questions. Top-level text may show the questions viewers ask first. Reply text may show how other viewers answer those questions. A parent link keeps those parts together.
Write your review question as one sentence. For example: “I need to read the answers viewers gave beneath questions about this lesson.” That sentence requires reply text. “I need to rank the opening questions by the number of responses” requires a count, but may not require the responses themselves.
Do not collect extra text simply because a tool can return it. More rows create more reading work. Each reply also needs enough thread context to make sense. A short response such as “That worked” can be hard to interpret without its parent.
For a review that needs this context, Chronometrica documents replies as separate rows. Its relevant fields include `parentCommentId`, `isReply`, `replyDepth`, and `replyCount`. These fields support the distinction between a reply row and the comment it belongs to. Chronometrica contract
An Actor is a hosted data collection program. The choice here concerns what its output must contain. Choose the required evidence first, then choose the Actor that documents that evidence.
Compare the documented result types
The following table focuses on the decision that changes the recommendation.
| Decision point | Chronometrica | CheapAPI |
|---|---|---|
| Comment rows | Top-level comments and separate reply rows | Top-level comments only |
| Reply information | Reply text and parent-link fields | Reply counts; no reply text |
| Top-level limit per video | 1–1,000 | 1–700 |
| Reply limit | 1–100 per parent when replies are enabled | No reply-text rows |
| Other relevant controls | Separate top-level and reply caps | Minimum likes, minimum replies, keywords, dates, and only-new mode |
Sources: Chronometrica contract, Chronometrica input schema, CheapAPI contract, CheapAPI input schema.
A schema is the list of accepted input fields and their rules. Check it when you prepare an input, because product controls can change.
The different limits do not establish a price or speed advantage. They describe how much each input permits the Actor to collect. Available public comments and the selected controls still affect the result.
A narrower row type can be the correct choice. If a review uses only opening questions, adding reply text may increase the reading work without improving the decision. If a review must assess answers within threads, a reply count leaves out the required language.
Keep that distinction separate from other product questions. This comparison does not establish differences in collection speed, cost, or completeness.
Set separate limits before you collect
Chronometrica uses `maxCommentsPerVideo` for the top-level limit. It accepts values from 1 to 1,000. When `includeReplies` is true, `maxRepliesPerComment` accepts values from 1 to 100. The top-level limit and reply limit are separate. Chronometrica input schema
This distinction changes how you plan an export. A top-level limit does not become a total row limit when replies are enabled. Each selected parent can add reply rows, up to the configured reply limit.
For one video, calculate the permitted maximum as:
`top-level cap + (top-level cap × reply cap)`
Use this calculation to estimate the largest result allowed by those two settings. It is an upper bound, which means a maximum under the stated conditions. It is not a forecast of the number of rows you will receive.
A useful limit should reflect your review capacity. Decide how many opening questions you can inspect, then how many replies beneath each question you need to read. Record both numbers before collection. This makes the later report easier to explain.
If you expand the work, keep the settings with each collection. Otherwise, a larger result could appear to show more discussion when it reflects a higher collection limit. The settings are part of the evidence needed to interpret the row count.
Start with one relevant public video
The following input uses documented current fields. It enables replies and sets small, separate limits:
{
"startUrls": [
"https://www.youtube.com/watch?v=dQw4w9WgXcQ"
],
"maxCommentsPerVideo": 2,
"includeReplies": true,
"maxRepliesPerComment": 2
}The URL illustrates the input format. Replace it with a relevant public video. Its presence in this example does not establish that comments are currently available. Chronometrica input schema
Chronometrica also provides a public comments-and-replies Task. A Task is a saved input preset. Use it as an input starting point, then check its settings against your review question. Comments and replies export Task
The first collection has a narrow purpose: confirm that the returned fields support your intended review. Inspect whether you can identify reply rows and connect them to their parents. Read the linked text together to see whether the connection gives you enough context.
A valid input alone does not prove that a result contains the evidence you need. Inspect the output before you add more videos. A small first collection makes this check easier because you can follow the records by hand.
Work through a fictional five-row result
This example is fictional. It is not an Actor run, a benchmark, or a customer result.
The review selects two top-level comments. The first has two collected replies. The second has one collected reply. The export therefore contains:
- Two top-level rows.
- Three reply rows.
- Five rows in total.
For reading, label the parents A and B. Place the first two replies beneath A and the remaining reply beneath B. These labels only explain the example; they are not proposed output fields.
Replies make up `3 / 5 × 100 = 60%` of the rows in this fictional result. That percentage describes collected rows only. It does not describe unique authors, all comments on the video, or all viewers. One person could write more than one row.
With a top-level cap of two and a reply cap of two per parent, the arithmetic upper bound is `2 + (2 × 2) = 6` rows. The fictional result contains five. The limits permit six rows; they do not promise six.
Now suppose one of those fictional replies corrects an answer in the tutorial. Reading that reply could change the review. A parent row that contains only a reply count cannot show the correction’s words. That is the practical reason to require reply text.
If the review only needs to identify opening questions that received responses, the count may be sufficient. The same fictional thread can support different collection choices because the research questions differ.
The example also shows why collection totals need clear labels. “Five collected rows, including three replies” describes this result. “Five viewers” or “all five comments” would claim facts that the example does not establish.
Use a small collection and review method
Use this method to turn the product choice into a result you can check.
- Define the required reading. Write whether you must read replies or only assess top-level questions. Name the decision the text will support. If reply wording could change that decision, include it in the requirement.
- Declare the limits. Set the top-level cap and, when needed, the reply cap. Calculate the permitted maximum before collection. Keep the limits beside the video URL in your review notes so that another reader can interpret the result.
- Keep record links. Retain comment IDs and parent links in the export. An ID identifies a record. A parent link connects a reply to the comment it belongs to. Removing these fields can make later grouping difficult even when the text remains readable.
- Separate the row types. Read top-level comments and replies as different types of records. Chronometrica documents `isReply` and `parentCommentId` among its relevant fields. Check those fields in the returned result before you build counts or groups. Chronometrica contract
- Group replies for reading. Place each reply beneath its parent using the retained link. Keep an unresolved link visible. If the required parent is missing from the export, do not guess which comment supplies the context. Mark the case for review.
- Count collected rows once. Report the number of top-level rows, the number of reply rows, and their sum. Keep `replyCount` separate from this calculation. It is a count field, not an additional set of collected text rows.
- Check whether the evidence answers the question. Read the small result before expanding collection. Confirm that the needed text and links are present. If the review requires only top-level text, reassess whether reply collection adds useful evidence.
These steps give you a result that another person can inspect. They also keep collection choices separate from conclusions about the discussion. A missing parent is a context problem to report. A small row total is a collection result to explain. Neither supports an invented answer about the video.
Keep reply counts separate from collected replies
A common counting error is to add a parent’s `replyCount` to the reply rows already present in the export. That can count the same discussion twice.
Keep two separate measures. The first is the number of reply rows you actually collected. The second is the reply count stored on a comment record. Label each measure clearly. Do not assume that the stored count equals the number of reply rows in your export.
A collection limit can permit fewer reply rows than a thread contains. The result must therefore preserve the difference between text you can inspect and a count you can report. Only the collected text can support a statement about what a particular reply says.
Preserve unknown values. If a field is missing, do not replace it with zero. Zero makes a specific claim about quantity. A missing value says that the quantity is not known from that field.
Apply the same care to parent links. Keep a reply with an unresolved parent in a visible review group. Its text may still be useful, but the export has not supplied the full connection needed for confident thread reading.
Sources & further reading
By Chronometrica · Updated
Back to top ↑