I turned Steam's new hardware data into a compatibility risk map

This post was originally posted on Vaporlens Patreon

Hey folks!

A couple weeks ago I wrote about Valve quietly adding hardware metadata to Steam reviews and how that immediately broke my brain in the best possible way.

Well, the first real version of that work is now live in VaporLens.

Short version: I now have a hardware sentiment matrix wired into the analysis pipeline.

Which means VaporLens can finally start answering questions like:

"Is this mostly falling apart on lower-VRAM setups?"
"Is this actually broken on Linux, or are a few Proton users just having a bad day?"
"Are performance complaints coming from low-end machines, or from hardware that should absolutely be fine?"

That is a lot more useful than just "performance is mixed".

The old problem: performance complaints were flattened into soup

Before this, a game could have 2,000 angry reviews about stutter, crashes, shader compilation, VRAM issues, or weird frame pacing, etc.

And VaporLens could tell you that performance sentiment was negative.

But it could not reliably tell you:

for who
on what hardware
on which OS
and whether the issue was "this PC is ancient" or "this port is cursed"

That distinction matters a lot.

A complaint from a 6GB VRAM setup is not the same signal as a complaint from a modern card that should be running the game without even noticing it's there.

What the matrix actually does

The new system groups review sentiment by hardware slices and lets me compare how pain is distributed.

Right now, the most useful buckets are things like:

VRAM ranges
RAM ranges
Windows vs Linux / Proton
Steam Deck / handheld

So instead of one generic blob of "bad optimization", I can start seeing patterns like:

8GB cards are hitting memory pressure while 12GB+ cards are mostly fine
Linux users are okay overall except for one launch blocker
Steam Deck players can run it, but they hate the UI scaling

That last distinction is especially important.

"Runs on Deck" and "good Deck experience" are not the same thing. That is also why I shipped the new Linux Index alongside this work: if a game runs on SteamOS, that tells me something useful about Proton/Linux compatibility, but I still want a separate signal for desktop Linux pain.

The annoying part: hardware data is only useful after normalization

Of course, Valve did not hand me a clean analytics table.

They handed me review-level metadata.

So before I could build anything useful, I had to normalize:

vendor names
VRAM values
OS labels
missing / partial hardware blobs
weird review-to-review inconsistencies

Without that step, the matrix would look precise while actually being nonsense.

And fake precision is worse than no chart at all.

The result is not "perfect hardware science".

It is a much more grounded answer to a very common question:

"When players complain about performance, which slice of players are we actually talking about?"

That is enough to make the hardware profile useful already.

What's next

I do have two obvious follow-ups in mind here.

The first is adding the refunded flag into review weighting more broadly.

That is not really a hardware-matrix thing. It is a wider pipeline thing.

If a review ended in a refund, that is usually a much stronger signal than ordinary dissatisfaction, so I want that to matter more across the analysis stack in general.

The second is testing whether vendor-level splits are actually possible and worth shipping.

In theory, AMD vs NVIDIA vs Intel would be extremely useful. In practice, I still need to answer two boring questions first:

is the hardware metadata clean enough to normalize vendor labels properly?
is the coverage high enough that a vendor split would be honest instead of fake precision?

If the answer is yes, great. If the answer is no, I'd rather keep the matrix simpler than ship a cool-looking lie.

← Back to Blog