Browser, OS and Device Analytics, Explained

What the browser, OS, device and language panels actually count

In GhostMetrics these four reports live on the Visitors tab. The tab name suggests people, but the query behind each panel groups rows in the events table by one column and counts them. Every row written by a page load is a pageview, so the count is pageviews with that label over the selected period of 24 hours, 7 days, 30 days or 90 days.

That has three practical consequences.

• Heavy readers weigh more. A visitor who reads five pages adds five rows to their browser's slice. If one browser skews toward long reading sessions, it looks bigger than its head count.
• Single-page-app route changes count. The tracker sends a new pageview with the same browser, OS and device labels on every pushState or popstate navigation, so app-style sites inflate the weight of whoever navigates the most.
• The percentages are shares of the donut total. The legend divides each slice by the sum of the rows it was given and prints it to one decimal, with that sum in the donut centre. Rows with an empty label are excluded by the query.

Each panel also returns at most the top 10 labels. For browser, OS and device that cap never bites, because the tracker can only emit five, six and three distinct labels. It matters for language, which can take any value the browser reports.

Two further limits are worth knowing. The four panels are independent queries, so there is no browser-by-device or OS-by-browser cross-tab. And there is no country filter in the dashboard, so you cannot narrow these panels to one market; use the export for that.

One more place shows the same labels: click a bar in the daily chart and the day drill-down lists that day's devices and browsers, counted as pageviews, with raw counts rather than percentages. It is the quickest way to check whether a deploy shifted your mix.

How each label is made

The labels come from the tracker in the visitor's browser, not from the server. At load, gm.js reads navigator.userAgent and innerWidth and sends three derived strings with the pageview. The parsers are short enough to read in full:

function parseBrowser(ua) {
  if (/Edg\//i.test(ua)) return "Edge";
  if (/Chrome\//i.test(ua) && !/Chromium/i.test(ua)) return "Chrome";
  if (/Firefox\//i.test(ua)) return "Firefox";
  if (/Safari\//i.test(ua) && !/Chrome/i.test(ua)) return "Safari";
  return "Other";
}
function parseOS(ua) {
  if (/iPhone|iPad|iPod/i.test(ua)) return "iOS";
  if (/Android/i.test(ua)) return "Android";
  if (/Windows/i.test(ua)) return "Windows";
  if (/Mac OS/i.test(ua)) return "Mac";
  if (/Linux/i.test(ua)) return "Linux";
  return "Other";
}
function parseDevice(w) {
  if (w < 768) return "mobile";
  if (w < 1024) return "tablet";
  return "desktop";
}

The first match wins, which is why the order matters: Edge sends a Chrome token, so it is tested first, and Android user agents contain the word Linux, so Android is tested first. The language is not parsed at all: navigator.language is sent as is and stored verbatim, so en-US and en-GB are separate rows. Viewport and screen sizes are stored too but no dashboard panel charts them; they are in the raw export, which is built from the table's live columns.

Where user-agent parsing misleads you

A user-agent string is a self-description that browsers have padded with each other's names for decades, so a short regex list gets the family right and the product wrong. Reading the parsers above against typical user agents gives a predictable set of blind spots. The parser rules are exact; the browser behavior described is typical at the time of writing, and user-agent formats change, so confirm any single case against the vendor's current docs.

• Chromium forks become Chrome. Opera, Samsung Internet and other Chromium-based browsers typically carry a Chrome token, and the parser only separates out Edge. A "Chrome" slice is really "Chromium family minus desktop Edge". A user agent that includes a Chromium token falls through to Other, because the Chrome rule explicitly excludes it.
• iOS browsers read as Safari. Chrome and Firefox on iOS typically identify with tokens like CriOS/ and FxiOS/ plus Safari, and none of them match the Chrome or Firefox patterns. They land in the Safari rule. For testing purposes that is often right, since iOS browsers have historically all used Apple's engine, though platform rules on alternative engines have been changing in some regions.
• Edge outside desktop. Edge on phones typically uses tokens other than the Edg/ the parser looks for, so it reads as Chrome on Android and Safari on iOS.
• iPads in desktop mode. iPadOS can send a Mac-style user agent by default, which this parser reports as Mac. Combined with a viewport of 1024 pixels or more in landscape, an iPad can appear as desktop on a Mac.
• Other operating systems. Anything that matches none of the six patterns, such as ChromeOS, is typically reported as Other, and the OS panel has no version or device-model detail at all.
• Automation is dropped, not labelled. The ingest filter silently discards user agents containing headless, crawler and HTTP-library markers, so a headless Chrome test run never shows up as Chrome. A script with a real-browser user agent does pass, so an odd spike in one browser and OS pair is worth a look at the Organizations panel.
• Privacy tools are invisible. A visitor sending Global Privacy Control or Do Not Track gets no beacon at all, and script blockers remove more. Privacy-minded browsers can be under-represented in every number on this page.

User-agent reduction and client hints

Browser vendors, led by Chromium, have been trimming the detail in the user-agent string and moving finer detail, such as full versions and device model, behind a separate opt-in mechanism called User-Agent Client Hints. Check the current browser documentation for what each engine sends today, because the rollout has been staged and differs between vendors.

For GhostMetrics the effect is limited, because of what the tracker reads. It never reads navigator.userAgentData, and it keeps only coarse families. It does not depend on versions or device models, which are the details reduction removes. The remaining risk is a browser dropping a token the regexes rely on; those visits would move into Other, so a growing Other slice is the signal to watch. Tools that report versions, models or screen resolutions depend more on this change; check their current docs.

Mobile vs desktop, and how it pairs with Core Web Vitals

Device type is the most useful split in this report, because it is the one that changes what you build. A site that is 54% mobile deserves a different review order from one that is 15% mobile, regardless of which browser leads.

The cut is a viewport threshold. parseDevice compares the window's inner width to 768 and 1024 when the page loads, and recomputes it for each single-page-app navigation. That means:

• A desktop browser in a half-screen window under 768 pixels reports mobile.
• A phone held sideways can be wider than 768 CSS pixels and report tablet.
• A tablet in landscape at 1024 pixels or wider reports desktop.

Treat "mobile" as "narrow layout" and you will read it correctly: it matches the breakpoints your CSS responds to, which is arguably what you want to test anyway. Treat it as "phone hardware" and it will mislead you at the edges.

Performance by Device

The Performance tab carries a Performance by Device table below the Vitals by Page table. It groups rows that carry a vitals beacon by the same device label and shows the average FCP, LCP, CLS and TTFB for each. Four things to keep in mind when reading it:

• Averages, not percentiles. A few very slow loads pull an average up, so read it as a direction, not a pass or fail.
• No rating and no sample size on the rows. The Good, Needs Work and Poor ratings are applied only to the four summary cards at the top; the device table prints raw numbers and has no count column.
• Split by device only. There is no browser or OS split of vitals, so you cannot ask whether Safari is slower than Chrome here.
• Some visits never report. The tracker sends vitals once FCP, LCP and TTFB are all captured, or after a 10-second timer if some are missing. A visitor who leaves before either can happen contributes nothing, and a metric a browser cannot observe is skipped in that metric's average. The beacon is sent once, with the values seen at that moment, so a later, larger paint or a late layout shift is not counted.

INP is not captured by GhostMetrics, so responsiveness on slow phones needs another source. Pair the two views: if mobile is your largest device slice and its LCP is well above desktop, fix mobile first. If mobile is a small slice and fast, spend the time elsewhere. Our guide to real-user Core Web Vitals monitoring covers the thresholds and what to do about each metric.

Turning the numbers into a browser-support decision

A support decision needs two inputs: how much traffic an environment carries, and how costly it is to support. The report gives you the first. This worked example uses made-up numbers; it is illustrative, not a benchmark. Suppose 90 days of data show 10,000 pageviews:

The donut shows only the percentage in its legend, so work backwards from the total in the centre: a 4.5% Firefox slice of a 10,000 total is 450 pageviews. Here is how to reason from that table.

• Pick the tiers first. Set cutoffs in advance, for example "full testing above 10%, smoke test between 2% and 10%, best effort below 2%". The numbers are yours to choose; the discipline is choosing them before you see the report.
• A slice is a bundle. Safari at 23.0% includes every iOS browser, so a bug that only appears in Apple's engine affects far more traffic than a Safari-only reading suggests. Cross the Browser donut with the OS donut: a large iOS slice and a large Safari slice are largely the same visitors.
• Weigh the cost of failure, not just share. A 4.5% browser that breaks checkout is worth more care than a 9.0% browser where a tooltip is misaligned. GhostMetrics has no conversion-by-browser view: the Custom Events panel lists event name, count and last triggered, and events carry no browser column, so rank the pages that matter from the Pages tab and test those on every tier.
• Watch Other. If Other grows, either a real browser appeared or a user-agent token changed; inspect the raw export before deciding.
• Use language for content, not support. A large non-English language slice is a case for translated copy, currency or date formats. Compare it against the Geo tab; the language is a browser setting, not a location. Our weekly dashboard routine shows where this fits.

A second reason to be careful with small slices: with a 30-day window and low traffic, a one- or two-point swing can be noise. Prefer the 90-day view for policy and the 24-hour or 7-day view for spotting a regression after a deploy.

How to build a browser and device support policy in GhostMetrics

1. Set the 90d period and open the Visitors tab. The period picker offers 24h, 7d, 30d and 90d; 90 days smooths out launches and one-off referral spikes.
2. Record the Browser, OS and Device shares. Read the percentages from each legend and the pageview total from the donut centre, and write down the implied counts. Note the size of Other.
3. Read the Languages bars. Note any non-default language above your threshold and whether regional variants of one language should be combined, since each variant is its own row.
4. Open the Performance tab. Compare LCP, FCP and TTFB for mobile, tablet and desktop in Performance by Device, and compare the cards against the Good, Needs Work and Poor thresholds.
5. List your top pages. From the Pages tab (All Pages and Entry Pages), pick the five pages that carry the most entries or matter most to your goals. These are your test pages, since the Visitors tab cannot tell you which pages each browser sees. See our entry and exit pages guide.
6. Export for the cross-tabs the dashboard lacks. Use Export data for the raw CSV, then pivot browser by device type by viewport width in a spreadsheet. Export is on every plan, free included.
7. Write the tiers down. One page: which browsers and device widths get full testing, which get a smoke test, which get best effort, and the cutoffs.
8. Re-check on a schedule. Revisit the 90-day view each quarter and the 7-day view after releases. A day drill-down (click a bar in the daily chart) shows whether one day's device or browser mix jumped.

Options for browser, OS and device reporting

Most analytics tools offer these breakdowns; they differ in granularity, in what they count, and in how much of the data survives privacy settings. The comparison below is qualitative; check each tool's current documentation for the exact dimensions and limits.

GA4 is the stronger choice if you need to see conversion rate by browser or device, or to build audiences on those segments. A cookieless tool is the stronger choice if you want the breakdown without a consent banner; the trade-off is coarser labels. For a broader view, see cookieless analytics compared and how cookieless tools count visitors.

FAQ

Keep reading

Disclosure: GhostMetrics is built by Null Agency and we use it on this site, so we are not a neutral party about our own product. User-agent formats, client hints and engine rules are set by browser vendors and change over time; check their current documentation. Competitor tools' dimensions are theirs to document; check their current docs. The worked example numbers are illustrative, not benchmarks.