Why Main Comments and Replies Need Different Fields

A flat count hides the conversation

A page can contain 100 visible records without containing 100 separate opinions. Some records start a thread. Others clarify, disagree with, or answer the original comment. Putting everything into one flat text column removes the relationship that gives a reply its meaning.

That difference matters when a product team groups feature requests, counts recurring issues, reads sentiment, or returns to the original discussion.

What we saw in platform tests

In one Google Maps test, the page contained 77 main comments and 75 replies. A task capped at 100 records collected 77 main comments and 23 replies. Replies counted toward the same limit, while each row still showed whether it was a main comment or a reply.

In a separate Bilibili test, we collected 20 main comments and 23 replies with parent identifiers. The useful part was not simply the total of 43 rows. It was knowing which rows started a discussion and which belonged beneath them.

A useful export keeps the thread structure

A comment export should make the following details easy to see:

• whether each record is a main comment or a reply;
• the parent relationship when the page provides it;
• whether replies count toward the requested limit;
• whether the task stopped with a partial result;
• the source URL for returning to the page.

What one test can tell you

These examples show why reply structure matters. They do not set a fixed limit for every page. Page layout, login state, region, and platform controls can change what loads. The export should contain the records the page returned and clearly mark a partial task when loading stops.