Skip to content
Start a passport+ {Activate} Passport
Implementation & Decisions

The Denominator Problem: How to Measure Scans, Repairs, Recalls and Resale

Measure scan, repair, recall and resale rates with the right eligible population, exposure rule and time window instead of dividing actions by the wrong total.

Reading time
8 min
Written by
ActivateDigital
Last verified
Published
Sources
5
Share article
LinkedIn X Email
A woman scanning a labelled carton on a conveyor with a small data screen beside her.
Jump around this page

In 60 seconds

A scan, repair, recall response or resale percentage is interpretable only when four things are explicit: the numerator, the eligible denominator, what counts as exposure and the time window. Different connected-product funnels need different denominators, so the total number of products made, codes printed or products in market is not a universal base.

  • If you cannot state which units were eligible to produce the action, do not present the count as a rate. Scannability is not engagement.
  • A resolver request is measurable but does not show how many people saw the code. Packs printed are not exposures.
  • Recall measurement keeps four populations apart: affected, reachable, notified and completed-action.
  • Two programmes can both report "12%" while one divides unique scans by exposures and the other divides all requests by products shipped.
  • No industry standard currently mandates these denominator definitions. Credible benchmarks need comparable definitions and populations first.

The governing rule: if you cannot state which units were eligible to produce the observed action, do not present the action count as a rate. A code can be scannable without being seen. A product can exist without being repair-eligible in the observation window. A recalled unit can exist without its owner being reachable. Scannability is not engagement.

For scan evidence, what a scan actually tells you covers the channel evidence. This page covers the measurement contract underneath the percentage.

Why the denominator changes the story

A numerator is usually easy to count. Systems record requests, transactions and events. The denominator is harder because it asks a counterfactual question: how many units, people or opportunities could reasonably have produced this action?

The GS1-Conformant Resolver Standard shows how a resolver can receive requests against identifiers and return typed links. That creates a measurable service-boundary event. It does not tell you how many people saw the code, how many physical items were in use or whether the request came from a human rather than software.

GS1 EPCIS gives systems a standard vocabulary for lifecycle events across what, when, where, why and how. That can improve event consistency. It does not guarantee that trading partners exchange every event, use the same permissions or share a denominator.

The same problem appears in public evidence. SmartLabel's 2021 consumer research reported stated use of SmartLabel and QR experiences, but stated survey behaviour is not an observed exposure-adjusted scan rate. A Polytag and Ocado serialised-QR programme reported participants and large numbers of coded packs, but coded or printed units are not the same thing as eligible exposures. Dividing one by the other would manufacture a benchmark the source does not support.

Maturity today

StateWhat is justified
NOWDenominator discipline is directly applicable to scan, recall, repair and resale measurement.
EMERGINGShared measurement contracts across connected-product programmes.
POSSIBLEIndustry benchmarks, but only if definitions, populations and observation windows become comparable.
NOT_SUPPORTEDTreating scannability as engagement or reporting observed actions as reliable rates when the eligible or exposed population is unknown.

A comparison matrix for four outcome families

The table below is ActivateDigital measurement guidance: a design framework for making different funnels explicit, not a claim that one industry standard currently mandates these denominator definitions.

Outcome familyNumeratorEligible denominatorExposure definitionKey exclusionsTime windowCommon wrong denominator
ScanValid scan/resolver requests under the declared counting ruleUnits or people with a realistic opportunity to encounter a working carrier, if that population can be measuredCarrier was present and available to the eligible population; distinguish this from a mere unit being producedBots, repeat requests where uniqueness matters, test traffic, units never exposedFixed campaign, ownership or observation periodAll units produced, all codes printed or all units shipped
RepairEligible products entering or completing the defined repair outcomeProducts that were in scope for repair and observable during the periodProduct was in use/in scope and the repair route was available under the programme definitionProducts outside warranty/service scope where relevant, unavailable parts, unobserved external repair if the metric cannot capture itFixed age band or observation periodEntire installed base regardless of age, failure or service eligibility
Recall responseRecalled units for which the defined corrective action was completedUnits within the affected recall population, with a separate reachable/notified denominator where communication effectiveness is measuredOwner or responsible party was reachable/notified through the declared channelUnaffected lots, units outside the recall scope, unreachable units when measuring notification response separatelyRecall campaign period plus declared completion windowAll products ever sold or all units in the product family
ResaleEligible items listed, sold or transferred under the defined outcomeItems that were genuinely eligible and observable for the chosen resale opportunityItem entered the resale route or was exposed to an eligible resale opportunityProducts outside programme scope, unobserved private resale, stock never offeredFixed ownership or listing periodAll products originally sold, regardless of resale eligibility or observation

The matrix doesn't force all programmes into one denominator. It makes the differences impossible to hide.

Scan rates: a server request is not an exposure denominator

A resolver request is measurable. It is also downstream of several events you may not observe: a unit was produced, the carrier remained present and readable, a person encountered it, chose to scan it and the device completed the request.

These are different metrics:

  • working carriers as a share of eligible units;
  • observed scans as a share of measurable exposures;
  • unique scanners as a share of exposed people, where that population can legitimately be measured;
  • downstream actions as a share of scans;
  • downstream actions as a share of eligible units.

If exposure cannot be measured, report a count or a clearly bounded proxy rather than inventing a scan rate. Do not use packs printed as though every pack was seen by a consumer. Do not use total sales as though every buyer encountered the code.

For the evidence around real-world scan measurement and its limitations, use What a scan actually tells you.

Repair rates: start with products that could actually enter the repair funnel

A repair rate needs an eligibility rule before it needs a percentage.

The total installed base can be a poor denominator when products differ in age, failure opportunity, access to service, geography or programme eligibility. A young product that has had almost no opportunity to require repair should not automatically be treated as equivalent to an older product that has been in use throughout the window.

ActivateDigital measurement guidance: define the product population, the observation window and the event being counted. “Repair rate” might mean repair requests, repair starts, successful repairs or repairs that avoided replacement. Those are not interchangeable.

If the measurement depends on item-level repair history, the architecture question is separate: what repair information can follow a product and help a repairer. This page does not redefine that operational evidence.

Recall response: affected, reachable, notified and completed are different populations

Recall measurement is especially vulnerable to denominator collapse because several populations sit inside one another.

The US FDA food traceability rule demonstrates a mature cross-actor pattern built around Critical Tracking Events, Key Data Elements and traceability lot codes. It is not an EU DPP analytics standard, but it shows why operational scope matters: the affected population is defined through traceable events and identifiers rather than through a vague product-family total.

For a recall programme, keep at least these populations separate:

Affected population: units, lots or serials actually inside the recall scope.

Reachable population: affected units for which a responsible person or channel can be reached, where that is measurable.

Notified population: affected/reachable units for which the required communication was actually sent or delivered under the chosen rule.

Completed-action population: affected units for which return, repair, disposal or another defined corrective action was completed.

A “recall response rate” calculated as completed actions divided by every product ever sold answers a different and usually much weaker question. The operational/legal handling of recalls belongs in what happens to a DPP after a product recall.

Resale rates: decide whether the opportunity is an item, listing or transaction

Resale can be measured at several stages, and the denominator has to match the stage.

A programme may care about items eligible for resale, items submitted, listings created, listings sold or completed ownership transfers. Dividing sales by all original product sales would mix products that never entered a resale opportunity with products that did.

The legal and product-scope question is also separate. Existing stock does not become subject to a DPP obligation merely because it is resold. See the second-hand product boundary. Identity can reduce operational friction in a resale flow without changing that legal scope. The adjacent architecture question is how digital product identity can support a resale journey, which should stay separate from the denominator used to measure that journey.

ActivateDigital measurement guidance: pick the opportunity you are trying to improve, define which items could enter it and measure conversion between adjacent stages. Do not label platform activity as a market-wide resale rate when the platform observes only its own eligible population.

A measurement contract before a percentage

For every reported rate, keep the same minimum record:

FieldRequired statement
NumeratorWhat event is being counted?
DenominatorWhich units, people or opportunities were eligible to produce it?
ExposureWhat had to happen before the event was possible?
Unit of analysisItem, batch, user, order, listing, transaction or another declared unit?
ExclusionsWhat was removed from the population and why?
Time windowDuring which period could the outcome occur?
DeduplicationAre repeat events separate or collapsed?
Data coverageWhich channels or actors are not observed?

ActivateDigital measurement-governance rule: if the eligible denominator cannot be stated, publish the observed count and its limits rather than a percentage that implies a population you do not have.

That rule also prevents invalid benchmark comparisons. Two programmes can both report “12%” while one divides unique scans by measurable exposures and the other divides all requests by products shipped. They are not measuring the same thing.

Agreeing the denominator is the part that makes the number mean anything, and it has to be agreed before the test runs rather than after. ActivateMeasurement is built around that order: it sizes a test and states the smallest effect it could honestly detect before any budget is committed.

What would change this answer

The framework should be revisited if high-quality industry standards establish shared denominator definitions for connected-product measurement, or if enough programmes publish comparable definitions and populations to support credible benchmarks.

Until then, common technical event formats are useful but insufficient. A resolver can log a request. EPCIS can structure an event. Neither defines the business denominator for you.

Keep exploring

The questions this page usually raises next.

Sources

Sources as at 4 September 2026.

Does this reach your products?

Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.