Sign in

Blog · Data quality and reconciliation

Product taxonomy for analytics: lines, families and SKUs, and which level each measure uses

Why a product list with four hundred SKUs produces whitespace everywhere and a concentration figure that means nothing, the three levels a product taxonomy needs, line, family and SKU, which measure is computed at which level, the rule that a SKU belongs to exactly one family and a family to exactly one line, the dated mapping that survives a range change, and the identity that revenue sums identically at every product level.

By CoviragePublished 16 September 20263 min read
The short answerA product taxonomy for analytics has three levels: lines, ten to thirty, which whitespace and products-per-customer use; families, which catalogue fit, quote conversion and warranty use; and SKUs, which stock, pricing and out-of-stock inference use. Every SKU belongs to exactly one family and every family to exactly one line, with dates so a range change is a new row and not an overwrite. Revenue sums to the same total at every level, and a measure computed at the wrong level, whitespace on SKUs or price realisation on lines, is wrong before it starts.

The ledger carries a product code on every line. Whether that code is a SKU, a family or a line decides whether the measure computed on it means anything. This guide sets out the three levels, which measure uses which, the one-parent rule, the dated mapping, and the identity.

The three levels

Level Count, typically Definition Measures computed here
Line 10 to 30 What the company sells as a line and manages as one Whitespace, products per customer, cross-sell and upsell, share of wallet by line, price realisation by line
Family 50 to 300 A group of substitutable SKUs within a line Catalogue fit, quote conversion, warranty claim rate, range fit per store
SKU Hundreds to thousands The stock-keeping unit Out-of-stock inference, substitution pairs, lost lines, price per unit, the product tail

The one-parent rule

Every SKU belongs to exactly one family. Every family belongs to exactly one line. Dated.

A SKU with two families, or a family with none, fails the check and is listed. Tags for secondary uses are attributes, not parents.

The identity

Σ revenue by line = Σ by family = Σ by SKU = ledger revenue, for the period, using the mapping in force

A ledger line whose product code is not in the taxonomy fails it and is listed as unmapped, counted, and excluded from every product-level measure until mapped.

The dated mapping

SKU Family Line Effective from Effective to
K-104 F-12 Dairy 2021
K-227 F-40 Frozen 2021 2025-06-30
K-227 F-41 Frozen 2025-07-01
K-990 F-12 Dairy 2026-03-01

SKU 227 moved family mid-year. Reports for the first half use the old family; the second half the new. SKU 990 is new and mapped from day one.

Which level, worked

Question Level Why
Which customers do not buy something similar customers buy? Line Similar customers buy lines; SKUs vary by taste
Which customer's catalogue coverage is narrow? Family Families are the units of a range
Which store ran out on Tuesday? SKU Stock is by SKU
What share of revenue is the tail? SKU, presented by line The tail lives at SKU; the board reads lines
Is the discount above agreement? SKU, rolled to line Prices are per SKU; the policy is per line

Where it goes wrong

Whitespace on SKUs. Every cell empty; the list meaningless.

Price realisation on lines. A line's average hides the SKU where the override lives.

SKUs in two families. The roll-up double-counts.

Mapping overwritten. Every product measure restated to the start.

Unmapped codes dropped. Revenue missing from every product view; the identity would have caught it.

Once built, checked on every upload

Mapped once and dated, the product master and the ledger produce the three-level roll-up, the one-parent check and the identity on every upload, with unmapped codes listed. Covirage builds this from the exports as they are. The metrics governance solution describes the setup, and the whitespace analysis guide covers the measure that most depends on the line level being right.

Questions people ask

How many lines?

As few as the company manages as lines: ten to thirty. A whitespace grid with four hundred columns is empty everywhere; one with twelve says something. Lines are the level at which similar customers are compared on what they buy.

What about a SKU in two families?

It is in one, by rule. A product that genuinely serves two families is placed in the one it is sold under, and the other is a tag, not a parent. The roll-up needs one parent per SKU or the identity fails.

What happens when the range changes?

A new SKU gets a family and a line from its first day. A discontinued SKU keeps its history. A family moved to a new line gets a dated row, and reports for earlier periods use the old line. Overwriting the mapping restates every product-level measure back to the start.

Related reading

Data quality and reconciliation

A CRM data quality scorecard: five fields, five checks, one number per rep

How to score CRM data quality from the export rather than from complaints: five fields that every coverage and pipeline measure depends on, owner, close date, stage, activity date and account identifier, the check for each, the completeness and validity rate per rep, why the score is reported beside the measures that depend on it, and the rule that a measure computed on data under a stated score is shown greyed.

16 Sept 20263 min readData quality and reconciliation

Account hierarchy: parents, subsidiaries and the level you actually sell to

How to build and use an account hierarchy for sales analytics: the levels that exist in most customers, group, legal entity, site, department, the one level where the buying decision is made and every measure is computed, the levels beneath kept as dimensions, the dated parent mapping that survives acquisitions, the identity that revenue sums identically at every level, and the two mistakes that produce forty customers where there is one and one where there are forty.

16 Sept 20263 min readData quality and reconciliation

B2B customer segmentation from the ledger, not from personas

How to segment a B2B customer base from data the company holds: the two or three fields that make a segment useful for norms, size, sector and channel, why behavioural fields like order frequency and product mix belong in the measures rather than the segment definition, the minimum segment size that makes a norm mean something, the test that a segmentation is good, and why personas do not survive contact with a ledger.

16 Sept 20263 min readData quality and reconciliation

Baseline and norm: what this account usually does, and what accounts like it do

The difference between a baseline, an account's own typical level from its own history, and a norm, what similar accounts do when the relationship is full, why the two answer different questions, has this account changed and how far is it from where it could be, which measures use which, surge and dormancy against baseline, gap and share against norm, the case where an account is at its baseline and far from the norm, and the rule that both are stated on the line that uses them.

16 Sept 20263 min read