Querying Vercel Web Analytics From the CLI: Why It Matters
Vercel can now return Web Analytics data from the terminal via vercel metrics. Here is why a scriptable, agent-readable analytics feed changes how solo builders work.

You can now query Vercel Web Analytics from the CLI, and that small change is bigger than it looks. Vercel shipped a vercel metrics command that pulls page views, visitors, and custom events straight into your terminal, no dashboard tab required. I run a few projects on Vercel, so I went and read the announcement properly instead of skimming it.
The news comes from Vercel's own changelog: Query Web Analytics from the Vercel CLI, published 26 June 2026. What follows is my read on why a terminal-readable analytics feed is more useful than another chart.
π What actually changed
Until now, your Vercel traffic data lived inside a web dashboard. You logged in, picked a project, eyeballed some graphs. The new vercel metrics command lets you ask the same questions from the command line and get structured data back.
Per the changelog, you can pull three core things:
| Metric type | Example question it answers |
|---|---|
| Page views | Which pages got the most hits this week? |
| Visitors | How many unique people landed on the site? |
| Custom events | How many signups or downloads fired? |
The changelog also says there is a full list of supported metrics, dimensions, filters, and query options in Vercel's documentation. I'm not going to invent the exact flags here, because I haven't run every one of them. Read the docs for the precise syntax.
Key takeaway: Analytics moved from "a page you look at" to "a thing you can query." Once data is queryable from a script, it stops being a report and starts being an input.
π οΈ Why scriptable beats clickable
A dashboard is great for a glance. It's terrible for anything you want to do twice. The moment your answer needs to be repeated, compared, or fed into something else, clicking through a UI becomes the bottleneck.
Here's what a CLI feed unlocks that a dashboard never could:
- Repeatable checks. Wrap
vercel metricsin a shell script and run the same traffic check every Monday morning. - Diffable history. Save weekly output to a file in git and you have a free, version-controlled traffic log.
- No context switch. You're already in the terminal deploying. Ask the traffic question without opening a browser.
- Pipe it anywhere. Structured output goes into
jq, a spreadsheet, or a notification.
For a solo builder or a two-person team in Sri Lanka, this matters more than it does for a big company with a dedicated analytics seat. You are the analyst. Anything that turns a five-minute manual ritual into a one-line command is time you get back.
π€ The real story is the coding agent angle
The part of the changelog that made me stop was this: by giving a coding agent access to the CLI, the agent can answer questions on your behalf. The examples Vercel lists:
- Which pages gained the most traffic this week?
- Which UTM campaigns drove the most signups this month?
- Compare conversion events between mobile and desktop users.
Think about what that means. You stop writing the query and start asking the question in plain language. The agent picks the right metric, dimension, and filter, runs the command, and reads the result back. Your analytics become conversational because the data is finally in a shape a model can consume.
The shift isn't "analytics in the terminal." It's analytics that an AI assistant can read without you building a custom integration first.
I'd treat the campaign question as the most practical one. Most small SL projects I see run ads or share links with no tracking at all, so "which campaign worked" is genuinely unanswerable for them. That's a self-inflicted wound, and it's fixable before you ever touch the CLI.
π Get your UTM tags right first
The campaign example only works if your links carry clean UTM parameters in the first place. vercel metrics can group signups by campaign only if every link you shared was tagged consistently. Sloppy tags (utm_source=FB on one link, facebook on the next) split the same campaign into two rows and ruin the comparison.
A quick discipline that pays off:
| UTM field | Keep it as | Avoid |
|---|---|---|
utm_source |
facebook, whatsapp, newsletter |
FB, Whatsapp, news |
utm_medium |
social, email, cpc |
random capitalisation |
utm_campaign |
launch-june, sale-2026 |
spaces, emoji, dates only |
Lowercase everything, no spaces, pick one spelling and reuse it. If you want a quick way to build consistent tagged links, I keep a free UTM builder on the site that enforces this structure so your future CLI queries actually line up.
Bottom line: garbage tags in, garbage campaign report out. The CLI can't clean data you never tracked cleanly.
π‘ What this means for you
If you ship on Vercel, this is a low-effort win. You don't have to rebuild anything; the data you're already collecting is now reachable from the terminal and, by extension, from any agent you trust with shell access.
Here's how I'd approach it:
- Read the docs once. Learn the metrics, dimensions, and filters before you script anything. Don't guess the flags.
- Start with one question. Pick the single traffic question you check most often and turn it into a one-liner.
- Tag your links properly today, even if you never touch the CLI this week. Clean UTMs make every future query worth running.
- Be careful with agent access. Giving an AI assistant CLI access to your account is powerful and also a trust decision. Scope it sensibly.
The broader trend is clear to me: tools that expose their data as queryable, structured output are the ones that survive the agent era. A pretty dashboard is a dead end for automation. A command that returns clean data is a building block. Vercel just turned its analytics into the second kind, and that's the right direction.
Original source
Query Web Analytics from the Vercel CLI