Quick answer: Occurrence count is the tally of how many times a particular bug or crash has been recorded, after duplicates are grouped into one issue. It is the single most useful prioritization signal in bug tracking, because it objectively measures reach: how many players (or sessions) an issue has affected.
When you are deciding which bug to fix first, the question that matters most is usually 'how many players does this affect?' Occurrence count answers it. By tallying how many times a grouped issue has happened, occurrence count turns the vague sense that a bug is 'common' or 'rare' into a hard number you can sort and prioritize by. It is what makes data-driven bug prioritization possible.
What Occurrence Count Measures
Occurrence count is simply how many times an issue has been recorded, counted at the level of the grouped issue rather than individual reports. When duplicate reports of one bug are grouped together, the occurrence count is the size of that group: a crash that happened five hundred times has an occurrence count of five hundred. It is a direct measure of how often the bug occurs in the wild, and by extension, roughly how many players it affects.
This depends entirely on grouping. Without grouping, you have individual reports but no sense of how many represent the same issue; with grouping, each distinct issue carries a count that aggregates all its occurrences. Occurrence count is the number that grouping produces, and it is what gives each issue a measure of its scale.
Why It Drives Prioritization
Occurrence count is the objective reach signal that good prioritization needs. The bugs with the highest occurrence counts are, by definition, hitting the most players and happening most often, which usually makes them the most worth fixing. Sorting your issues by occurrence count instantly surfaces your biggest problems, no guessing, no being swayed by whoever complained loudest, just the bugs that are actually most widespread.
It also sharpens severity-versus-priority decisions. A severe bug with a low occurrence count (game-breaking but rare) and a minor bug with a huge occurrence count (trivial but everywhere) are both clarified by the count. Pairing occurrence count (reach) with severity (impact when it happens) gives you the two axes that together determine what to fix first, and the count is the half you can only get from real data.
Occurrence Count in Practice
To have occurrence counts, you need automatic grouping that aggregates reports of the same issue, and a steady stream of reports for it to count. The count then becomes a live measure you watch: a fast-climbing occurrence count signals a spreading problem, possibly a regression or a launch crisis, while a flat one is stable. Watching the trajectory of counts is how you spot emerging issues early.
Bugnet's occurrence grouping produces a running occurrence count for every issue automatically, so your dashboard shows distinct issues ranked by how many times each has happened. This makes prioritization mechanical, fix from the top of the occurrence-ranked list, and makes monitoring easy, a spiking count surfaces a problem as it grows. Occurrence count turns the abstract goal of 'fix what affects the most players' into a concrete, sortable number.
Occurrence count answers the question that matters most: how many players does this hit? It turns 'common bug' into a number you can sort by.