Overview
The YouTube Metrics and Comments Collector is a YouTube comment scraper: a standalone desktop bot that opens a public watch page, reads the video’s own embedded metadata, scrolls the comment section to a target you set, and saves two datasets - one video_metrics row and one comments row per top-level thread - as CSV files on your machine.
What does the YouTube Metrics and Comments Collector do?
You give it three inputs before a run: video_url (one public watch page, or a list of them, one URL per line), comment_count (the target number of top-level comments, default 50), and sort_order (top for the popular ordering, recent for newest first). The bot then navigates to the video, pulls the title, channel, view count, like count, publish date and duration straight from the player JSON embedded in the page - the same data the page itself renders from, which is far more stable than scraping visible text - and scrolls the comments section until your target is met or the feed ends.
Everything lands locally. The configuration does not pin a custom export filename, so each dataset is written as a CSV named for its dataset key, video_metrics and comments, in the launcher’s output folder. Because the run happens on your desktop, your research interests - which channels you study, which videos you batch, what you do with the sentiment in the comments - never pass through anyone else’s servers.
Two honesty notes up front. First, this build collects top-level threads only; it never expands reply chains. Second, it ships without proxy rotation or CAPTCHA solving, so if a verification wall appears the run logs it and stops rather than fighting through - the failure paths are described further down.
Who uses a YouTube comment scraper or comment export tool?
The content strategist asks “what did the audience actually say about this launch video?” and needs a dated CSV of newest-first comments to code themes against, not a screenshot gallery. The academic researcher asks “can I build a reproducible corpus of comments on these twenty videos for a published study?” and needs batch list mode, exact field provenance and a dataset they collected themselves and can cite. The creator asks “how do my like counts and comment volumes compare across my last ten uploads?” and needs the metrics row per video, re-collected on a schedule they control. All three want an artifact they produced and can defend - rows with video_id, page_url and collection context attached - rather than a dashboard inside someone else’s web app.
How does a YouTube metrics collector run work, step by step?
Every command in the run is linked to its reference page. First, three set_cookie calls fire before any navigation: two consent cookies that preempt the EU cookie interstitial, and one pinning the interface to English. A set_viewport_size call fixes the window at 480x940, and goto loads the watch page - with image, media and font resources blocked for speed. A try_catch block dismisses any consent dialog that still appears, then wait_for_selector confirms the player shell has rendered.
Phase one is metrics: an execute_script step reads the embedded player response and initial-data objects, a bounded search digs out the like count, and eight set_variable calls park the values so the video_metrics dataset can capture them via variable selectors; extract_data writes the row. If the embedded JSON is ever unavailable, a METRICS_DEGRADED marker is logged and the run continues to comments.
Phase two prepares the scroll: a script strips the related-videos sidebar and footer so the document bottom is the end of the comments section, one scroll teleports there to hydrate every lazy sentinel, then a while loop climbs back in gradual 600-pixel steps - gated by is_visible checks for either the first comment thread or the comments-disabled message, capped at 40 tries - because the comment section only mounts when its sentinel is sampled by an intersection observer, never on a jump.
Phase three sorts: an if branch opens the sort menu and clicks Top comments or Newest first explicitly on every run, with scroll_into_view first and a text-based fallback behind the position-based click. Phase four collects: infinite_scroll drives the page with a two-second delay per step, its do block re-stripping the sidebar as insurance, re-extracting the deduplicated comments dataset each cycle, and issuing a break the moment the running total reaches comment_count. A final comment line logs the totals for the run.
Getting YouTube comments to CSV: what lands in each column
The metrics table mirrors the published sample output exactly:
| video_id | title | channel | views | likes | published | duration_seconds |
|---|---|---|---|---|---|---|
| abcdefghijk | Restoring a 1972 field recorder - full teardown | Example Field Notes | 184322 | 9214 | 2026-08-14 | 942 |
video_id and channel_id are the platform’s own stable identifiers - join on them across runs and batches rather than on titles, which creators edit. title, channel, views, likes, published and duration_seconds come from the embedded player JSON; views and likes are captured as displayed strings, so strip any formatting in your spreadsheet rather than expecting pre-parsed numbers. description is the open-graph summary, kept for context. page_url records the exact watch page the row came from, which is what makes a multi-video batch auditable.
The comments dataset carries its own columns:
| author | author_url | text | likes | published | replies |
|---|---|---|---|---|---|
| Example Viewer | https://www.youtube.com/@exampleviewer | Great teardown - the belt replacement tip saved mine. | 42 | 3 weeks ago | 5 replies |
author and text are trimmed verbatim. author_url is normalised to an absolute channel link by a transformation script. likes is the one normalised field: a script converts display shorthand (1.2K, 3M) into plain integers, defaulting to 0 when no count is shown. published is the platform’s relative label as displayed - “3 weeks ago” - kept raw so the run is auditable against the page. replies is the raw reply-toggle label, not reply content. Deduplication runs on author plus text plus published, which is what lets overlapping scroll batches append safely.
Can it serve as a video analytics scraper for channel research?
Yes, within its shape. A video analytics scraper ultimately answers “how did engagement on these videos move, and what are people saying?” - and a batch run over a channel’s recent uploads, re-run monthly, gives you exactly that: views, likes and comment volume per video_id over time, plus the newest-first comment corpus to read against the numbers. What it will not do is chart anything, alert you, or re-run itself; schedule the launcher with your OS scheduler and diff the CSVs. If you need live dashboards and automated reporting, that is a product category, not this bot - the trade is set out below.
How does it compare to manual copying and hosted collection?
Hand-copying comments works for twenty threads and collapses at two hundred, produces no like counts or timestamps worth trusting, and cannot be repeated identically next month. This bot produces the same deduplicated CSV on your own machine for nothing per run, and the workflow is a file you keep. Against hosted export websites and metered collection platforms - the ones that charge per comment, per record or per month and keep your exports in their cloud - the difference is structural: here the data lands on your disk, the retention and compliance decisions are explicitly yours, and a bigger comment target costs only your own time and bandwidth. Against the platform’s official developer API, the trade is different again: the API is the sanctioned route but runs on a shared daily unit budget that makes large comment pulls a quota-accounting exercise, and it requires a developer project at all. This bot reads the public page like a viewer. The honest costs of local collection: no dashboards, no scheduling, no history, and selector-level maintenance when the page changes.
How do you set it up on Windows, macOS and Linux?
Download the launcher for your platform from this page - a single raw file, no archive and no extraction step anywhere. On Windows, run the downloaded .exe directly; SmartScreen may ask for confirmation on first launch, and “More info” then “Run anyway” proceeds once you have verified the published checksum. On macOS, two launchers are published - check Apple menu, About This Mac for Apple Silicon or Intel and pick the matching one, since running the wrong build is the most common first-launch mistake. Make it executable with chmod +x, clear the Gatekeeper quarantine with xattr -d com.apple.quarantine /path/to/youtube-metrics-comments-collector, then launch. On Linux, the launcher is a single .sh file: chmod +x ./youtube-metrics-comments-collector then ./youtube-metrics-comments-collector - the executable bit can be lost in transfer, so keep the chmod step. Do not rename the file: the filename carries the configuration id. First run asks for the three inputs (video URL, comment target, sort order); for unattended repeats, schedule the launcher with Task Scheduler on Windows, launchd on macOS or cron on Linux.
What do I check when a run returns zero rows?
In order. Metrics empty: is the URL a public watch page that loads in an ordinary logged-out browser, or an embed, age-restricted or region-locked video? A METRICS_DEGRADED marker in the log means the embedded JSON route failed - the comments half may still be fine. Comments empty with a COMMENTS_UNAVAILABLE marker: the section is disabled, restricted, or never rendered in time - confirm by opening the page yourself. Fewer comments than the target but a non-zero file: the video simply has fewer top-level threads than you asked for, or the scroll cap derived from comment_count was reached - raise the target and re-run. Empty likes columns are normal: many threads display no like count, and the transformation defaults them to 0. A run that stops at a verification wall is honest, not broken - this build deliberately ships no solver, so the answer is to slow down, not to fight through. The contract throughout: failure is loud and logged, never fabricated data.
What are the limits of the bot?
It collects what a logged-out viewer can see on one watch page at a time: metrics from the embedded player data and top-level comment threads. It does not expand replies, collect channel pages, playlists, search results or Shorts-specific surfaces, and it does not download video or audio. It has no proxy rotation or CAPTCHA solving in this build, no scheduling of its own, and no alerting - it is a snapshotter, not a monitor. Batch mode processes URLs sequentially with one worker. The comment target is a floor guarantee, not an exact cut: expect overshoot of up to one loading batch. And the metrics route depends on the page’s embedded JSON staying present; when it does not, the bot says so in the log rather than guessing.
What is responsible comment collection?
Comments are user-posted content tied to named or pseudonymous accounts - unambiguously personal data under GDPR, UK GDPR and similar regimes. Establish your lawful basis before repurposing anything, honour deletion and opt-out requests immediately, and never use author names or channel links for unsolicited outreach, spam or profiling of individuals. Review the platform’s terms of service with open eyes: automated collection may conflict with them, and the decision to run is yours to own. Keep request rates at what a patient human could sustain - the two-second scroll delay and single-worker design are there for exactly that reason - and keep your corpus scoped to what your research or reporting actually needs. The acceptable-use policy applies in full before your first run.
