Versions

Versions answers three questions about your releases: which versions people run, how quickly a new one replaces the old ones, and whether a release changed what people do. It is in the menu after Devices for every app and browser extension, and for a website once it has sent a version.

A version is whatever your product sends as appVersion, kept exactly as sent: 2.4.0 and v2.4.0 are two versions. Each user-day keeps the version of that day's latest event, so someone who updates at lunch counts on the new version from then on.

Reading adoption

The chart shows, for each day, how that day's users split between versions, as shares adding up to 100%. Each user counts once a day, on the version they ran last that day; on longer ranges, once a week or a month. The five versions with the most users in the range get a line each, newest first, and everything else is one dashed Other versions line.

A healthy release climbs from a few percent on its first day to most of your users within a week or two, while the version before it falls away. A line that stalls means people are not updating: an app store review still pending, an auto-update turned off, or a build that only some devices can install.

The table below counts users per version over the whole range, with the change on the previous period. Someone who updated during the range counts under each version they ran, so the rows can add up to more than your users. Pick a goal above the table to see how many people on each version reached it.

The newest version

The version first seen latest is marked Newest, in the table, the chart and the overview's Versions panel. Version strings are never compared as numbers, because every product numbers them its own way (2.10, 2026.10.1, a build number), but the day a version first appeared is right for all of them. When two first appeared on the same day, the one with more users is the newest.

Comparing releases

Every row in the table is a filter. Choose 2.4.0, and every report shows only the people on that version: Events, Goals, Funnels, Journeys, Retention, Locations and Devices. To see whether a release raised sync_failed, open Events filtered to the new version, then to the one before, over the same range. The filter reads as version:2.4.0 in the address, so a comparison can be bookmarked or shared with your team.

AI assistants can do the same through MCP: get_breakdown with by: "version" names the newest version, and version:2.4.0 works in every tool's filters.

Pre-releases

A beta or a release candidate is a version like any other: send 2.5.0-beta.1 from your beta builds and its testers appear as their own line and row, beside production. Filter to it to see what they do before everyone else gets it.

Development and staging builds are better kept out of your numbers altogether, in a project of their own: see Production, staging and development.

No version recorded

Users whose app sent no version are counted apart, under the table, as having no version recorded. So are users from before versions were kept: a project has versions for the 90 days before the Versions report arrived, and from then on.

Sending a version

• A browser extension sends its manifest's version by itself, from @analyticstrend/extension 0.6.0. Pass appVersion to initBackground to send something else.
• A website built with the web SDK passes appVersion to init if it has releases worth telling apart, such as a single-page app's deploys.
• An app sends appVersion in every batch, as the App guide and its examples do. See the collector API for the field.