GPSR for Marketplaces: Product Safety, Traceability, and Recalls

GPSR is the EU General Product Safety Regulation, and on a marketplace it turns a recall into a question about data you either collected over the past two years or did not.

A recall is the one event in a marketplace where the supervisory authority, the buyer, and your board ask the same question within the same hour. What gets tested is not the procedure but the data collected over two years.

You cannot backfill that after the fact.

This article breaks down:

• Which 4 questions does a recall turn on?
• Which 2 directions does traceability run in?
• Where should the responsible-person data live?
• How do you reach buyers you have no address for?

Key insights

• A recall is not an announcement. It is four questions your database either answers in minutes or cannot answer at all.
• Who sold it. Who bought it. Where else the same thing is listed. What tells it apart from the one that looks like it.
• Your catalogue probably has offers on sale right now with nobody named as responsible for the product. Run the query this week.
• One batch can sit behind five offers under four different names. Take down the one you found by searching and the rest keep selling.
• Keep the query that produced the list, and the list. Six months later the same query returns something else.

Which 4 questions does a marketplace recall turn on?

Ask your team how many minutes it takes to answer four questions about any product in the catalog. Not "do we have a procedure," but how many minutes.

1. Who sold it. Which seller posted the offer, and who stands behind the product itself as the responsible person in the EU.
2. Who bought it. Which orders contained the item, how many units, to which countries, and how to reach those buyers.
3. Where else the same item is still listed. Under how many other sellers and under how many names.
4. What separates it from what looks like it. Without that, you take down too much or too little.

If any of those cannot be answered with a query against the system, you do not have a procedure. You have a description of one.

Each draws on different data, collected at a different moment by a different party: the first at seller onboarding, the second at the order, the third and fourth when the offer is published. And until you know the scope, you take nothing down, notify nobody, and answer nothing to the authority.

The whole process waits on the result of a single query.

Which 2 directions does product traceability run in?

Upstream, it leads to two entities. The seller posted the offer and holds the contract with you.

The responsible person answers for the product itself. Regulations require that for many categories of goods there be an entity established in the EU whose name and address are stated and genuinely reachable, even when the manufacturer sits on the other side of the world.

Those are two different roles, and in a marketplace very often two different companies: the seller bought from a distributor who bought from an importer. The authority asks about both.

Downstream, it leads to the buyer, and operators think about that direction last. The law goes further than intuition.

If you hold contact details for people who bought the recalled product, you are expected to use them and warn those people directly. A notice on the website is an addition to that.

The three moments of collection cannot be reordered. Seller onboarding.

Identity, registry entry, address, contact; the same set as in "Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions". Offer publication.

The product identifier, the batch or model number, the details of the responsible person, photographs. The order.

Who, when, how many units, to which address.

What you cannot collect retroactively. The batch number, if your offers never carried one.

The identifier, if the seller has already left. And the thing most projects overlook: the version of the product page from the day of purchase.

The page is editable, and a recall is about what the buyer received on the day of purchase. Without versioning, you cannot answer whether a warning covers a unit bought a year ago, and you cannot prove it does not.

Why is the responsible-person field empty on offers still selling?

This is the best-documented pathology in this layer, and worth naming, because you probably have it.

The mechanism is banal. A regulatory change adds a few new mandatory fields to the product page: the name of the entity placing the product on the market, its address, its seat.

Validation gets switched on for new offers, and from that day everything coming in carries them. Offers already published pass around that gate, because the gate stands at the entrance and they came in earlier.

You cannot switch the selling off, because that is half your catalog. Practitioners on large implementations say that to this day they open a random product page, look at the responsible-person field, and see nothing, while the offer is live.

What this means: you do not know the scale until you ask.

Run that query this week. "Field empty" is indistinguishable in the data from "does not apply", so a report without a breakdown by category is useless.

And the distribution says more than the total: a hundred thousand offers with the field blank sounds like a migration, but if they come from fourteen sellers, it is fourteen conversations.

Validating new offers does not cure this and cannot. Some platforms cannot run a rule against an already published catalog at all; their rules work only on the way in.

Others can, but the rule is destructive: instead of flagging non-compliant offers, it pulls them off the storefront, so running it unprepared looks like an outage in the sales report. The distinction between "flag" and "take down" decides whether this is configuration or a migration project.

"Marketplace Compliance: Adding a Required Attribute to a Million Offers" carries the vendor question and the whole method.

Why does taking one offer down fail to recall a batch?

The most common operational mistake in a recall is not legal. It is a mistake about sets.

An example. A batch of three thousand chargers travels from one manufacturer to five of your sellers.

On the platform, you see five offers and four different names ("65W wall charger", "USB-C 65W power adapter", the distributor's name, a name with a typo), two descriptions from two feeds, and two of the five carry no product identifier, because the field was optional. A warning arrives.

The operator types the name from the warning into the search box, finds one offer, takes it down, and closes the ticket. Four stay on the storefront, and two of them are invisible to any query at all.

The conclusion: a recall starts from the identifier. A commercial identifier plus a batch or model number is the only thing binding five independently written pages into one set.

As long as the identifier stays optional, "so onboarding stays frictionless," you have offers you will never find. That is not a data quality problem.

It is a hole in safety.

The risk is symmetrical: the same name, a different model. Take down too much, and the seller is right to demand a justification and the appeal path from "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension".

Where should the responsible-person data live: product, offer, or seller?

The market has no consensus here, and this is not a technical detail: where you keep the data about the responsible person decides how a recall runs.

The recommendation: product data on the product page, batch data on the offer. If you pick a single place, pick the product page.

One truth, and you fix it once. You then need a process for settling who may change it.

How do you reach marketplace buyers you have no address for?

Three situations in which "we will notify the customers" has nothing behind it.

1. The buyer's address is masked

In many implementations, the buyer and the seller write through an alias, with your mail relay underneath. That is a good decision for other reasons, but the seller cannot write to the buyer without you.

Practitioners add a second warning: the sending domain and the relay are one channel, and changing it without agreeing to that with your vendor can take the whole communication down at once.

2. The address belongs to the seller

Formally, somebody is there to write, but you have no proof they wrote. Settle it in advance: either you send yourself, in your own name, or you hand it to sellers and collect confirmations against a deadline.

The first is faster and provable, the second is cheap and unverifiable. There is no third option.

3. The buyer has no account

A guest purchase leaves an address and a phone number on the order. That is enough, because a safety message is not marketing: you do not ask for marketing consent before warning somebody about a charger.

The basis for contact and the retention period are a separate regime, taken up by "Marketplace GDPR: Controller, Processor, or Joint Controller?".

4. How you prove you sent it

Not with a screenshot of a campaign. With a log per recipient: order identifier, channel, timestamp, the version of the message, delivery status.

Add the people you never reached, because a failed attempt is part of the file too. The message itself carries requirements: the rules expect it to describe the risk plainly and not to soften its impact with reassuring language, and the buyer has to be given a choice between repair, replacement, and a refund.

Confirm with your lawyer how many of those options have to be available.

What goes to the authority, and what has to stay with you?

The notification goes through the public channel for businesses and calls for things most catalogs do not have to hand: what the product is (identifier, batch, recognizable photographs), what the risk is, how many units and in which countries, who placed it on the market, what you have already done. That is almost one-to-one with the four questions from the opening.

The authority is not inventing a form. It is asking for the result of your query.

What stays with you matters more than the confirmation of filing. The query stays, together with its result.

A list of affected orders without the criteria you built it from cannot be reproduced six months later: the catalog has changed, offers have expired, the seller has gone. A result without its criteria is not evidence.

It is a printout. Preserve a dated snapshot, because a bookmarked report recalculates itself.

What does GPSR change about the rest of your marketplace?

1. The product identifier stops being a data quality field

It becomes a safety field, and that changes the decision: required, with a narrow and deliberately closed list of exceptions. Entry gates and category permissions are a separate decision ("Restricted and Prohibited Products on a Marketplace: The 3 Gates").

2. The product page needs a version and a date

A recall is only ever about the past.

3. Taking an offer down needs a reason, a trail, and an appeal

You act fast and sometimes too broadly, so the appeal path from "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension" protects you as well.

4. The money flows through the pipe you already have

A refund for a recalled product is a refund: on a €1,000 cart at a 12% commission, the same question about €120 comes back, and "Marketplace Refunds: Who Pays for Them and Out of What?" and "Who Keeps the Marketplace Commission on a Refunded Order?" settle it. Who funds the replacement, and whether the commission comes back when the manufacturer is at fault. Settle both before the first case.

5. Keep the neighbouring topics apart

Backfilling missing fields goes to "Marketplace Compliance: Adding a Required Attribute to a Million Offers". Producer obligations go to "Extended Producer Responsibility (EPR) for Marketplaces: Who Pays the Environmental Fee?".

Complaints and repairs belong to the after-sales chapters, and shipment tracking is a logistics function that does not replace product traceability.

How do you drill a marketplace recall in one hour?

Do not audit the procedure. Run the drill instead.

Pick one real product with at least three offers and give the team only what you would get in a real warning: a photograph and a trade name, with no identifier. Start the clock.

• 0 to 10 min: find that product in the catalog from the photograph and the name alone.
• 10 to 25 min: list every offer of the item across all sellers, plus who the responsible person is and whether the field is filled in.
• 25 to 40 min: the list of orders from the last two years, the number of units, the countries of delivery.
• 40 to 50 min: the list of buyers with a contact channel; separately, how many have no account, how many have a masked address, how many you will not reach.
• 50 to 60 min: take the offers down and show the trail. Who, when, on what criteria, and whether the result can be reproduced a week from now.

Write down the time for every step. That is your real response time and the only number here worth showing the board.

Three outcomes repeat most often: searching by photograph takes a human being and half a day, "which orders" ends in an export to a spreadsheet, and there is no snapshot, so two runs of the same query give two different lists.

Three questions for the platform vendor, with a request to be shown rather than told:

1. A recall by identifier, covering the offers of five sellers listed under different names.
2. A rule run against the already published catalog. Ask it plainly: does it flag the offers or take them down?
3. Proof that a notification went out per recipient, with the version of the message and the list of people not reached.

Which mistakes do operators make about GPSR on a marketplace?

1. A recall designed as an announcement instead of a query

The procedure sits in a binder, and there are no queries: the first case takes three days instead of an hour, and the authority learns the scope later than the press does.

2. The product identifier as an optional field

It saves friction at onboarding and costs you offers you cannot find, so part of the batch stays live with no signal at all.

3. Compliance measured at the entrance

"New offers have all the fields" is true and says nothing about the catalog. You find out about live selling with no responsible person from the authority's question.

4. Buyer notification delegated to sellers with no confirmations

You have no proof anybody was warned, and the responsibility for that gap stays with you.

5. A list of affected orders with no criteria written down

Six months later you rebuild it by hand and get a different result from the one you sent the authority.

What do you still have to settle yourself about GPSR on a marketplace?

This guide is a map of data and process, and it deliberately carries no article numbers, no deadlines, and no thresholds. Confirm the scope of the duties, the deadlines, and which of them apply to you at all with an e-commerce lawyer, for your own categories and your own markets.

The families of regulation to bring to that conversation, so you are not discovering them mid-incident:

• the rules on general product safety, known in practice as GPSR: the platform's obligations, the content of the message, warning buyers;
• the rules on market surveillance and the responsible person in the EU: for which categories such an entity has to exist and which details have to be stated;
• the regulations on digital services, known in practice as the DSA: traceability of sellers, the notice-and-action procedure, informing buyers about a product that is unlawful;
• the personal data protection regime, known in practice as GDPR: the basis for making contact and the retention period for order data;
• the sector rules for your own categories: toys, electronics, chemicals, cosmetics, and medical devices all carry their own, stricter requirements;
• extended producer responsibility, if you bring goods in or import them yourself.

Our claim is narrower than any of those answers and independent of them: whichever set of rules ends up covering you, it will ask about the same four things. A catalog that cannot answer them is out of step with every version of the law at once, including the one that arrives next year.

Summary: What does a product recall test in your system?

Two years of data collection, in one hour. The seller's identity from onboarding, the responsible person from the offer, the identifier and batch from the product page, the orders and contact details from the checkout, and a dated snapshot of what the buyer saw.

Each was captured at a different moment by a different party, and none of it can be backfilled once a warning arrives.

Run the one-hour drill on a real product and write down the time for every step. Building a marketplace that has to answer all four recall questions in an hour? Talk to us about the build.

Frequently asked questions on GPSR for marketplaces

What does GPSR require from an online marketplace?

That you can identify the product, the seller, the responsible person, and the buyers, and act on all four quickly. It also shapes what a warning has to say and how it reaches people.

Which duties fall on you, and from when, is a question for a lawyer covering your categories and markets.

Who is the responsible person for a product sold on a marketplace?

An entity established in the EU whose name and address appear with the product, and it is usually not you. It can be the manufacturer, an importer, an authorised representative, or a fulfilment service provider.

The seller supplies the value; your platform decides whether the field exists, is required, and can be queried.

Does a marketplace have to notify buyers of a recall directly?

If you hold contact details for the people who bought it, you are expected to use them. A notice on the website sits on top of that.

Prove it with a log per recipient: order identifier, channel, timestamp, the version of the message, and delivery status, including the people you never reached.