MediaMarktSaturn EU Data Act Product Attributes: Seller Guide (2026)

Last verified against current MediaMarktSaturn/Lengow marketplace documentation: 23 August 2026

MediaMarktSaturn has turned the EU Data Act into a structured product-attribute workflow for connected products.

For marketplace sellers, the implementation is unusually explicit. MediaMarktSaturn's seller communication introduced seven dedicated PROD_FEAT attributes for EU Data Act product information:

• PROD_FEAT_94000 — form, type and volume of generated data
• PROD_FEAT_94001 — real-time data generation
• PROD_FEAT_94002 — capability of storing data
• PROD_FEAT_94003 — duration of data retention
• PROD_FEAT_94004 — data accessibility for the user
• PROD_FEAT_94005 — additional EU Data Act information
• PROD_FEAT_94006 — link to manufacturer information

MediaMarktSaturn also tells sellers that, where the manufacturer provides the required information on its own website, the seller can provide a stable manufacturer link that leads directly to that information.

This is important because it shows what Article 3 looks like when a legal transparency requirement reaches a real marketplace catalogue:

the regulation becomes product data.

This guide explains what each MediaMarktSaturn EU Data Act field means, how the seven attributes map to Article 3, when a manufacturer link can replace or support manually entered fields, what real MediaMarkt product pages currently show to shoppers, how manufacturers should structure source data, and how sellers can avoid creating inconsistent marketplace-specific descriptions for every SKU.

Need the manufacturer source record first? Use the free EU Data Act Product Data Notice Generator to structure the underlying Article 3 information before converting it into marketplace fields.

Important: RegCatalog is independent and is not affiliated with or endorsed by MediaMarktSaturn. Marketplace attributes and category requirements can change. Always verify the current marketplace/Mirakl documentation before production submission.

Quick answer: what are the MediaMarktSaturn EU Data Act fields?

MediaMarktSaturn's September 2025 marketplace communication, documented by Lengow, introduced the following attributes for connected products:

Operational source:

MediaMarktSaturn — EU Data Act: new attributes for connected products (Lengow Help Center)

The seller communication tells sellers to:

1. check whether their offers are connected products;
2. enter the required information in the new PROD_FEAT fields or insert a reliable manufacturer link, consulting the supplier/manufacturer where necessary.

It also warns that non-compliance can lead to issues with offers being listed and potential regulatory consequences.

Why MediaMarktSaturn created these attributes

The underlying legal source is Article 3 of Regulation (EU) 2023/2854, the EU Data Act.

Article 3(2) requires specified information to be provided before a contract for the purchase, rent or lease of a connected product is concluded.

The core information includes:

• type, format and estimated volume of product data;
• whether data can be generated continuously and in real time;
• whether data can be stored on-device or on a remote server;
• intended retention where applicable;
• how users can access and retrieve the data;
• how users can erase data where relevant;
• technical means;
• terms of use;
• quality of service.

Primary legal source:

Regulation (EU) 2023/2854 — EUR-Lex

For the full field-level Article 3 explanation:

EU Data Act Product Data Notice Guide

MediaMarktSaturn's seven attributes are therefore not arbitrary ecommerce metadata. They are a marketplace representation of the Article 3 product-information problem.

What shoppers actually see on MediaMarkt product pages

The implementation is already visible on live MediaMarkt product pages.

Current MediaMarkt Spain product pages include a section labelled:

Information according to EU Data Act

Examples reviewed for this guide include:

• Xiaomi smartwatches;
• Amazon Fire TV devices;
• EZVIZ connected security cameras;
• TCL connected televisions;
• connected sensors and smart-home devices.

The product pages show structured fields corresponding to the marketplace attributes, including data type/form/volume and other Data Act information.

Examples:

• Xiaomi Watch 2 product page on MediaMarkt Spain
• EZVIZ H8c connected camera
• Amazon Fire TV Stick HD

This matters for sellers and manufacturers because it confirms that the fields are not merely hidden compliance metadata.

They become customer-facing product information.

MediaMarktSaturn's own Data Act information page

MediaMarkt Germany also maintains a public Data Act information page explaining how it handles connected products sold by third parties.

The page states that MediaMarktSaturn acts as retailer rather than data holder for those products and that detailed product-data information is available on the relevant product page under the Data Act information area.

It says manufacturer-provided information covers details such as:

• data type;
• format;
• estimated volume;
• retention;
• access/retrieval/deletion;
• real-time capability.

Official MediaMarkt source:

MediaMarkt — EU Data Act Information

This reinforces the operational model:

Manufacturer product-data facts
        ↓
Marketplace product attributes / manufacturer documents
        ↓
MediaMarkt product page
        ↓
Customer before purchase

PROD_FEAT_94000: form, type and volume of generated data

This is the most information-dense field.

It corresponds broadly to Article 3(2)(a):

• product-data type;
• format;
• estimated volume.

A strong source record should separate those components even if the final marketplace field combines them.

Type

Examples can include:

• operational data;
• sensor measurements;
• device status;
• energy usage;
• diagnostics;
• fault events;
• configuration;
• location;
• interaction or usage events.

Do not write only:

The device collects data.

That does not identify the type.

Format

Examples:

• JSON;
• CSV;
• XML;
• binary log;
• H.264/H.265;
• JPEG;
• Apache Parquet;
• proprietary structured record.

Real MediaMarkt product pages currently show highly product-specific formats. Connected-camera information, for example, can distinguish binary logs from multimedia formats.

Estimated volume

The legal concept is estimated volume, not perfect precision.

Useful values include:

1–5 MB/month
100–500 KB/day
up to 512 GB local media
variable depending on events
approximately 200 MB per log file

If volume varies, explain what drives the variation.

Recommended internal structure

Even if MediaMarkt expects one output field, manufacturers should maintain:

data_category
format
estimated_volume
volume_basis
generation_frequency

separately.

Then the marketplace adapter can generate PROD_FEAT_94000.

PROD_FEAT_94001: real-time data generation

This field captures whether the connected product generates data in real time.

Do not automatically set Yes simply because the product has sensors.

Products can be:

• real-time;
• periodic;
• event-driven;
• locally buffered then uploaded later;
• mixed depending on category.

A smartwatch can, for example, produce some measurements continuously while synchronizing them later.

A robust source record should capture:

• real-time: yes/no/conditional;
• continuous: yes/no/conditional;
• generation frequency;
• conditions/exceptions.

Example output

Yes for live temperature and status telemetry. Diagnostic logs are event-based and uploaded after an event.

or:

No. Data are stored locally first and synchronized later.

Keep the product truth more detailed than the final marketplace label.

PROD_FEAT_94002: capability of storing data

This field addresses storage capability.

The canonical product record should distinguish:

• on-device storage;
• remote-server/cloud storage;
• transient processing;
• mixed storage.

Weak answer

Yes

Strong answer

Sensor measurements are stored in a local rolling buffer and synchronized to the manufacturer's remote service when the device is connected.

For Article 3, storage and retention are linked concepts, which is why PROD_FEAT_94002 should come from the same canonical storage profile as PROD_FEAT_94003.

PROD_FEAT_94003: duration of data retention

Retention should describe how long relevant product data are stored where applicable.

Typical patterns include:

• fixed number of days;
• rolling overwrite buffer;
• until account deletion;
• until factory reset;
• configurable by customer;
• product lifetime;
• event-dependent/no fixed retention.

Example

Device diagnostics: retained locally until circular-buffer overwrite.
Cloud telemetry: retained for 30 days.
User-created media: retained according to the selected storage plan.

Do not invent a single retention number if multiple data categories/storage locations have different rules.

PROD_FEAT_94004: data accessibility for the user

This field should explain how users actually obtain the data.

Possible mechanisms:

• mobile app;
• account portal;
• API;
• direct-device interface;
• USB/file export;
• manufacturer support request;
• multiple mechanisms.

A useful answer includes:

• method;
• technical means;
• relevant URL or endpoint;
• retrieval/export format;
• erasure process where relevant.

Weak answer

User can access data.

Strong answer

Users can view product telemetry in the manufacturer's web portal and export historical measurements as CSV. Account holders can request deletion through the manufacturer's data portal.

The marketplace output should remain factual and reviewable.

PROD_FEAT_94005: additional EU Data Act information

This is the least self-explanatory field.

MediaMarktSaturn labels it as additional/further information under the EU Data Act.

A sensible use is information not cleanly represented in the prior fields, such as:

• technical means;
• terms of use;
• quality of service;
• important restrictions;
• related-service notes;
• manufacturer/data-holder contact;
• product-family exceptions.

Do not treat PROD_FEAT_94005 as a dumping ground for a full legal policy.

If a stable manufacturer page contains the full information, it may be cleaner to keep this field concise and use PROD_FEAT_94006 to point to the source.

PROD_FEAT_94006: link to manufacturer information

This field is strategically important.

MediaMarktSaturn tells sellers that if manufacturers provide the required information on their website, the seller can insert a stable link that leads specifically to the information.

A good URL looks like:

https://manufacturer.com/eu-data-act/smart-lock-x100

or:

https://manufacturer.com/legal/data-act/product-family-x

A weak URL looks like:

https://manufacturer.com/

or a generic privacy policy.

The link should take the user directly to information identifying the product or product family.

Why stable manufacturer links matter

A stable URL can be reused across:

• MediaMarktSaturn;
• Kaufland;
• distributors;
• dealer portals;
• product documentation;
• QR codes.

That is much more scalable than sending different static documents to each marketplace.

Does the manufacturer link replace the other fields?

MediaMarktSaturn's seller communication says sellers can enter the required information in the new PROD_FEAT fields or insert a reliable manufacturer link where the manufacturer provides the information.

However, exact implementation can depend on:

• product category;
• current marketplace validation;
• Mirakl attribute configuration;
• country/storefront;
• integration middleware.

Therefore, do not build a permanent technical assumption that:

PROD_FEAT_94006 always makes every other field optional.

For production feeds:

1. verify the current category attributes;
2. test a sample product;
3. inspect marketplace validation;
4. retain the structured source fields anyway.

The manufacturer link is an important distribution method, but the source facts remain valuable for other channels.

MediaMarktSaturn uses Mirakl: why that matters

The MediaMarktSaturn marketplace operates through Mirakl infrastructure.

Lengow's current integration documentation identifies the channel as:

MediaMarktSaturn (Mirakl)

Current integration reference:

MediaMarktSaturn (Mirakl) — Lengow Help Center

Product data and offer data are different concepts

Marketplace systems distinguish product catalogue information from seller offer information such as price and stock.

Data Act information belongs naturally with the product record, because the facts describe the connected product itself.

For a multi-market seller, the better architecture is:

PIM / product master
        ↓
Regulatory product attributes
        ↓
MediaMarktSaturn adapter
        ↓
Mirakl catalogue

Do not manage seven regulatory fields independently in an ecommerce spreadsheet if they can live in the product-data system.

Current live product-page evidence: what the fields look like in practice

Reviewing live MediaMarkt Spain pages provides useful implementation evidence.

EZVIZ connected cameras

Current EZVIZ camera pages show data categories including operational logs, activation records, detection events, user-operation logs, configuration data and media. The page also identifies product-specific formats and storage quantities.

Example:

EZVIZ H8c on MediaMarkt Spain

This demonstrates why PROD_FEAT_94000 needs more than a generic sentence.

Xiaomi smartwatches

Current Xiaomi watch pages include device/firmware telemetry, usage data, related-service/app data, format information, volume estimates, and notes on local storage and later synchronization.

Example:

Xiaomi Watch 2 on MediaMarkt Spain

Amazon Fire TV

Current Fire TV listings include Data Act information covering usage, content interaction, search and technical/device data, plus explanations of storage behavior.

Example:

Amazon Fire TV Stick HD on MediaMarkt Spain

Why these examples matter

They show that the output can be customer-facing and relatively detailed.

For sellers, a rushed one-line field can become poor product information.

For manufacturers, a good canonical source can improve consistency across every reseller.

Manufacturer vs. seller responsibility

Article 3(2) is a pre-contractual information obligation on the seller, rentor or lessor, which may be the manufacturer.

MediaMarktSaturn's marketplace structure also makes the individual marketplace seller the contracting party for third-party marketplace sales, while MediaMarktSaturn Plattform Services operates the marketplace.

Official MediaMarkt sources:

• MediaMarkt marketplace overview
• MediaMarkt Germany legal notice — Marketplace

Operationally:

Manufacturer

Usually knows:

• generated-data categories;
• technical format;
• estimated volume;
• storage architecture;
• retention;
• access mechanism;
• related services.

Marketplace seller

Usually owns:

• catalogue submission;
• marketplace product fields;
• listing publication;
• channel compliance workflow.

That makes the efficient handoff:

Manufacturer
   ↓
Canonical Product Data Notice / structured record
   ↓
Seller / marketplace manager
   ↓
MediaMarktSaturn attributes

not:

Seller guesses engineering facts

What if the seller is also the manufacturer?

Then the workflow is simpler.

The same organization can:

1. classify the product;
2. collect engineering facts;
3. create the Product Data Notice;
4. map fields into MediaMarktSaturn;
5. maintain the source as products change.

Private-label sellers should not assume they are “only ecommerce.” If they control the product design/technical record, they need a reliable internal source for these field values.

How to prepare PROD_FEAT_94000–94006 efficiently

Do not start with seven empty marketplace text boxes.

Start with one structured source model.

Source fields

Product identity
Data categories
Format
Estimated volume
Generation mode
Real-time status
Storage locations
Retention
Access/retrieval
Erasure
Technical means
Terms
Quality of service
Canonical manufacturer URL

Adapter output

Then generate:

PROD_FEAT_94000
PROD_FEAT_94001
PROD_FEAT_94002
PROD_FEAT_94003
PROD_FEAT_94004
PROD_FEAT_94005
PROD_FEAT_94006

This reduces:

• duplicated writing;
• conflicting values;
• stale marketplace descriptions;
• differences between retailer and manufacturer documentation.

That is the architecture RegCatalog is designed to support.

Example mapping from one source record

Consider a fictional smart environmental sensor.

Source record

Product: EnviroSense X100
Data:
- temperature
- humidity
- device status
Format:
- JSON
Estimated volume:
- 1–5 MB/month
Generation:
- readings every 5 minutes
- alarms in real time
Storage:
- 24-hour local rolling buffer
- 30 days remote
Access:
- customer portal + REST API
Erasure:
- account portal
Terms:
- manufacturer data-access terms
Canonical URL:
https://example.com/eu-data-act/x100

PROD_FEAT_94000

Temperature, humidity and device-status data in JSON; approximately 1–5 MB/month depending on device activity.

PROD_FEAT_94001

Periodic measurements every five minutes; alarm events can be generated in real time.

PROD_FEAT_94002

Data are stored in a local rolling buffer and on the manufacturer's remote service.

PROD_FEAT_94003

Local buffer: approximately 24 hours. Remote data: 30 days.

PROD_FEAT_94004

Users can access historical data in the customer portal and retrieve it via REST API.

PROD_FEAT_94005

Erasure is available through the account portal. Data-access terms and service details are available on the manufacturer page.

PROD_FEAT_94006

https://example.com/eu-data-act/x100

This example is illustrative only. Real values must come from the actual product.

Should a seller use the fields or the manufacturer URL?

The best answer depends on current marketplace rules and source quality.

Use the manufacturer link when:

• it is stable;
• it points directly to the relevant product;
• the information is complete;
• the manufacturer maintains it;
• the current category/integration accepts it.

Use structured fields when:

• marketplace validation requires them;
• your feed/PIM expects the attributes;
• the manufacturer supplied data but no stable page;
• your integration maps attributes centrally.

Best long-term approach

Maintain both:

• structured internal facts;
• canonical manufacturer URL.

Then each marketplace can consume whichever representation it supports.

Relevant product categories

MediaMarktSaturn's seller communication references a separate file listing relevant connected-product categories.

This means the seven fields are not expected for every item in the catalogue.

However, category lists are marketplace operational guidance, not the legal definition of a connected product.

Use both layers:

Marketplace layer

Is this category currently configured for MediaMarktSaturn Data Act attributes?

Legal/product layer

Does the actual item meet Article 2(5), and do the relevant Chapter II obligations apply?

For scope:

What Is a Connected Product Under the EU Data Act?

For size/exemption issues:

EU Data Act Article 7 SME Exemption

How Article 7 affects marketplace sellers

Article 7 contains a Chapter II carve-out for certain products manufactured/designed, or related services provided, by qualifying micro and small enterprises, subject to additional conditions.

It is not a generic exemption for every small marketplace seller.

Example:

• seller: 12 employees;
• product: connected camera from a multinational manufacturer.

The seller's small size does not make the multinational manufacturer's product a micro/small-enterprise product for Article 7.

Marketplace sellers should not use their own employee count as a shortcut for deciding whether the Data Act fields matter.

How MediaMarkt's implementation differs from Kaufland and bol

This comparison shows why normalized product data matters.

MediaMarktSaturn

Current model:

• seven structured product attributes;
• option for a stable manufacturer information link;
• customer-facing Data Act product-page section.

Kaufland

Current model:

• seller confirms Data Act status;
• seller supplies Smart Device Info URL;
• structured is_smart_device and manufacturer URL fields;
• CSV/XML/API support.

Guide:

Kaufland EU Data Act Requirements

bol

Current public model:

• seller uploads a product-information document;
• bol template or manufacturer document accepted;
• affected new electronics can be publication-gated;
• phased enforcement for missing content.

Guide:

bol EU Data Act Requirements

Same facts, three output models

Manufacturer product facts
          ↓
    Regulatory source record
      ┌────┼─────────┐
      ↓    ↓         ↓
MediaMarkt Kaufland  bol
fields     URL       PDF

That is why a manufacturer should not use the marketplace output as the original source of truth.

A practical MediaMarktSaturn workflow for sellers

Step 1 — identify affected products

Use:

• current marketplace categories;
• product technical characteristics;
• your compliance process.

Step 2 — obtain manufacturer information

Ask for:

• Product Data Notice;
• Data Act notice;
• Article 3 information;
• stable manufacturer URL.

Step 3 — validate the source

Check:

• product/model coverage;
• data types;
• formats;
• volume;
• real-time generation;
• storage;
• retention;
• access;
• technical means;
• terms/QoS.

Step 4 — choose marketplace representation

Depending on current category/integration:

• populate structured PROD_FEAT fields;
• provide the stable manufacturer link;
• or both where required.

Step 5 — submit through the marketplace integration

If using Mirakl/feed middleware:

• verify mapping;
• validate output;
• inspect rejection/error reports.

Step 6 — check the customer-facing page

Confirm the information appears under the Data Act section.

A successful feed import is not the final QA step.

Step 7 — retain source/version

Record:

EAN
Product
Manufacturer
Notice URL/document
Notice version/date
MediaMarkt field status
Last verified
Owner

A practical workflow for manufacturers

Step 1 — build a product-data inventory

For each connected product/family:

• product identity;
• SKU/GTIN;
• generated-data categories;
• data format;
• volume;
• generation;
• storage;
• retention;
• access.

Step 2 — create a canonical Product Data Notice

Use one reviewed manufacturer source.

Step 3 — publish a stable URL

Prefer a durable path such as:

manufacturer.com/eu-data-act/product-x

Step 4 — generate the seven MediaMarkt attributes

Transform the source record, not the other way around.

Step 5 — distribute to sellers

Provide:

• SKU/EAN;
• manufacturer link;
• field mapping;
• last updated date.

Step 6 — maintain change triggers

Review when:

• firmware changes;
• cloud architecture changes;
• retention changes;
• data access changes;
• a new model joins the family;
• marketplace schema changes.

Common MediaMarktSaturn EU Data Act mistakes

Mistake 1: stuffing everything into PROD_FEAT_94000

That field is for form/type/volume, not the entire notice.

Mistake 2: using a privacy policy as PROD_FEAT_94006

A GDPR privacy policy usually does not contain Article 3 product-data information.

Mistake 3: using a generic manufacturer homepage

The link should lead specifically to the required information.

Mistake 4: writing only “Yes” for storage

The underlying source should distinguish local and remote storage.

Mistake 5: giving one retention number for every dataset

Different categories can have different retention rules.

Mistake 6: treating real-time and continuous as identical

They can differ.

Mistake 7: forgetting technical means, terms and QoS

These belong in the source notice/additional-information layer.

Mistake 8: allowing marketplace copy to become the source of truth

Maintain a canonical manufacturer/product record.

Mistake 9: hard-coding PROD_FEAT_94000–94006 across several scripts

Keep them in one maintained marketplace adapter.

Mistake 10: assuming the fields can never change

MediaMarktSaturn continually updates marketplace attributes/categories. Treat this as external schema.

Mistake 11: assuming the manufacturer link always replaces all other fields

Verify current category/integration behavior.

Mistake 12: never checking the live product page

Customer-visible output is the actual end result.

Mistake 13: copying another seller's wording

Use manufacturer-verified product facts.

Mistake 14: assuming every Wi-Fi device is automatically in scope

Apply Article 2(5) and Article 7 where relevant.

Technical implementation for PIM and feed teams

If your organization manages many connected products, treat MediaMarktSaturn as an adapter.

Canonical model

product_id
gtin
data_categories[]
formats[]
volume_estimates[]
real_time
continuous
storage_profiles[]
retention[]
access_methods[]
erasure
technical_means
terms_url
quality_of_service
canonical_notice_url

MediaMarkt adapter

94000 ← type + format + volume
94001 ← real-time / continuous summary
94002 ← storage capability
94003 ← retention summary
94004 ← user access / retrieval
94005 ← additional Article 3 information
94006 ← manufacturer URL

Why adapters should be versioned

Store metadata such as:

marketplace: MediaMarktSaturn
source: MMS seller communication / integration documentation
last_verified: 2026-08-23
adapter_version: 1.0

When marketplace requirements change, update the adapter rather than rewriting every product manually.

MediaMarktSaturn EU Data Act checklist

Scope

• Product screened as a potential connected product.
• Current MediaMarktSaturn category requirements checked.
• Article 7 reviewed where relevant.
• Responsible owner identified.

Source data

• Product/model/GTIN clear.
• Data categories documented.
• Formats documented.
• Estimated volume documented.
• Real-time status documented.
• Continuous-generation status documented.
• Storage capability documented.
• Retention documented.
• Access/retrieval documented.
• Erasure documented where relevant.
• Technical means documented.
• Terms documented.
• Quality of service documented.

Marketplace mapping

• PROD_FEAT_94000 prepared.
• PROD_FEAT_94001 prepared.
• PROD_FEAT_94002 prepared.
• PROD_FEAT_94003 prepared.
• PROD_FEAT_94004 prepared.
• PROD_FEAT_94005 prepared.
• PROD_FEAT_94006 prepared where using manufacturer URL.
• Current attribute requirements re-verified.

QA

• Feed/import accepted.
• No Mirakl validation/rejection errors.
• Live product page checked.
• Data Act section visible where expected.
• Manufacturer URL resolves.
• Last-reviewed date stored.

Frequently asked questions

What are the MediaMarktSaturn EU Data Act attributes?

Current seller communication documents seven attributes: PROD_FEAT_94000 through PROD_FEAT_94006, covering data type/form/volume, real-time generation, storage, retention, user accessibility, additional information and manufacturer-information URL.

What is PROD_FEAT_94000?

It is the MediaMarktSaturn field for the form, type and volume of data generated by the connected product.

What is PROD_FEAT_94001?

It covers real-time data generation.

What is PROD_FEAT_94002?

It covers the capability of storing data.

What is PROD_FEAT_94003?

It covers the duration of data retention.

What is PROD_FEAT_94004?

It covers accessibility of the data to the user.

What is PROD_FEAT_94005?

It is the additional/further information field for EU Data Act information not captured cleanly by the other dedicated fields.

What is PROD_FEAT_94006?

It is the link to manufacturer information. MediaMarktSaturn says sellers can use a stable manufacturer link that leads specifically to the required information.

Can I use the manufacturer's Data Act page instead of filling all fields?

MediaMarktSaturn's seller communication says a stable manufacturer link can be used where the manufacturer provides the required information. Exact category/integration validation can vary, so verify current marketplace requirements rather than assuming the link always replaces every field.

Does the manufacturer URL have to be a MediaMarkt page?

No. The field is specifically intended for manufacturer information.

Can I use a privacy-policy URL?

Only if it genuinely contains the required product-specific Data Act information, which a generic privacy policy usually does not. A dedicated Product Data Notice/Data Act page is more appropriate.

Does MediaMarkt show Data Act information to customers?

Yes. Current MediaMarkt product pages include an "Information according to EU Data Act" section with structured product data for connected devices.

Does MediaMarktSaturn use Mirakl?

Yes. Current seller/integration documentation identifies MediaMarktSaturn as a Mirakl marketplace.

Are the seven fields mandatory for every MediaMarkt product?

No. MediaMarktSaturn's communication points to relevant connected-product categories. Current category-level marketplace requirements should be verified.

Can a seller use another seller's wording?

That is risky. Use manufacturer-verified product facts or an official manufacturer notice.

Are small marketplace sellers automatically exempt?

No. Article 7's carve-out depends on the manufacturer/designer/related-service provider and other conditions, not simply the seller's headcount.

Does every Wi-Fi device need these fields?

Not automatically. Apply the connected-product definition and current marketplace category rules.

Should manufacturers maintain a separate MediaMarkt document?

Not necessarily. A canonical Article 3/Product Data Notice source can be mapped into MediaMarkt's seven attributes and reused elsewhere.

Does RegCatalog submit directly to MediaMarktSaturn?

Not unless a future direct integration is explicitly implemented and tested. RegCatalog's initial role is to structure the manufacturer source record and generate marketplace-ready mappings.

How often should these attributes be reviewed?

Review them when generated data, format, volume, storage, retention, access method, firmware/cloud service or marketplace requirements materially change.

Why MediaMarktSaturn is an important model for RegCatalog

Kaufland demonstrates a URL/status model.

bol demonstrates a document-upload model.

MediaMarktSaturn demonstrates a field-level structured product-data model.

Together, the three marketplaces prove a broader operational problem:

one EU regulation can produce three different ecommerce representations of the same manufacturer facts.

The scalable solution is not to write three separate compliance documents.

It is:

One structured manufacturer record
        ↓
Product Data Notice
        ↓
MediaMarkt attributes
        ↓
Kaufland URL
        ↓
bol PDF
        ↓
Distributor / retailer outputs

That is the workflow RegCatalog is designed to make easier.

Useful next steps

• Generate a Product Data Notice
• Read the Article 3 Product Data Notice guide
• Check what counts as a connected product
• Understand the Article 7 SME exemption
• Read the Kaufland EU Data Act guide
• Read the bol EU Data Act guide

Primary sources and further reading

MediaMarktSaturn / marketplace implementation

1. MediaMarktSaturn EU Data Act — new attributes for connected products (Lengow)
2. MediaMarktSaturn (Mirakl) integration documentation — Lengow
3. MediaMarkt Germany — EU Data Act Information
4. MediaMarkt Germany — Marketplace
5. MediaMarkt Germany — Legal notice / Marketplace operator and seller role

Live MediaMarkt product-page examples

1. Xiaomi Watch 2 — MediaMarkt Spain
2. EZVIZ H8c connected camera — MediaMarkt Spain
3. Amazon Fire TV Stick HD — MediaMarkt Spain

EU Data Act

1. Regulation (EU) 2023/2854 — EU Data Act
2. European Commission — Data Act explained
3. European Commission — Data Act

_RegCatalog is an independent informational product-data tool. It is not affiliated with, sponsored by or endorsed by MediaMarktSaturn, MediaMarkt, Saturn, Mirakl or Lengow. RegCatalog does not provide legal advice or certification. Marketplace attributes, categories, validation rules and product-page presentation can change; verify current MediaMarktSaturn marketplace documentation before production submission._