Quick answer: Gather device and config context from everyone affected, then look for the shared factor, GPU, OS, locale, settings, that the unaffected players lack. A bug that only hits some players is your data telling you the cause is in their environment; find the variable they share.
Some bugs hit a fraction of your players and leave the rest, including you, completely unaffected. These are among the most frustrating to debug because you cannot reproduce them on demand, and it is tempting to dismiss them as flukes. But a bug that affects some players and not others is almost never random, it correlates with something those players share: hardware, OS, locale, settings, or game state. Finding that shared factor is the whole game.
Partial Bugs Are Environmental Clues
The fact that a bug hits some players and not others is itself the most important clue you have. It means the bug depends on a variable that differs between players, the affected ones have some condition the unaffected ones lack. Your job is not to reproduce it on your clean machine (which by definition lacks the condition) but to identify what the affected players have in common. The 'some players' pattern is pointing straight at an environmental cause.
This reframes the bug from 'an unreproducible mystery' to 'a correlation waiting to be found.' Somewhere in the affected players' environments is a shared factor, and the bug is telling you to go find it rather than to assume the report is noise.
Gather Context From Everyone Affected
To find the shared factor, you need the environment data from each affected player: GPU and driver, OS version, locale, screen resolution, graphics settings, and what they were doing. Manually asking for all this rarely works, but automatic capture supplies it for free. When every report arrives with full device and config context, you have the raw material to spot the correlation.
Bugnet captures device context, OS, GPU, settings, and version with each report, so a bug affecting some players arrives with the environmental details of each one. That is exactly the data you need to find what the affected players share, gathered automatically rather than chased report by report.
Find the Shared Factor by Clustering
With context on every affected player, look for the variable they share that the unaffected players lack. Group the reports by device, driver, OS, and locale and watch for the cluster: if every affected player is on the same GPU vendor, or the same OS version, or a particular locale, that is your cause. The shared factor often points directly at the fix, a driver-specific workaround, a locale-specific bug, a settings combination to handle.
Grouping is what makes the correlation visible. One report saying 'crashes on my machine' is a mystery; twenty reports that all share an integrated-GPU-plus-vsync-off configuration is a diagnosis. A tool that groups by signature and lets you slice by device context turns a scatter of 'some players' reports into the specific environmental cause they all have in common, which is how you finally fix a bug you could never reproduce yourself.
A bug that hits some players and not others is a correlation, not a fluke. Find the variable they all share.