How I normalize benchmark scores across chip generations (and why raw AnTuTu numbers lie)

Tags: #showdev #webdev #data #seo

The problem

Benchmark scores inflate over time. A top AnTuTu result in 2024 was around 2.4M points; in 2026 the leaders are pushing 4M. So a statement like "this phone scores 3.1M" is meaningless without context — is that flagship-level today, or last year's midrange?

It gets worse when you mix sources. AnTuTu measures the whole system, Geekbench isolates the CPU, 3DMark stresses the GPU, DxOMark rates cameras on a completely different scale. None of them are comparable to each other, and none are stable over time.

I run MobileRank — a database of 2,500+ smartphones, 239 mobile SoCs and 47 GPUs — and the core feature is head-to-head comparison across generations. That only works if every device sits on one comparable scale. Here's how I approached it.

The approach

The short version: every raw score is converted to a 0–100 rating relative to the current state of the database, not to a fixed reference point.

Each category gets its own scale. Performance ratings come from CPU and GPU benchmarks, camera ratings from DxOMark, battery ratings from capacity and endurance data. A phone's overall rating is a composite of these, so a gaming phone with a monster chip and a mediocre camera doesn't accidentally outrank a balanced flagship — you can see exactly which category drags it down.

The key design decision is that the scale is relative and moving. When a new chip tops the charts, everything below it shifts slightly. A phone rated 95 in 2024 might sit at 88 today — not because it got slower, but because the ceiling moved. That's exactly the behavior I wanted: the rating answers "how good is this device right now, against everything on the market," which is the question people actually have when buying.

This is also why raw scores stay visible on every page next to the normalized rating. The 0–100 number is for comparison; the raw AnTuTu/Geekbench/3DMark figures are for verification. If you disagree with the weighting, the underlying data is right there.

Edge cases that bit me

Missing data. Not every phone has a DxOMark review — most midrange devices never get one. Filling the gap with a guess would poison the rankings, so devices are only rated in categories where real data exists, and the overall score reflects what's actually known rather than pretending completeness.

Same chip, different scores. An identical SoC performs differently depending on the body it's in — cooling, power limits and software tuning mean one Snapdragon 8 Elite Gen 5 phone can post noticeably higher sustained scores than another. So chip pages and phone pages are separate entities in the database: the chip has its reference scores, each phone has its own measured results.

Regional versions. Chinese and global variants of "the same" model often differ — chipset, battery, sometimes the whole spec sheet. They get separate entries (you'll see "(China)" suffixes in the database) instead of being merged into one misleading average.

The pipeline

The site is a programmatic build: every phone, SoC and GPU gets its own generated page, plus a page for every popular comparison pair — that's how it covers long-tail queries like "phone A vs phone B" that people actually type into search.

New devices and updated scores flow in daily, and ratings are recalculated on each update since the scale is relative. That's the tradeoff of a moving scale: you can't cache a rating forever, the whole ranking is recomputed when the data changes. At this database size it's cheap; it would need rethinking at 10x the scale.

What this looks like in practice

You can see the normalized scores in action on any comparison page, for example OnePlus 15T vs Vivo X300 Ultra — two ratings side by side, with the raw benchmarks, specs and prices underneath.

The database updates daily. There are no sponsored placements — rankings are just the data.

What's next

More depth on sustained performance (throttling is the biggest gap between benchmark numbers and real experience) and richer battery data.

If you've dealt with normalizing noisy third-party data at scale — especially handling scale drift over time — I'd genuinely love to hear how you approached it.