A familiar connected-product demo ends at the same visual beat: the device appears in the app, the status light turns green, and the user taps “connected.” That proves a pairing event. It does not explain what data the product creates, where that data goes, who can access it, or how the user can retrieve, share, or—where relevant—erase it.
For brands that sell connected appliances, wearables, robotics, vehicle accessories, or industrial equipment in Europe, that missing part is becoming harder to treat as back-end detail. The EU Data Act makes access to data generated through the use of connected products a visible part of the product relationship.
The regulation does not prescribe a particular video format, and a video cannot replace compliant product design, pre-contract information, contracts, data-access mechanisms, or legal analysis. The production conclusion is ONCE’s: when user control over product data becomes part of the product promise, a “successful pairing” montage is no longer sufficient evidence for sales, support, channel, and compliance teams.
The dates matter—and they describe different obligations
The European Commission says the Data Act entered into force on 11 January 2024 and has applied since 12 September 2025. Article 50 of Regulation (EU) 2023/2854 adds a more specific date: the obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026.
Article 3(1) requires connected products and related services to be designed so that product data and related-service data, including metadata needed to interpret and use them, are accessible by default in an easy, secure, free, comprehensive, structured, commonly used, and machine-readable format. Direct access is required where relevant and technically feasible.
The same article lists information that must be provided before a connected product is purchased, rented, or leased: the type, format, and estimated volume of data the product can generate; whether generation is continuous or real-time; whether data is stored on the device or remotely and for how long; and how a user can access, retrieve, or, where relevant, erase it. Providers of related services have parallel information duties covering the nature, estimated volume, collection frequency, storage, and access arrangements for data they expect to obtain.
Scope is just as important as the headline. The Commission’s Data Act explained says Chapter II covers raw and pre-processed data generated by use of a connected product or related service that is readily available to the data holder, including relevant metadata. Highly enriched inferred or derived data and content are outside that description. Personal data remains subject to the GDPR and other data-protection rules. “All device data must be public” is not an accurate summary.
Why the classic pairing demo is incomplete
Most connected-product films treat connection as the finish line: a phone detects the device, a control panel appears, and the user walks away satisfied. The sequence is visually efficient, but it cuts out the decisions most likely to create trust or support costs later.
A sensor reading may be live product data, a cloud-derived output, or a preloaded demonstration. A “share” icon may represent a specific permission flow—or merely an illustrative animation. A history chart may look useful without showing whether the user can retrieve a usable file. The more realistic the interface looks, the more readily viewers will interpret it as actual product behavior.
Generative tools can help with mood, storyboards, and clearly identified conceptual layers. They should not invent buttons, values, or workflows that will be presented as product evidence. A factual demo still needs a controlled account, safe test data, a known product version, and real screen capture.
ONCE’s four-scene data journey
Instead of trying to compress “data transparency” into a disclaimer, map each material data journey across four scenes: generate, access, share, and exit. Not every consumer-facing video needs all four scenes, but every promoted data feature should have all four answers in the production record.
Scene 1: Generate
Show the action or condition that creates the data. Is the device measuring temperature, energy use, position, motion, or a user instruction? Preserve the input condition, device state, and relevant version—rather than keeping only an attractive number changing on screen.
The evidence sheet should name the data, the trigger, its frequency or real-time status, offline behavior, and whether the demonstration uses test data. The objective is not to expose every engineering detail. It is to prevent a sample animation from being edited into an implied sensor test.
Scene 2: Access
Who can see the data, and where? The path may run through a device display, mobile app, web account, or downloadable machine-readable file. A screen recording should keep enough context to identify the entry point, permission state, and operation sequence—not only the final dashboard.
If the path changes by account tier, market, firmware, or service version, those variables belong in the slate and delivery record. A single ideal account should not become a universal training asset by accident.
Scene 3: Share
Sharing is not a cloud icon drifting across the frame. The production team should distinguish the manufacturer, the related-service provider, a third party chosen by the user, and any visual used only as a conceptual explanation. When sharing is shown, the script or visual context should identify who initiates it, who receives it, what permission is granted, and how it can be withdrawn. “Works seamlessly with every platform” should not survive review without product evidence.
Scene 4: Exit
Exit does not always mean showing a “delete everything” command. The accurate question is what the user can do under the specific product and contractual setup: access, retrieve, export, stop sharing, or erase data where relevant. Where does each action happen, and how is completion confirmed?
If a capability is not yet released, exists only in certain markets, or requires a manual request, keep that condition visible. A qualified path will usually age better than an unconditional green tick.
When a production day should capture the data journey
Not every fifteen-second ad should become a setup tutorial. Use six questions at the brief stage:
- Does use of the product generate device or service data that a user is likely to care about?
- Does a material feature depend on an app, account, cloud service, or third party?
- Does the data path vary by market, permission, firmware, or subscription state?
- Could access, export, sharing, or erasure change a purchase, installation, or support decision?
- Will the product be placed on the EU market after 12 September 2026?
- Will engineering samples, test accounts, back-end configurations, or technical staff be difficult to reconvene after the shoot?
When several product-truth questions are “yes” and recapturing the setup will be expensive, capture the real device state, essential screen paths, permission changes, and failure branches while the engineering environment is available. The consumer ad may use only a few seconds. Product pages, sales demonstrations, help-center videos, and support content can draw on the deeper sequence.
This changes the objective of the shoot. The team is not trying to make one film longer; it is creating verified building blocks that can support different depths of explanation.
Price the verified path, not only the finished video
For connected products, hidden production costs often sit outside the studio: account provisioning, firmware freezes, screen capture, product review, legal language, localization, and version maintenance. A per-video quote tends to push this work into a vague “revisions” bucket.
A more useful internal measure is:
Cost per verified data path = product and legal preparation + device filming and screen capture + path verification + localization + version maintenance, divided by the number of data paths that have passed product, legal, and market checks and remain usable.
This is not an industry benchmark, and different paths will not cost the same. It changes the procurement question: how many true, reusable data journeys did the project create for advertising, commerce, sales, training, and support? When firmware changes, can the team replace one recorded module, or must it rebuild an entire film?
For a production partner, the margin opportunity shifts as well. Value can come from pathway design, version records, cross-functional approval, and update governance—not only shoot days. A team that can maintain these assets is closer to a long-term connected-product content partner than a supplier of isolated films.
Before the next shoot, walk one real path end to end
The smallest useful step is not to reshoot the entire library. Choose one connected SKU headed for Europe and ask product, engineering, marketing, support, and qualified legal counsel to walk a single generate–access–share–exit journey. Put each real entry point, limitation, owner, and version into the production brief. Then decide what belongs in an ad, a product page, a help center, or an internal verification record.
The Data Act does not turn a product video into legal proof. Its more durable production lesson is that the brand story of a connected product can no longer stop when the pairing succeeds. The user needs to understand what happens to the data after connection—and where control returns to them.
Primary sources: European Commission, “Data Act”, updated 2 July 2026; European Commission, “Data Act explained”; Regulation (EU) 2023/2854, Articles 3 and 50. This article is not legal advice. Applicability should be assessed for the product, company size, contractual role, market, and data type by qualified counsel.
