Google Play Console just added an App version dimension to the Statistics page, so DAU, MAU, session counts and other engagement metrics can be broken down or filtered by the exact build a user is running. Until now, a release that quietly tanked engagement was invisible in the aggregate numbers — a bad build could drag down average session length for a week before anyone noticed, and by the time it showed up in the top-line chart, most of the damage was already done and the causal thread back to a specific release was gone.
That lag is the real cost. Engagement dashboards built purely on rolling averages answer “is engagement up or down this week” but not “did version 4.12.0 break something.” Without a version dimension, teams either shipped changes blind to their per-release impact, or bolted on their own client-side version tagging to get the same answer Play Console can now give natively. If your own analytics events already carry an app version property — most do — this is a chance to cross-check Google’s first-party numbers against your own instrumentation rather than replace it.
Data Points to Track
- App version string on every engagement event, matching the exact format Play Console uses (
versionName+versionCode) so cross-referencing the two dashboards doesn’t require guesswork - Rollout percentage at time of event, for staged rollouts, so a dip can be attributed to the release itself rather than to the smaller sample size of an early rollout stage
- Session length and screens-per-session, segmented by version, to catch UX regressions that don’t show up as crashes but still shorten sessions
- Time since update installed, distinguishing users who just updated from those who’ve been on a version for weeks — early-adopter behaviour often looks different from steady-state
- Device and OS version paired with app version, since a regression that only appears on specific device/OS combinations is easy to miss in an aggregate version breakdown
Setup Steps
- Confirm your event schema already stamps app version on every event; if it doesn’t, this is the first fix, since Play Console’s new dimension is only useful if your own analytics can speak the same language.
- Build a saved Play Console view filtered to the current release, comparing its DAU/MAU trajectory against the prior version’s first-week numbers, not against the whole app’s rolling average.
- Set a threshold alert — a manual or scripted check — for when a new version’s session length or Day-1 retention drops more than a set percentage below the previous version’s equivalent window.
- Cross-reference staged rollout percentage against the version breakdown so early swings from a small rollout cohort don’t trigger false alarms.
- Archive version-level snapshots at 7 and 14 days post-release; Play Console’s live view updates continuously, so a point-in-time export is the only reliable way to compare release-over-release later.
Actionable Insights
A version showing lower session length than its predecessor in the first 48 hours, before the rollout has widened past a small percentage, is usually noise — wait for the rollout to reach a representative sample before reacting. A sustained drop that persists once the rollout is complete, especially paired with a specific device/OS combination, points to a real regression worth a hotfix rather than a UX quirk to monitor. And a version that shows strong Day-1 numbers but a steep drop in Day-7 retention relative to prior releases usually means the update changed something in onboarding or first-session flow rather than anything users encounter later — worth checking against onboarding completion data before blaming retention broadly.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert