We Stress-Tested Our Demographics Engine. Here's What Came Back.

At Zonera, we help businesses make smarter location decisions — whether you're opening a new store, evaluating a franchise location, planning delivery zones, or running geo-targeted campaigns. Our platform calculates demographics for any area in the Netherlands using official CBS (Statistics Netherlands) data at the 100-meter grid level.

But none of that matters if the numbers aren't accurate. A retailer choosing between two sites, a franchisor deciding where to expand next, a marketing team planning a local campaign — they all need to trust the data they're looking at.

So we decided to put our calculations to the test. Not a quick sanity check — a proper, independent stress test.

Why We Did This

Our demographics engine does something deceptively complex. When you draw a zone on the map, we fetch thousands of CBS data points, calculate geometric intersections between your zone and each data cell, weight the results by overlap ratio, and aggregate everything into a final demographic profile.

There are many places where subtle errors could creep in: a rounding issue in the intersection calculation, a weighting bug in the aggregation, an off-by-one in the data fetching. These wouldn't cause the system to break — it would still produce numbers. They'd just be slightly wrong numbers, and you'd never know.

That's exactly the kind of problem we wanted to rule out.

How We Tested

The critical design decision was this: we didn't test the system by re-running its own algorithm. If we had, we'd only be confirming that the code runs — not that it produces correct results. A systematic error would go undetected because the test would make the same mistake.

Instead, we built three completely independent approaches to compute expected values, then compared them against what our system produces.

Approach 1: Grid cell direct summation. We selected specific blocks of CBS 100-meter grid cells in Amsterdam, Utrecht, and Amersfoort. For these blocks, the expected answer is simply the sum of all cells — no intersection math required. If our system returns the same totals, the entire pipeline from data fetching to final aggregation is working correctly.

Approach 2: Partial overlap with known ratios. We constructed zones that intentionally cut through grid cells at known fractions (50% overlap, 25% overlap). Instead of relying on our geometric intersection algorithm, we calculated expected values using simple arithmetic. This tests whether the weighting and proportional calculation is accurate.

Approach 3: Municipality-level comparison. CBS publishes official aggregate statistics at the municipality level. These are pre-computed totals — no calculation involved. If our zone covers part of a municipality, our numbers must be proportionally lower. If our zone is larger than the municipality, our numbers must be higher. This catches any gross errors in the aggregation logic.

The Results

We tested 9 zones across 52 individual metrics: population, gender split, age distribution, household composition, housing types, property values, income levels, origin, marital status, and vehicles.

51 out of 52 metrics passed with less than 1% deviation from the independently computed ground truth. Zero failures.

The single warning was a minor rounding difference in the vehicles-per-household metric (0.80 vs 0.83) — a consequence of how averages are rounded at different aggregation levels, not an error in the calculation.

For the grid cell tests, population and household counts matched exactly. Not approximately — exactly. 12,630 people in our system, 12,630 people in the ground truth. The same pattern held across all three test cities.

For the partial overlap test, even with cells weighted at 50% and 25%, all metrics stayed within 0.5% of the expected values.

What This Means for You

If you're a retail chain evaluating two candidate locations, the population counts, income levels, and household profiles you see in Zonera reflect the actual CBS statistics for that exact area — not rough estimates or interpolated approximations.

If you're a franchise network deciding where to expand, the demographic differences between locations are real differences, not noise from the calculation engine.

If you're a commercial real estate broker presenting a location report to a client, the numbers in that report stand up to scrutiny. They come from official government statistics and survive independent verification.

If you're a marketing team planning geo-targeted campaigns, the audience profiles for each area accurately reflect who actually lives there.

Location decisions are expensive to get wrong and slow to reverse. The data behind them should be as accurate as possible. After this round of testing, we're confident ours is.

This Isn't a One-Time Thing

We've built this testing pipeline to run continuously, not just once. Every time we update our calculation engine, change data sources, or add new metrics, we re-run the full suite against CBS ground truth. If anything drifts, we catch it before it reaches you.

Data accuracy isn't a feature you ship once. It's a commitment you maintain. That's what we intend to do.

If you'd like to see the data for a specific location, try Zonera — it takes less than a minute to get your first demographic report.