# What Can a Product Code Do After the Sale?

Source: https://activatedigital.ai/knowledge/guides/product-code-after-sale-services
Last verified: 4 September 2026
Summary: A product code can keep working after checkout, routing people to care, manuals, support, registration and other product-specific services.

## In 60 seconds

A product code can keep working after checkout. It can recognise the product and route someone to the right care information, manual, support path, registration journey or other product-specific service. Where an account is actually needed, sign-in or registration can be introduced as a separate step.

- GE Appliances, AEG and LG UK already run product-specific support routing. LG UK keeps registration as a separate sign-in step.
- The GS1-Conformant Resolver Standard 1.2.1, ratified in **August 2026**, lets one identified entity carry multiple typed service links.
- The Commission's 2021 GPSR impact assessment found pre-filled product information could increase registration completion. No rate is reproduced.
- A 2023 Joint Research Centre study in Spain, Germany and Bulgaria found substantial non-use of the QR route in the tested online setting.
- Not supported: that identity causes loyalty or revenue, that a scan identifies the customer or that recognition proves ownership or authenticity.
Product recognition, service routing and an account relationship are different layers. A scannable route also does not prove that anyone saw, understood or valued the information. For the mechanics of what happens between a scan and a destination, see [what happens when you scan a product code](https://activatedigital.ai/knowledge/passport/what-happens-when-you-scan).

## Start with the product, then add an account when needed

A product code can carry or resolve an identifier that tells a system which product, model or unit is in front of it. That can be enough to choose the right support destination.

It does not follow that the system knows who is holding the product.

This gives post-sale service two distinct layers:

| Layer | What the service can know or do | What does not automatically follow |
|---|---|---|
| Product recognition | Identify a product, model or unit and select relevant resources | The person scanning is not automatically identified |
| Product-specific service | Show the right manual, care information, support route or service entry point | The person has not necessarily registered, logged in or proved ownership |
| Optional account binding | Ask the person to sign in or register when the service job needs an account relationship | Registration does not turn product recognition into proof of authenticity or ownership |

Many after-sale jobs are about the object, not the person. Someone may need a manual, maintenance instruction or support route simply because the product is in front of them.

Where a service starts collecting or using personal data, the privacy question becomes its own design and legal problem. The existing guide on [personal data and privacy around product services](https://activatedigital.ai/knowledge/passport/personal-data-and-gdpr) owns that deeper privacy boundary.

## What is established now

The basic service pattern is already deployed.

**NOW:** product-specific self-service before mandatory sign-in is demonstrated in current manufacturer support flows. **NOW:** account-bound product registration is also demonstrated, but it remains a separate intentional step.

GE Appliances documents QR codes that use product information such as model and serial details to route owners towards registration and support resources. AEG describes product-level QR support that can expose documents, warranty information and tailored support. LG UK separates product recognition from account registration: a scan can help populate model or serial information, while registration still requires the customer to sign in.

These are first-party deployment examples. They show that product-specific post-purchase routing is practical now. They do not establish how widely people use the services, whether the services improve loyalty or whether they create a measurable commercial return.

The useful evidence is narrower and stronger: the service can know which product needs help before it needs to know which person is asking.

A standards layer can support the same architectural idea. The GS1-Conformant Resolver Standard 1.2.1, ratified in August 2026, allows an identified entity to be associated with multiple typed links and optional language or media metadata. That is a technical capability for selecting services around a product identity. It is not evidence of universal adoption, consumer engagement or a shared cross-brand customer profile.

## Where registration belongs

Registration is a different state from recognition.

LG UK's product-registration flow keeps those states separate. Product information can be recognised or entered first, but the customer relationship is created through an intentional account step.

That is a better mental model than assuming a scan itself "registers the customer".

There is some evidence that reducing product-entry friction can help a registration journey. In the European Commission's 2021 impact assessment accompanying the proposal for a General Product Safety Regulation, a product-registration experiment found that pre-filling product information could increase completion compared with asking consumers to enter the product information themselves. The accessible source used in this evidence pack does not expose the full denominator needed to reproduce a rate, so no percentage claim belongs here.

There is also counterevidence. The UK Office for Product Safety and Standards reported in 2025 that wording and branding changes could affect product-registration behaviour. So registration is influenced by journey design factors beyond product identity or pre-fill.

Product recognition can remove one source of friction. It does not prove that persistent identity causes registration, retention, loyalty or revenue.

Registration also does not prove ownership or authenticity. Those are separate questions with separate evidence requirements. See [why identity can support a service journey without proving ownership or authenticity](https://activatedigital.ai/knowledge/passport/identity-authentication-and-ownership).

## What a scan does not prove

A code creates an opportunity to access information. That is not the same as information exposure.

A 2023 Joint Research Centre behavioural study tested QR-code access to food information with participants in Spain, Germany and Bulgaria. It found substantial non-use of the QR route in the tested online setting, and the hybrid-label condition worsened speed and knowledge outcomes in that experiment.

The study is not about appliance support, registration or every post-purchase use case. Its value here is the boundary it establishes: the presence of a scannable route cannot be treated as proof that consumers used the route or understood what was behind it.

The same caution applies to service analytics. A scan count is not automatically an engagement rate, and the denominator matters. The evidence guide on [what a scan can and cannot tell you](https://activatedigital.ai/knowledge/evidence/what-a-scan-tells-you) owns that measurement question.

So the following claims are not supported by this evidence:

- persistent product identity itself causes loyalty, retention or revenue uplift;
- a scannable product code means consumers necessarily see or use the information;
- product recognition proves ownership or authenticity;
- a scan automatically identifies the customer;
- a resolver context mechanism is already a universal cross-brand preference profile.
They define the useful boundary of the service.

## A practical post-sale service design

**ActivateDigital implementation view:** start with the product-specific service, then introduce sign-in or registration only when the next action needs an account relationship.

A neutral flow:

**Recognise the product → serve the product-specific help → add an account step when the action needs one.**

The first step can select the right manual, care information, support route or service entry point. The second can give the person something useful immediately. The third can be reserved for jobs such as account registration or another deliberately account-bound service.

This is design guidance, not a legal rule.

It has two practical advantages. First, it keeps the product-service layer useful even when the person does not want to sign in. Second, it gives the identity request a clearer purpose because it appears at the point where the service needs an account relationship.

It also makes the architecture easier to reason about. Product identity, service routing and customer identity are separate things. They can be connected, but they should not be collapsed into one claim.

The same separation becomes important when the physical package itself is hard to read or navigate. The next question is [how an on-product code can route people to packaging information in a more accessible format](https://activatedigital.ai/knowledge/guides/accessible-packaging-product-code).

## The identity should survive the first transaction

A persistent identity can help the right product be recognised again during recall, repair, warranty, returns, resale and later lifecycle updates. It gives each workflow a reliable subject. It does not by itself prove ownership, entitlement, authenticity or condition.

Use the specialist owners for the next decision: [what happens to a DPP after a recall](https://activatedigital.ai/knowledge/guides/dpp-after-product-recall), [what repairers need](https://activatedigital.ai/knowledge/evidence/repairers), and [how digital product identity can support resale](https://activatedigital.ai/knowledge/guides/digital-product-identity-resale).

The long-term pattern is:

`LIST → SELL → UPDATE → RETURN → REPAIR → RESALE → RECALL → RETIRE`

The data and evidence around the product may change. The identity gives those changes a consistent subject. Return to the [Product Identity journey](https://activatedigital.ai/knowledge/product-identity) or apply the model to one of your own products.

## What would change this answer

The core distinction is stable today: deployed services can recognise products and route to product-specific help without automatically identifying the customer.

This page should be revisited if there are material changes to resolver or service-link standards, post-sale registration or privacy rules, or repeatable multi-brand deployments that change how product recognition and account-bound services are connected.

A future cross-brand preference layer would need more than a generic context parameter. It would need a shared normative vocabulary, governance and an implemented negotiation mechanism before it could be treated as an established interoperable capability.

## Keep exploring

The questions this page usually raises next.

- [CompareNext questionHow can an on-product code make packaging information more accessible?Next: How can an on-product code make packaging information more accessible?→](https://activatedigital.ai/knowledge/guides/accessible-packaging-product-code)
- [Another angleNext questionwhat happens when you scanFor the deeper mechanics and boundaries, continue with what happens when you scan, personal data and GDPR and what a scan tells you.→](https://activatedigital.ai/knowledge/passport/what-happens-when-you-scan)
- [Another angleNext questionpersonal data and GDPRFor the deeper mechanics and boundaries, continue with what happens when you scan, personal data and GDPR and what a scan tells you.→](https://activatedigital.ai/knowledge/passport/personal-data-and-gdpr)
- [Evidence behind thisNext questionwhat a scan tells youFor the deeper mechanics and boundaries, continue with what happens when you scan, personal data and GDPR and what a scan tells you.→](https://activatedigital.ai/knowledge/evidence/what-a-scan-tells-you)

## Sources

Sources checked as at **4 September 2026**.

- [GS1-Conformant Resolver Standard, release 1.2.1: used for the technical capability to associate an identified entity with multiple typed service links. It does not prove adoption or engagement.](https://ref.gs1.org/standards/resolver/) Standards body
- [GE Appliances, QR Code Guide and Resources: first-party deployment evidence for product-specific registration and support routing.](https://products.geappliances.com/appliance/gea-support-search-content?contentId=17723)
- [AEG Customer Support: first-party deployment evidence for product-level documents, warranty information and support routing.](https://www.aeg.co.uk/support/)
- [LG UK Product Registration: first-party deployment evidence separating product recognition from account-bound registration.](https://www.lg.com/uk/support/minho-page/product-registration/)
- [European Commission, SWD(2021) 168 final: official evidence that removing product-information entry can reduce one source of registration friction in the tested journey. No rate is reproduced here because the accessible evidence pack did not expose the full denominator.](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=SWD%3A2021%3A0168%3AFIN)
- [Office for Product Safety and Standards Delivery Report 2024–2025: counterevidence showing that wording and branding can also affect registration behaviour.](https://www.gov.uk/government/publications/opss-delivery-report-2024-2025/opss-delivery-report-2024-2025)
- [Joint Research Centre, Using QR codes to access food information: behavioural evidence that code availability is not the same as use or information exposure.](https://publications.jrc.ec.europa.eu/repository/handle/JRC134602)