One App. Every Release.
Per-Build XR Application Analytics.
This page is for the product owner of one immersive title — not a portfolio, one app — who needs to know what changed between the last two builds before signing off the next release. XR application analytics, framed around the release cycle of a single product.
The problem this discipline solves
Shipping an XR product is a sequence of builds. Between v1.4 and v1.5 you moved a waypoint, retuned the tutorial pacing and shipped a new locomotion mode. Something in that changeset either helped or hurt — and the only honest way to know is to compare the two builds on the same cohorts, the same scenes and the same comfort thresholds. That comparison, done properly, is what we mean by XR application analytics on this page.
This is deliberately narrower than 'spatial analytics'. It is not a research methodology and it is not a data warehouse. It is a per-release loop: baseline the current build, ship the next one to a beta cohort, diff completion and comfort by scene, decide what to keep. Repeat next Friday.
The rest of this site covers the broader stack — the platform view for org-wide rollouts is at /xr-analytics-platform, the researcher workflow at /analyze-xr-behavior. This page stays focused on one thing: how a single app team decides whether to promote the next build.
What the release-cycle loop looks like
Baseline the current build
Pin the last GA build as the reference. Every downstream release is diffed against it — completion, hesitation, comfort spikes, stability — until you deliberately move the baseline forward.
Ship the candidate to a beta cohort
Tag the beta cohort in the SDK config. The build appears in the compare view the moment the first session lands, without waiting for a nightly rollup.
Diff by scene, not by app
An app-level metric hides scene-level regressions. Comparisons are broken down by scene so a tutorial-only regression does not get averaged away by a strong endgame.
Decide, then move the baseline
Promote, hold or revert with the diff attached to the decision. Once promoted, the new build becomes the baseline for the next candidate — the loop stays honest release after release.
Guardrails, not vanity metrics
Every release ships against explicit guardrails: comfort spike rate, tutorial completion floor, stability event ceiling. A candidate that breaches a guardrail is flagged for review before promotion — no green dashboard hides a red scene.
What you compare between builds
- Completion rate per scene, per cohort, per build
- Hesitation deltas at named waypoints and interactions
- Comfort spike rate — count and severity — per scene
- Stability events (freezes, drops) with spatial anchor
- Accessibility guardrails: reachable volume, missed affordances
- Time-to-first-interaction per new scene in the release
For the pieces that feed this loop: capture layer (what the SDK sends), researcher workflow (deep-dive analysis), session replay (debug one bad session), Unity SDK (install reference).
Why release-cycle framing beats generic dashboards
Generic XR dashboards answer 'how is the app doing'. That is not the question a release owner asks the day before promotion. The question is 'did this changeset make it worse in any scene, for any cohort, on any headset'. Framing analytics around the build diff is what makes the answer actionable. More on the philosophy in our XR vs traditional analytics article and our comparison with Cognitive3D.
Frequently asked questions
Promote the next build with a diff, not a hunch
Join the Gossip Analytics beta and put your XR release cycle on a per-build comparison loop.
Request beta access