vPlatform
Crash grouping fixed for shipping builds, app hangs, crash-free players
FIXEDCrashes from RELEASE builds were grouped wrong — and this is the big one, because it affects the majority of real player telemetry. A shipping (IL2CPP/AOT) build writes stack frames like “at Game.Player.Update () [0x00010] in <8f4a2b1c…>:0”, where that hex value is an id for the compilation, not for your code. We were including it in the grouping hash, so the SAME bug produced a DIFFERENT signature in every build you shipped: it kept reappearing as a brand-new “first seen” issue, occurrence counts were split across releases, and regression detection could not see that a bug had come back. Editor-reproduced crashes also grouped separately from the identical crash arriving from a shipping build. Both are fixed, and the fix applies to builds already in players' hands — we regroup server-side on ingestion, so there is no SDK update to install. ONE-TIME EFFECT WORTH KNOWING: signatures computed from now on differ from the old ones, so a currently-open issue will start collecting under a new row, and triage state (resolved / assigned) does not carry across. Expect a burst of “new” signatures that are really your existing bugs, correctly grouped for the first time.
NEWApp hangs are now a first-class card on Analytics — count, players hit, median / p95 / worst stall, and the worst scenes ranked. Your SDK has been detecting main-thread freezes since 0.11 and sending them, but nothing on our side read them: they landed as anonymous custom events you would only find by digging through the event browser. A freeze produces no crash report and no stack trace, so this was the single failure your players call “the game is broken” that the dashboard never mentioned. Nothing to instrument — detection is on by default with a 5 second threshold, so if your game froze in the selected window, the card already has it.
NEWCrash-free PLAYERS, alongside crash-free sessions on your Command Center. Sessions tell you how often the game fails; players tell you how many people it failed — and they can be very far apart. A bug that crashes one unlucky player forty times barely dents crash-free sessions on a busy game, and reads as a healthy 99%; the player figure shows that person for what they are, a whole player having a bad time. Read the two together: a wide gap means your crashes are concentrated in a minority of players, which is the shape that quietly drives churn and refunds.
FIXEDARPDAU · 24h was understated on high-volume games. Its numerator (purchases) comes from the analytics page's event budget, which on a busy game does not reach back a full 24 hours, while its denominator (active players) always did — so a partial day of revenue was divided by a whole day of players, by a factor nobody could see. Where the events cannot span 24 hours the figure is now withheld and labelled “withheld · window too dense”, with an explanation on hover, instead of showing a number that is quietly low. Narrowing the range or applying a build/platform filter brings it back. Every other revenue figure on the card was already scoped honestly to the events it had.
FIXEDA play session that ran across UTC midnight was counted as two sessions in the crash-rate denominator — once on each side of midnight — so every crash rate was understated by roughly the share of your sessions that straddle midnight. Rates and per-build rates will therefore read slightly HIGHER than before; they were too low, and this is the correction. Crash counts, crash-free percentages and session lists were never affected. If your game has long sessions the change is larger, because more of them cross midnight.
IMPROVEDNothing about how you are billed has changed. What changed is that the two rules protecting your invoice are now covered by tests instead of by inspection: within a billing period the reported peak can only ever RISE, so a temporary dip in our own measurement (a row ageing out, a query hitting a size limit, a player exercising erasure) can never quietly move your bill — and at the start of a new period it resets to that period's own peak instead of carrying the previous one forward. Both rules already worked; neither was verified automatically, on the one code path where a silent mistake becomes a wrong invoice.
IMPROVEDA studio on a negotiated price is now provably excluded from automatic metering, including the free-forever case — zero is exactly the value a careless check would read as “unset” and bill at the full published ladder.