Who Pays for a Connected Product? The Economics of Identity, Data, Events and Services
Connected products create costs and benefits across different actors. Use payer-beneficiary alignment to choose subscriptions, usage, service or shared-cost models.

The cheapest layer of a connected product is often not the layer that determines whether the business model works. Resolution and request-serving can be cheap. Integration, physical capture, secure provisioning, support, governance and measurement can dominate the operating model. So the useful question is not simply "what does a connected product cost?" It is which actor benefits from each layer, who controls the decision to use it and whether the value created can actually be observed well enough to support the commercial model.
The short answer
Price a connected-product system around the actor that captures observable value and controls the relevant decision. Where the beneficiary, decision-maker and cost owner are different organisations, design the cost-sharing explicitly rather than assuming the manufacturer should pay for every layer.
There is no defensible universal connected-product or DPP cost benchmark in the accepted evidence, and public vendor prices should not be averaged into one. Outcome-linked pricing can work selectively, but only when measurement is strong enough to support a contract-grade attribution rule.
Navigate this page
- Overview
- The short answer
- Why "what does a DPP cost?" is the wrong question here
- The Connected-Product Cost Gradient
- Who benefits, who controls and who can observe?
- BCO: the natural payer test
- Business-model choices: upfront, subscription, usage, servic
- Why public prices cannot be averaged
- Physical capture and secure hardware change the economics
- Scale is not ROI
- METER: when outcome pricing is defensible
- Software, services and hardware have different economic risk
- Portability and switching are part of the business model
- What to do now
- Keep exploring
- Sources and evidence boundary
Why "what does a DPP cost?" is the wrong question here
ActivateDigital already has a canonical guide for generic DPP programme cost. That page owns the question of what a passport programme costs and why there is no single published figure.
This article owns a different problem: who should fund which layer of a connected-product system, and what commercial model best aligns cost, control and benefit?
That distinction matters because a connected product is not one cost line.
The CIRPASS SME study found that prospective DPP providers were often reluctant or unable to provide a single quantitative implementation cost. It identified cost elements beyond software, including integration, identifiers, certification, maintenance, training and project management. CIRPASS also discussed multi-tenancy and delegation as ways to spread implementation cost, but did not establish a universal realised cost curve. (CIRPASS SME cost study)
That is the first economic lesson: the commercial unit you can price is not necessarily the same as the total system you need to operate.
The Connected-Product Cost Gradient
We use a Connected-Product Cost Gradient as an ActivateDigital synthesis. It separates the layers that can look almost commodity-like from the layers that remain organisation- and use-case-specific.
| Cost layer | Typical components | Economic characteristic |
|---|---|---|
| Resolution / request-serving | Resolver, redirects, API requests, basic compute | Can be very cheap per request at scale |
| Identity / data service | Identifier records, passport hosting, basic workflow | Often subscription or usage priced |
| Enterprise integration | ERP/PIM/PLM connectors, mapping, data remediation | Organisation-specific implementation effort |
| Physical capture | Printing, labels, RFID/NFC, readers, application | Unit and lifecycle cost tied to physical operations |
| Security / provisioning | Secure tags, keys, authentication, credential management | Adds hardware and operational complexity |
| Operations / governance | Support, SLA, monitoring, data quality, change control | Recurring service and organisational cost |
| Measurement / outcome proof | Exposure data, control groups, attribution, audit | Required before value-linked pricing is defensible |
The gradient explains why low digital request cost cannot be used as a proxy for programme TCO.
GS1 operates a free resolver service and says organisations can connect barcodes to the web for free or operate their own resolver. Cloudflare's published Workers example prices 100 million requests per month at 7 ms CPU per request at $45.40 under its stated assumptions. AWS Lambda separately publishes request charges starting at $0.20 per million requests for the cited service model, with compute and other charges additional. Those figures demonstrate that request-serving can be inexpensive. They do not price data remediation, ERP integration, carrier deployment, support, governance or an enterprise SLA. (GS1 Resolver, Cloudflare Workers pricing, AWS Lambda pricing)
Cheap serving is not cheap operation.
Who benefits, who controls and who can observe?
Connected-product value is often split across actors.
A manufacturer may pay for identity and passport hosting. A retailer may benefit from better operational events. A repair provider may benefit from verified part or service information. A marketplace may benefit from authentication signals. A consumer may benefit from product information but should not be expected to fund infrastructure merely because they can scan a product.
For DPPs specifically, the legal access architecture also constrains the business model. Article 11 of the EU Ecodesign for Sustainable Products Regulation requires relevant actors to have free-of-charge and easy access to DPP data according to their access rights. The same provision constrains service-provider reuse of stored data beyond what is necessary for the service unless specifically agreed with the economic operator. That does not mean the economic operator receives hosting, integration, governance or SLA services for free. (Regulation (EU) 2024/1781, Articles 9-11)
The provider's legal role and data-use boundary are owned by who is allowed to hold your passport data and what they may do with it. Commercial design must respect that boundary rather than treating legally required access as a paywall opportunity.
BCO: the natural payer test
We use a three-part BCO test: Beneficiary × Control × Observability. This is an ActivateDigital decision framework, not an industry rule.
1. Beneficiary
Who captures the economic benefit if the connected-product capability works?
Examples might include fewer manual interventions, better service conversion, lower loss, faster recall handling or a new paid service. The benefit must be defined for the actual workflow, not assumed from the existence of the technology.
2. Control
Who can decide whether the capability is deployed, used or operationally followed?
The actor who benefits may not control the relevant process. A brand can fund a tag, for example, while a downstream retailer controls whether readers are deployed in stores.
3. Observability
Can the result be measured with enough precision to prove who benefited and by how much?
This is where many attractive business models fail. If the outcome cannot be measured against a valid denominator and counterfactual, it cannot safely support gain-share pricing.
A useful payer hypothesis is strongest when the same actor has high benefit, meaningful control and observable outcomes. When those dimensions split, the commercial model usually needs cost-sharing, minimum commitments or a simpler subscription structure.
| BCO pattern | Likely commercial implication |
|---|---|
| One actor has benefit + control + observability | Direct subscription, usage or service fee is plausible |
| Beneficiary differs from controller | Shared-cost or channel agreement may be needed |
| Benefit is high but observability is weak | Avoid outcome pricing; use fixed/usage pricing while measurement improves |
| Control is fragmented across many actors | Platform, consortium or service-provider model may fit better |
| Benefit is public/compliance-led rather than privately captured | Do not force a value-share model onto legally required access |
Business-model choices: upfront, subscription, usage, service and shared cost
Different layers support different commercial models.
Upfront or implementation fee
Best fit: data remediation, integration, migration, custom security work and physical deployment projects where effort is front-loaded and customer-specific.
Risk: the supplier is paid for implementation even if ongoing adoption is poor. The customer should therefore separate acceptance criteria for implementation from later business outcomes.
Subscription
Best fit: recurring software, hosting, governance tools, identity management and support where the service is continuously available.
Public market examples show this model is already common. Minespider publishes annual Digital Battery Passport packages of €11,900, €19,700 and €34,500, with optional services and SLAs separate. DPP-Tool publishes monthly tiers from €29 for 100 products through €399 Enterprise, with different API, analytics, SLA and export features. PicoNext uses subscription packages with Enterprise pricing on contact. These are vendor-specific offers with different inclusions, not a market price series. (Minespider pricing, DPP-Tool pricing, PicoNext pricing)
Usage or unit pricing
Best fit: a cost or value driver genuinely scales with units, requests, identities or events.
Amazon Transparency is a useful example of per-code pricing. Amazon publishes $0.05 per code for the first 1 million, $0.03 from 1,000,001 to 10 million and $0.01 above 10 million, with no enrolment or subscription minimum. That is an anti-counterfeit service price, not DPP compliance pricing, and it excludes printing/application, integration and wider operating cost. (Amazon Transparency pricing)
Managed service
Best fit: customers need operational support, governance, data stewardship, monitoring or integration help rather than software alone.
The economic structure can differ materially from pure software. Digimarc's 2025 filing reported $19.844 million subscription revenue and $14.069 million service revenue, with direct cost lines of $2.633 million and $5.648 million respectively, plus separately reported acquired-intangible amortisation. Simple arithmetic on those direct lines gives roughly 86.7% for subscription and 59.9% for service before that separately reported amortisation. This is ActivateDigital arithmetic on one company's filing, not a company-reported segment margin and not an industry benchmark. (Digimarc 2025 Form 10-K)
The point is not the percentages. It is that software and services can have different cost structures and commercial risks.
Shared-cost or ecosystem model
Best fit: one actor pays for infrastructure while value is distributed across brands, retailers, service organisations or consumers.
CIRPASS's discussion of multi-tenancy and delegation is relevant here because shared service infrastructure can spread implementation cost. It does not establish a guaranteed savings curve, so the model still needs a real allocation rule. (CIRPASS SME cost study)
For smaller operators, the practical adoption path belongs in Digital Product Passport readiness for small businesses.
Why public prices cannot be averaged
Public prices look comparable because they contain currency symbols. Often they are measuring entirely different things.
Consider four examples from the accepted evidence:
- Amazon Transparency prices codes and excludes broader operational integration.
- Minespider prices annual Digital Battery Passport packages with optional services and SLAs separate.
- DPP-Tool prices software tiers by product count and feature set.
- A University of Sheffield/AMRC tender estimated £410,000 excluding VAT for a robotic DPP research/demonstration cell combining hardware, readers, data and services.
Averaging those numbers would produce a number with no meaningful denominator. (Amazon Transparency, Minespider, DPP-Tool, UK Find a Tender notice 041264-2025)
The economic unit must stay attached to the price:
price per what, for which scope, with which exclusions, at what service level?
That is why there is no defensible universal connected-product price benchmark in the accepted evidence.
Physical capture and secure hardware change the economics
A connected product can remain mostly digital, or it can require physical capture infrastructure and secure hardware.
RFID, NFC, readers, tag application, key provisioning and physical operations add costs that do not appear in basic cloud or SaaS pricing. NXP's NTAG 424 DNA supports AES-128, SUN authentication, secure messaging and Common Criteria EAL4-certified hardware/software. STMicroelectronics' ST25TA-EB is a secure NFC Type 4 tag IC with digital-signature capabilities. Those sources establish technical capability, not representative industrial unit prices or guaranteed anti-counterfeit outcomes. (NXP NTAG 424 DNA, STMicroelectronics ST25TA-EB)
Carrier selection also creates lifecycle and replacement implications, so the detailed handoff is choosing a carrier that still works in five years.
Scale is not ROI
Large deployments prove that a technology can operate at scale. They do not prove that the deployment generated a particular financial return.
Amazon reports that Transparency has more than 90,000 brands and has verified more than 2.7 billion product units. Decathlon states that RFID was deployed on 100% of its products by January 2019 and describes nearly 50,000 readers across factories, warehouses and stores. Decathlon separately reported 1.23 billion products sold in 2025. (Amazon 2025 Trustworthy Shopping Experience Report, Decathlon RFID, Decathlon 2025 results)
Those are impressive scale facts. They are not the denominator for a specific workflow and they do not isolate causal ROI.
For example, "1.23 billion products sold" does not tell you how many units were eligible for a particular RFID workflow, how many were actually exposed to it, what the control condition was or what financial change was attributable to RFID rather than other operational changes.
That measurement problem is owned by two separate guides: how to test whether product information changes a business outcome and how to choose the right denominator for scans, repairs, recalls and resale.
METER: when outcome pricing is defensible
Outcome pricing is attractive because supplier and customer appear to win together. It is also easy to get wrong.
We use METER as the ActivateDigital outcome-pricing gate. The accepted evidence boundary is deliberately strict: do not link price to an outcome unless the relevant population is defined, eligible and exposed denominators are explicit, causal testing is credible and both parties can reproduce the calculation from agreed data.
In practice, ask:
- Is the outcome metric defined before the intervention is judged?
- Can you identify the population that was actually eligible and exposed?
- Is there a credible comparison or causal design rather than a before/after story alone?
- Can the economic value be calculated without double-counting unrelated effects?
- Can both parties audit and reconcile the result from the same underlying data?
If the answer to any of those questions is no, use a simpler commercial model until measurement improves.
This is deliberately selective. The accepted ActivateDigital measurement controls require explicit eligibility/exposure denominators and causal testing before product-information business outcomes are claimed. METER applies those controls to commercial contracting. It is not a recommendation for generic gain-share pricing.
Software, services and hardware have different economic risks
Company filings are useful for understanding that connected-product businesses can contain very different economic components, but they should not be turned into universal category margins.
Digimarc reported a mix of subscription and services revenue in 2025, and later said subscription revenue fell from $22.4 million to $19.8 million primarily because three commercial contracts expired. That proves contract concentration can matter to a recurring-revenue supplier. It does not establish why the customers did not renew or a market-wide churn rate. (Digimarc 2025 financial results)
Impinj, meanwhile, reported $361.075 million of 2025 revenue and $189.677 million gross profit, roughly 52.5%, across a RAIN RFID platform spanning endpoint ICs, readers, gateways, tag-production systems and licensing. It also disclosed that lower endpoint IC average selling price from product mix and pricing reduced 2025 endpoint revenue by $32.3 million, partly offset by $25.1 million from higher shipment volumes. This is evidence about one RFID platform company's hardware-heavy economics, not DPP software margins or a universal RFID price trend. (Impinj 2025 Form 10-K)
The commercial lesson is to avoid forcing all connected-product layers into one margin or pricing assumption.
Portability and switching are part of the business model
A low entry price can become expensive if the customer cannot move identifiers, passport data, links, mappings or operational history when a provider relationship ends.
That is why pricing should be considered alongside what you can take with you when you leave a provider. Portability affects switching cost, negotiating power and the credibility of long-term recurring pricing.
For DPPs, this also fits the ESPR direction towards open, interoperable, machine-readable data and avoiding vendor lock-in. The Commission's DPP Registry went live with a testing environment on 20 July 2026 and keeps product data decentralised while registering identifiers and associated metadata. The Registry's operation does not mean DPP obligations are already universal or that private platform pricing is standardised. (European Commission DPP Registry launch, Regulation (EU) 2024/1781)
What to do now
For each connected-product capability, work through the economics in this order:
- Separate the cost layers. Do not let cheap resolution obscure integration, operations or physical capture.
- Name the beneficiary. Be explicit about who receives economic value from the workflow.
- Name the controller. Identify who can actually deploy or operate the capability.
- Test observability. If the outcome cannot be measured cleanly, do not price against it.
- Choose the commercial unit. Subscription, usage, implementation, managed service or shared cost should follow the real cost/value driver.
- Keep legal access separate from commercial services. Free authorised access to required DPP data does not mean the operator's platform, integration or SLA is costless.
- Test portability. A low price with high switching friction can be a poor long-term commercial design.
- Use outcome pricing only after METER passes. Otherwise choose a model that does not depend on disputed attribution.
The practical rule is: price the layer around the actor that captures observable value and controls the relevant decision. Where those roles split, design the sharing mechanism instead of assuming one actor should absorb the full cost.
Keep exploring
The questions this page usually raises next.
- CompareNext questionHow to Test Whether Product Information Changes a Business OutcomeTest whether product information changes a business outcome with one treatment, a credible comparison, a pre-set outcome and a…
- CompareNext questionThe Denominator Problem: How to Measure Scans, Repairs, Recalls and Resale ProperlyMeasure scan, repair, recall and resale rates with the right eligible population, exposure rule and time window instead of dividing…
Sources and evidence boundary
The core evidence for this article comes from EU ESPR access rules and the 2026 DPP Registry architecture; CIRPASS research on SME DPP cost components; GS1 resolver economics; public vendor pricing from Amazon Transparency, Minespider, DPP-Tool and PicoNext; cloud price examples from Cloudflare and AWS; deployment-scale reporting from Amazon and Decathlon; SEC filings from Digimarc and Impinj; and secure-hardware documentation from NXP and STMicroelectronics.
These sources establish that the cost stack is layered, commercial denominators differ and software, services, hardware and operations can have different economics. They do not establish a universal connected-product price, universal ROI, representative industrial secure-tag cost or a general rule that outcome pricing is superior.
-
EU law
-
European Commission
-
Official study
What would change this answer: materially different legal access rules, robust independent cost benchmarks with comparable denominators, or contract-grade evidence showing that a specific outcome-pricing model generalises across connected-product use cases.
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.