Sample YouTube comments by Top or Newest order

Write the question first

Step 1. Write the analysis question before you choose an order.

Use Top when the question is about source-ordered featured comments. Use Newest when the question is about comments in the recent source order. If both questions matter, use two strata. A stratum is one declared part of a sample. Here, the stratum is the retrieval order.

The order controls which comments enter the sample. Pick the order that matches the question. Do not pick an order only because it supports a conclusion you already want.

Step 2. Declare the known videos, the observation time, the cap for each mode, and the top-level scope.

A cap is the top-level limit, `maxCommentsPerVideo`. Write the clock time for each list. Source order can change later. A later list is not the same sample.

Keep the caps equal when you compare Top with Newest. Unequal caps make the theme rates hard to compare.

Leave replies off. A reply is a comment under a top-level comment. Replies change the unit you count. Reply rows sit outside the top-level cap. This method did not test replies. Write that limit in your notes.

Set the current input

The YouTube Comments Actor public build used here is 1.1.6. It accepts these bounds.

• `startUrls` takes 1 to 100 known public video URLs or video IDs.
• `maxCommentsPerVideo` takes a whole number from 1 to 1,000.
• `commentSortMode` takes `top`, `newest`, or `both`.
• `includeReplies` can be on or off.
• `maxRepliesPerComment` takes a whole number from 1 to 100 when replies are on.

Use a known public video. Do not use a private video. This Actor does not search for videos for you.

On 13 October 2026, the YouTube Audience Comment Research Task saved this start input:

{
  "startUrls": ["https://www.youtube.com/watch?v=dQw4w9WgXcQ"],
  "maxCommentsPerVideo": 250,
  "commentSortMode": "both",
  "includeReplies": true,
  "maxRepliesPerComment": 10
}

That input is a known song video, a cap of 250, `both`, replies on, and up to 10 replies per comment. Replace the song video with one known public video you choose.

For the first pilot, use one known public video. Set `maxCommentsPerVideo` to 2. Set `commentSortMode` to `both`. Set `includeReplies` to false.

In `both` mode, that cap is one shared top-level budget. A cap of 2 is split across Top and Newest. It does not mean 2 Top rows plus 2 Newest rows. The documented `both` behavior also keeps one row per comment ID inside that same run.

A later explicit comparison is different. Run one Top list and one Newest list. Give each run the same declared cap. Keep the observation times comparable. Each of those caps belongs to one run. They are not the shared `both` split.

Read rows apart from the run summary

Each saved dataset row is one public comment or reply. With replies off, each row should be one top-level comment.

`publishedAt` can be null. Null means the value is missing. It does not mean zero. `publishedTimeText` is not an exact time. `scrapedAt` is collection time. Never copy `scrapedAt` into the publication time.

`parentCommentId`, `isReply`, and `replyDepth` are also contract fields. This top-level method does not use them.

The OUTPUT run summary is not a comment row. Read comment text from rows. Read run counts and stop reasons from OUTPUT.

A checked control used `both` on `educationalvideo_uQrJ0TkZlc`. It saved 2 unique top-level rows with nonempty text. One row had `sortMode` `top`. The other had `sortMode` `newest`. Both rows had `status` `ok`. `publishedAt` was null on both rows. OUTPUT reported `commentsWritten` 2 and `repliesWritten` 0. The stop reason was `requested_comment_limit_reached`.

Those two rows were two different comment IDs. The run shows that `both` can return rows and keep `sortMode` on that source. It does not show a random sample. It does not show every comment. It does not show exact age. It does not show the same sort behavior on every video. It does not show overlap between separate Top and Newest runs. It did not test replies. `repliesWritten` 0 is not a reply test. It did not test full coverage.

No comment words from that control are used in this article. A reply total or a like count does not prove you have every comment. Failed or unavailable inputs appear in OUTPUT. Do not invent comment rows for them.

Test the pilot, then pick the export

Step 3. Test one known video with the small `both` pilot.

Check that `videoId` and `videoUrl` match that video. Check that `text` is nonempty. Check that `commentId` and `sortMode` are present. Check the OUTPUT stop reason. When the shared cap is met, the stop reason to expect is `requested_comment_limit_reached`.

If `publishedAt` is null, leave the age unknown. Do not write 0. Do not write the collection time. A Newest `sortMode` records retrieval from the Newest order. Prove age only where the source gives an actual date.

Step 4. Choose one wider export or two separate lists.

Use `both` when you want one wider bounded export and you will read the stop reason and the counts. That export is still a bounded source list.

Use two runs for an explicit Top versus Newest comparison. A ledger is the raw saved list for one mode, kept with its input and its observation time. Run one bounded Top ledger and one bounded Newest ledger. Use the same declared cap on each run. Keep the observation times comparable.

Those paired runs are your later work. The checked control was one `both` run. Do not report that control as a paired overlap result.

Step 5. Deduplicate each ledger, then build the union from separate ledgers.

Deduplicate means you count one checked identity once. The key is `videoId` plus `commentId`. The same words are not the key. Two comments can share text and still be different IDs.

A union is the set of distinct checked IDs in either ledger. An intersection is the set of checked IDs that appear in both ledgers. Keep membership as `{top}`, `{newest}`, or `{top, newest}`.

You can assign `{top, newest}` only when both separate ledgers contain that ID. Inside one `both` run, dedupe keeps one row and one `sortMode`. That single label cannot reveal a second membership. Do not guess it. Keep the raw ledgers so the membership stays checkable.

If an ID is missing, it stays unresolved. Do not drop a missing ID into a zero count. Do not rebuild the lost membership from memory.

Code one rule, then compare sets

Step 6. Use the same code rule in each stratum.

A code rule is the written test for one theme. Write it before you mark rows. Apply that same test to Top and to Newest. Keep the raw text and the source context with the mark.

Before any fraction, reconcile four checks.

• Intended inputs: the videos and modes you declared.
• Unknown IDs: identities you cannot resolve. They stay unresolved.
• Valid text: nonempty text you can code.
• Status gaps: rows that are not `status` `ok`, plus any mode that failed.

The denominator is the count of comments allowed into the fraction. Use only valid text with a known ID. Report unknowns in a separate count. Unknown is not zero.

A theme count counts comments in the sample. It does not count people. It does not speak for silent viewers. It is not a demographic result.

Step 7. Compute intersection and union from the separate IDs.

Report how many retrieval appearances you saw, then how many unique IDs remain after you deduplicate. Overlap here is overlap of these bounded lists at these times. It is not the share of all comments on the video.

If a mode fails, the missing list is not a successful empty list. Do not code that mode as zero comments. The comparison stays unknown. Source availability can change between runs. Read `failedInputDetails` and `stopReasonCounts` before you code.

Step 8. Write a conclusion that matches the order and the question.

A theme that is common in Top can reflect source-ordered featured comments. That result is source ranking. It is not a view count, and it is not a certified score. A theme that is common in Newest can reflect recent activity in the Newest source order. It does not prove exact age when `publishedAt` is null.

One observation cannot prove that a theme grew. It cannot prove that a theme shrank. Save the sampling notes, the input, and the stop reason. A later reader should be able to repeat the sampling choice.

Some readers need a bounded way to study human comments when collection has limits. This public post describes that need. A numeric limit claimed there is not verified in this article. Do not treat that claim as current official API behavior. This Actor uses a different method. It does not use your YouTube API key. If you also use the official API, check that API's current primary docs yourself. Choosing Top or Newest answers the sampling need. It does not promise every comment.

Walk a fictional ledger

The ledger in this section is fiction. It teaches the counts. It is not an Actor result. It is not the two-row control. No real comment text is claimed here.

The fictional Top ledger has comment IDs A, B, and C. The fictional Newest ledger has B, D, and E. All five IDs have a source identity and text that can be coded.

The retrieval appearances are A, B, C, B, D, and E. That is 6 appearances. The distinct IDs are A, B, C, D, and E. That is 5 unique comments. B appears once in each ledger, so B is the repeated appearance. Count B once in the union, and keep both memberships. A repeated appearance is not spam. This method does not make a spam judgment.

The union is `{A, B, C, D, E}`. The intersection is `{B}`. Top only is `{A, C}`. Newest only is `{D, E}`.

A `both` export that saved B only with `sortMode` `top` cannot prove Newest membership. Only the separate ledgers can show that B was in both.

Reconcile the fiction before any theme fraction.

The code rule is fixed first. Mark the theme "setup question" only when the comment asks how to start the task. Use that same rule on every ID. In this fiction, the rule matches A, B, and D only. It does not match C or E.

The average of the two stratum rates is `(66.7 + 66.7) / 2`. That equals 66.7 percent. It does not equal the union rate of 60 percent. The union counts overlapping B once. Averaging the stratum percents does not build the unique union fraction.

Both orders show 66.7 percent in this fiction. That agreement is only about these five comments. It does not prove that 60 percent of all viewers have the setup question.

Show the IDs, memberships, code rule, and denominators before you state a conclusion. The conclusion allowed here is narrow. In this fiction, the theme share matches across the two bounded orders, and the unique union share is 3 of 5.

Two limits stay in force. If `publishedAt` is null, B's exact date stays unknown. Newest membership does not supply that date, and `scrapedAt` does not supply it either. If Newest failed on another video, you would not treat that video as a Top-only population. The comparison would be unknown. A failed mode is not a successful empty mode.