Product Data vs Product-Generated Data

Product data usually describes what a product is. Product-generated data records what a connected product observed or did during use. The first supplies identity and relatively stable context; the second supplies changing operational observations.

Product data
model = X100
voltage = 24 V
serial family = X100-EU-24

Product-generated data
temperature = 72 °C
runtime = 4,182 h
error = E42

The value of the second set depends on reliably knowing which product, variant and installed asset generated it.

The distinction at a glance

Product data: identity and specification

In product information management, product data includes identifiers, taxonomy, technical attributes, dimensions, materials, commercial descriptions and document relationships. It often applies at more than one level:

• a family shares a design platform;
• a model identifies a defined product design;
• a variant fixes differentiating attributes such as voltage or capacity;
• a trade item or SKU represents a sellable or stocked configuration; and
• an installed asset is a particular serialised physical unit.

Those levels should be explicit. Attaching voltage = 24 V to the X100 family when a 48 V variant exists creates false context for every downstream observation.

Product-generated data: observations from use

Product-generated data is produced while a connected product operates or is used. It can include sensor measurements, status changes, counters, diagnostic codes, energy consumption, interaction logs and environmental observations.

It is not necessarily streamed telemetry. A runtime counter retrieved through a physical service port is still generated through product use. Conversely, a static specification downloaded from a manufacturer website is not product-generated merely because software transmitted it.

Useful product-generated data normally needs more than a name and value:

asset_id = SN-X100-004182
observed_at = 2026-09-12T14:03:28Z
metric = bearing_temperature
value = 72
unit = Cel
quality = measured
schema_version = 2.1
firmware_version = 5.4.0

Even this record depends on the asset ID resolving to the correct model and configuration.

Identity is the join between the two

The operational pattern is:

observation → installed asset → serial number → variant → model → product documentation

Suppose SN-X100-004182 emits error = E42. An event catalog may define E42 differently for firmware 4 and firmware 5. The asset registry must identify the installed firmware, and the product record must connect that asset to the correct model and manual revision. Without those joins, a well-formed event can trigger the wrong diagnosis.

Common breakpoints include:

• serial numbers stored without a manufacturer namespace;
• model aliases that are never resolved to one canonical identifier;
• variant-defining attributes inherited incorrectly from a family record;
• replacement assets that retain the old asset-to-location mapping;
• firmware and error-code definitions overwritten instead of versioned; and
• telemetry keyed to a gateway or account but not the physical emitting unit.

Where Claro fits—and where it does not

Claro’s relevant role is product identity: matching inconsistent manufacturer, supplier and internal identifiers and resolving product, model and variant records into a governed canonical structure. That can provide a dependable reference for an asset registry or connected-product data platform.

Claro is not an IoT device-management system, telemetry broker or EU Data Act legal platform. It does not replace device connectivity, event ingestion, access-control, cybersecurity, consent or legal review. The credible connection is the identity layer that helps operational systems know what each asset actually is.

Why the distinction matters for the EU Data Act

The terminology can create avoidable confusion. In ordinary catalog work, teams may say “product data” when they mean model names and specifications. In the EU Data Act, the defined term “product data” concerns retrievable data generated by use of a connected product.

The Regulation’s Article 3 requirements also cover relevant metadata needed to interpret and use that data. Product identity, units, field definitions, code lists and schema versions are therefore practical dependencies even when some of them are maintained outside the event stream.

See EU Data Act 2026: Product Data Requirements for Connected Products for the Article 3 milestone and a readiness workflow.

Not the same as a Digital Product Passport

A Digital Product Passport primarily carries structured information about a product under applicable product-specific rules. Product-generated data records what a connected asset did or observed during use. A DPP identifier may help establish a product relationship, but the passport does not automatically become the mechanism for connected-product data access, and the two obligations should not be collapsed into one project.

A minimum identity contract

Before consuming product-generated data, agree on a small, versioned identity contract:

• Every event identifies the emitting installed asset unambiguously.
• The installed asset resolves to a manufacturer, model and variant.
• Variant-defining configuration and firmware are effective-dated.
• Metrics specify units, datatypes, timestamps and quality states.
• Error and status codes resolve to versioned definitions.
• Corrections preserve provenance instead of silently rewriting history.

FAQ

What is the difference between product data and product-generated data? +

In everyday product-data practice, product data describes the product, model or variant, while product-generated data is created during the use or operation of a connected product. The EU Data Act uses product data as a defined legal term for data generated by use and designed to be retrievable, so the context must always be stated.

Is product-generated data the same as telemetry? +

Telemetry is a common type of product-generated data, but the broader category can also include locally stored runtime counters, diagnostic events or other retrievable observations that are not continuously transmitted.

Why does product-generated data need product master data? +

A reading or error code is only reliably interpretable when the emitting asset is linked to its model, variant, configuration and applicable documentation. Product master data supplies that identity and context.