Grouping crashes without erasing users

Crash vendors merge stacks to keep your inbox calm. That is a reasonable product goal and a terrible model of users. Two people can die on the same line of shared infrastructure — a JSON parser, an image loader — while doing completely different jobs in your app.

In Observatory nights we often meet a single “NullPointer in Gson” group that is actually checkout, profile avatar, and a forgotten debug screen. Merging them makes the count look important and the fix look imaginary. Splitting them too early makes the board look like confetti.

A split test we actually use

Ask three questions before you break a vendor group:

Do the failing frames sit in your code or in a library used by many journeys?
Do breadcrumbs or custom keys show different entry points?
Would a single patch close all three journeys, or only one?

If (1) is library, (2) is mixed, and (3) is “only one,” split on journey, not on the crashing line. Keep the vendor group as a parent so you do not lose the roll-up. Teach the PM the child names: “checkout currency,” not “Gson NPE.”

What we refuse

We refuse clustering that depends on a data scientist in the room. If your rubric needs a notebook to run, it will not survive a store week. Paper, a spreadsheet, and one custom key are enough for most consumer apps we see in Thailand.

The flagship lab on this topic uses a redacted Android export with three journeys hiding under one parser crash. Students who finish the studio artefact have to name the children out loud. That exercise is more useful than another lecture on edit distance.

Continue with the Observatory if you already have a group you cannot name in a sentence.