What Vehicle Population Data Reveals About Product Coverage

A Complete Catalog Isn't Always a Good One

At dPivot, I worked on reporting systems for a client in the automotive parts industry. One question we wanted to answer was how well their products covered the vehicles actually being driven, rather than simply how many vehicle configurations appeared in the catalog.

That distinction matters. A product catalog could cover thousands of vehicle configurations and still miss some of the most popular vehicles on the road. Equally, a catalog with fewer applications might cover a much larger share of the actual vehicle population.

If you're deciding where to invest in new products or improve catalog coverage, counting applications alone doesn't tell you enough.

Counting Applications Versus Counting Vehicles

The traditional way to measure coverage is straightforward. Count the vehicle configurations that have at least one matching product, then divide that by the total number of configurations.

But that treats every configuration equally, regardless of how many vehicles are actually on the road.

By combining fitment data with vehicle population figures, we could look at coverage differently. Instead of asking what percentage of configurations had products, we could ask what percentage of the vehicle population those products covered.

A Simplified Example

In this illustrative example, the catalog covers two of the three configurations, giving it 67% coverage.

But those two configurations represent 510,000 of the 560,000 vehicles on the road. Population-weighted coverage is therefore approximately 91%.

Neither number is wrong. They answer different questions. The first measures catalog completeness. The second gives a better indication of how much of the vehicle market the catalog can serve.

Getting the Data Right

The calculation is simple enough. Getting the underlying data into a form where the calculation makes sense is more complicated.

Vehicle population data and product fitment data aren't always recorded at the same level of detail. One dataset might identify a vehicle by make, model, and year, while the product fitment depends on the engine, submodel, or another configuration detail.

This creates a problem. If you join the data too broadly, you can make it appear that a product covers vehicles it doesn't actually fit. If you use overly restrictive matching, you may exclude valid applications.

There's also the risk of counting the same vehicle population multiple times when several products fit the same configuration.

The approach needs to account for the level of detail available in both datasets and avoid treating incomplete population data as more precise than it really is.

This is one of the reasons I enjoy working on data systems. Writing a query isn't necessarily the difficult part. Understanding what the data represents, and whether the resulting numbers can be trusted, often is.

What Should the Product Team Do with It?

Once we could compare product coverage against vehicle population, the information became more useful for identifying gaps.

A missing application for a vehicle with a large population might deserve attention before several missing applications for vehicles that are rarely seen on the road.

But population isn't the whole business case. A large vehicle population doesn't guarantee strong demand for every product category. There are still questions about competition, expected sales, margins, and the cost of developing or sourcing a suitable product.

I'd treat uncovered population as a way to identify where to investigate, not as an automatic instruction to add products.

The level of detail also depends on who's using the information. Leadership might want to compare overall coverage across brands or product categories. A catalog manager needs to know which specific applications are missing so they can determine whether the gaps are genuine and what can be done about them.

Why this was Worth Doing

The original reporting work at dPivot had already shown how much time could be saved by making data easier to access. We reduced a reporting process that had taken nearly a full day to approximately ten minutes.

Adding vehicle population analysis took the reporting beyond simply retrieving information. It provided a way to identify gaps that might represent meaningful market opportunities.

That's the part of business intelligence I find most useful. Faster reports are valuable, but the more interesting question is whether the information helps someone make a better decision.