The Product Graph: Why Individual Product Data Beats SKU Data
Your business intelligence team can tell you exactly how many units of Model X shipped last quarter. They can break it down by channel, region, and price point. They can layer in return rates, margin contribution, and attach rates for accessories. It looks like insight. It feels like control.
It isn't.
What they cannot tell you is what happened to unit number 4,812. Where it ended up. Who owns it. Whether it's been serviced. Whether it's sitting in a skip or circulating on eBay. Whether the person who bought it is furious or delighted. Whether the filter clogged in month three and they never called support. They just switched brands.
SKU data is a photograph of what left your factory. A product graph is a living record of what a product did in the world. The gap between those two things is where a great deal of service revenue, loyalty, and liability management quietly disappears.
What Is a Product Graph?
A product graph is the complete, connected data record for a single physical unit, not a model, not a batch, not a category. One unit. It captures every meaningful event and relationship across that product's entire lifetime, from manufacture to end-of-life.
Think of it as a graph in the computer science sense: nodes and edges. The product is the central node. Connected to it are events (manufacturing, shipment, sale, registration, scan, support ticket, parts order, warranty claim, resale), entities (retailers, owners, technicians, service centres), and states (in warranty, out of warranty, recalled, resold, decommissioned).
A mature product graph for a single power tool might contain:
- Manufacturing: assembled at Line 4, Plant C, batch QC-2241, serialised at 09:14 on 14 Jan
- Distribution: shipped to a regional distribution centre on 22 Jan, transferred to a local branch on 3 Feb
- Point of sale: sold on 3 March, transaction ID captured via GS1 Digital Link scan
- Registration: registered by an owner in Birmingham B15, on 5 March, two days post-purchase
- Support: inbound query on 12 April for a stuck filter, resolved via self-service guide, step 7
- Parts order: replacement filter F-449 ordered 13 April, delivered 15 April
- Secondary market: scanned at a car boot sale in Solihull on 8 September, ownership transfer flagged
- End of life: deposited at a WEEE collection point, 14 February following year
That is one product. That is one product graph. And it tells you things no SKU report ever could.
The SKU Data Ceiling
SKU-level data was designed for a world where manufacturers had no post-sale visibility. It answered the only questions the business could ask: how many did we make, how many did we ship, how many came back?
Those questions still matter. But they represent the first few minutes of a product's multi-year life. The remaining years, the period during which customers form lasting brand opinions, buy replacement parts, recommend or condemn your product to friends, and decide whether to buy from you again, are largely invisible.
The consequences are predictable:
Recalls stay incomplete. Without knowing which specific units went where and who owns them now, manufacturers rely on press releases and retailer cooperation. Completion rates for recalls broadcast without direct owner contact tend to be low. With unit-level ownership data, a manufacturer can reach affected owners directly rather than hoping a notice is seen.
Support is reactive and expensive. Without knowing a product's history, every support interaction starts from zero. The customer explains the problem; the agent asks which model; nobody knows it's the third call about this unit or that it's out of warranty. Average handle time and cost per case stay stubbornly high.
Aftermarket revenue is invisible. You know Filter F-449 sells well. You don't know that it sells best to owners of a specific unit series, roughly a year into ownership, in postcodes with hard water. That kind of insight, available only at the unit level, is the difference between a generic parts catalogue and a targeted aftermarket revenue engine.
Circular economy claims are harder to verify. A sustainability report can say a share of products is recyclable. A product graph can describe which products were actually collected, by whom, when, and where. That distinction is becoming more significant under EU ESPR rules.
SKU Data vs. Product Graph Data
| Dimension | SKU Data | Product Graph |
|---|---|---|
| Granularity | Model / batch | Individual unit |
| Ownership | Unknown post-sale | Named, dated, located |
| Support history | Aggregate ticket counts | Per-unit event timeline |
| Location | Last known warehouse | Current owner location |
| Resale / secondary market | Invisible | Detected via scan events |
| Recall targeting | Broadcast to all owners | Precision to affected units only |
| Parts demand forecasting | Category-level averages | Unit-age and usage-based signals |
| End-of-life status | Assumed from sales age | Verified via collection scan |
| Warranty validity | Date-based approximation | Owner-verified, unit-specific |
| Compliance evidence | Aggregate claims | Auditable per-unit proof |
Each row describes an operational capability that unit-level data can support, and a corresponding gap in what SKU-only data can answer today.
What a Product Graph Enables
Predictive Support
When support knows that unit 4,812 was registered over a year ago in a hard-water postcode, has had a filter query before, and is now approaching its second recommended service interval, the support interaction transforms. Instead of reactive troubleshooting, you can push a proactive maintenance reminder before the problem surfaces. Consider a hypothetical appliance manufacturer that pushes service reminders to the specific owners approaching a known wear point: rather than deflecting queries, it aims to prevent the conditions that generate them in the first place.
Precision Recall
Product recalls are one of the highest-stakes events in manufactured goods. The conventional approach, announce, broadcast, wait, struggles because there is no direct line to the specific owners of specific units. A product graph inverts this entirely. You know unit 4,812 is registered to a named owner in Birmingham. You can contact that owner directly, confirm the affected serial range, and track completion unit by unit. The difference between a recall that reaches most affected owners and one that reaches few is not academic: it is the difference between manageable liability and systemic failure. We explore this in detail in our piece on warranty data as an undervalued asset for manufacturers.
Lifecycle Analytics
Aggregate failure data tells you a component fails. Unit-level data tells you it fails in units manufactured in a specific week, in specific climates, after a specific usage pattern. That is the signal that drives root cause analysis, supplier negotiations, and design improvements. Suppose, for example, a power-tool maker used unit-level scan and support data to trace a bearing failure to units assembled during a short window when a lubricant supplier changed formulation. Catching that pattern early, before it spreads across a far larger population of units, is precisely the kind of saving unit-level precision is meant to enable. Warranty analytics can reveal these patterns as they emerge, helping manufacturers act before systemic failures take hold.
Circular Economy Verification
The EU Digital Product Passport (ESPR) requires verifiable information about a product's materials, repairability, and end-of-life pathway, accessible through a scannable identifier rather than left as a theoretical recyclability claim. A product graph can strengthen that evidence base: it can record a chain of custody from manufacture to collection point, with verified events at each stage, which is more than a static data sheet provides. Brands that build this infrastructure now are not just working towards compliance; they are building a capability that is hard to assemble quickly without serialised unit data. See our overview of the product data manufacturers aren't collecting yet.
Aftermarket Revenue at Precision
Parts sales, extended warranties, and service contracts are most valuable when offered to the right owner at the right moment. A product graph makes this possible. It knows the unit's age, its usage signals (inferred from scan frequency and support contact), its owner's location, and the parts most commonly ordered at this lifecycle stage. The result is not a generic upsell email; it is a contextually relevant offer that is more likely to convert because it is specific. We cover this revenue model in full in why a product experience platform should replace the CRM for manufacturers.
How to Build a Product Graph
The architecture is simpler than it sounds. It requires two foundational capabilities.
Serialisation means assigning a unique identifier to every unit, not just a model number, but a per-unit serial that is embedded in a scannable code (a GS1 Digital Link QR is a current standard) at manufacture. This is the anchor point for everything else. Without a unit-level identifier, there is no graph, only aggregate data.
Registration is how you attach a human owner to that identifier. Frictionless warranty registration at unboxing, triggered by scanning the product code, is among the most effective mechanisms. A registration experience is more likely to succeed when it is quick and delivers immediate value: warranty confirmation, a setup guide, a parts finder. Every registered unit becomes a named node in your product graph from day one.
From those two foundations, every subsequent event, support contact, parts order, resale scan, service visit, can be attributed to a specific unit and appended to its graph. The data model grows richer with every interaction, compounding in value over the product's life. A coherent product data strategy helps ensure that serialisation and registration integrate cleanly with existing systems.
A range of vendors and platforms now work on serialisation infrastructure, registration workflows, and lifecycle analytics, each with different emphases. BrandedMark is built specifically for manufacturers of durable goods who need all three layers, serialisation, registration, and lifecycle analytics, in a single platform with no-code experience design and support for GS1 and EU DPP requirements.
Frequently Asked Questions
How is a product graph different from an IoT device twin?
A device twin, in the IoT sense, mirrors the real-time state of a connected device: sensor readings, firmware version, operational status. A product graph is broader and works for any physical product, connected or not. It captures the lifecycle story of a unit: who owns it, what support they've needed, what parts they've ordered, where it's circulating. Many durable goods are not IoT-connected, and may never be. The product graph gives manufacturers unit-level intelligence for all of them, via scan events and registration data rather than continuous telemetry.
What is a realistic registration rate, and does the graph have value if most units aren't registered?
Registration rates vary widely by category and by how the registration experience is designed. Even when only a minority of units in the field are registered, a product graph still gives you individual-level data on a meaningful share of them: enough for precision recall targeting, cohort analysis, and aftermarket segmentation that is more useful than SKU aggregates alone. The graph also grows denser over time as more touch points, including support, parts, and resale scans, append to existing records.
How does the product graph relate to EU Digital Product Passport requirements?
The EU Digital Product Passport under ESPR asks manufacturers to provide verifiable information about a product's materials, repairability, and end-of-life pathway, accessible via a scannable identifier on the product itself. A product graph is a data architecture that can support this at unit level. Manufacturers who build serialisation and lifecycle event tracking can use much of the same foundation to work towards DPP readiness, rather than treating the two as wholly separate projects.
The Shift That Is Already Happening
The manufacturers gaining ground in aftermarket revenue, recall management, and customer loyalty are often not doing anything structurally exotic. They are not necessarily spending more on advertising or hiring larger service teams. They are building product graphs, quietly, unit by unit, and compounding the advantage with every product that ships.
SKU data will always have a place in manufacturing operations. But it describes what left your factory. The product graph describes what your product did in the world, who it belonged to, what they needed from it, and what it is worth to them today.
That is not a reporting upgrade. That is a fundamentally different relationship between a manufacturer and the things they make.
BrandedMark gives every product a unique identity, a registered owner, and a full lifecycle record, from first scan to end of life. If you are ready to build your product graph, explore BrandedMark.