A competitor's shelf price is information about a product offer, not about a person, so it falls outside the Article 4(1) definition of personal data. The GDPR still touches your price monitoring, because the pages you take prices from carry names, photographs, reviews and seller identities next to the number.
The clean position is simple: take the price and its identifiers, and drop everything capable of identifying a human being before it reaches storage. Most GDPR problems in price monitoring are storage problems, not collection problems.
What Article 4(1) actually says
Personal data is any information relating to an identified or identifiable natural person. Three parts to test: is it information, does it relate to a person, and is that person identifiable, directly or indirectly.
A figure of 14.90 euro for a 0.75 litre bottle at a named retailer fails the second test. It relates to an offer made by a company. No individual's rights are engaged by the number.
The definition is broad, though, and regulators read "relating to" widely: information can relate to a person by content, by purpose or by effect. A price set for one named customer relates to that customer. A price on a public shelf does not.
Where personal data turns up on a competitor's page anyway
The price is clean. The page around it usually is not:
- Marketplace seller names. A sole trader trading under their own name is a natural person, and their business address is their personal data.
- Imprint blocks. German sites publish a managing director's name by law, so the Impressum is a reliable source of personal data on every page that links to it.
- Reviews and questions. Usernames, first names, photographs and free text that can reveal health, religion or political opinion.
- Live chat widgets, which sometimes render an agent's first name and photograph straight into the HTML you saved.
- Author bylines on buying guides stored alongside the product page.
- Structured data blocks, which often repeat the review author inside JSON-LD even when the visible page hides it.
- Screenshots, which capture all of the above at once and are the easiest thing to forget.
"Publicly available" is not an exemption
The GDPR contains no general carve-out for data a person has published. Article 9(2)(e) lifts the prohibition on special-category data manifestly made public by the data subject, and that is a narrow provision about special categories, not a licence to process ordinary personal data freely.
Collecting a name from a public page is still processing. It needs a lawful basis, in practice legitimate interests under Article 6(1)(f), and it needs a balancing test written down before you start rather than drafted after someone complains.
Article 14 is the reason to drop it, not to keep it
Where you obtain personal data from a source other than the person, Article 14 obliges you to tell them who you are, what you took, why, on what basis, how long you will keep it and what rights they have. The deadline is one month, or your first communication with them, whichever comes first.
Now picture doing that for several thousand marketplace seller names you never wanted in the first place.
Article 14(5)(b) offers relief where notice would involve disproportionate effort, and supervisory authorities have read that narrowly. Do not build a programme on an exemption you would have to argue for. Build one where the obligation never arises.
A minimisation rule that ends the argument
Decide what a price record needs, and refuse everything else at the point of ingest rather than in a later cleanup job. A useful record is short:
- The source URL
- The timestamp of the fetch
- The competitor as an organisation, not a person
- The identifiers you matched on: GTIN, MPN, brand, title, pack size
- The price, the currency and the VAT treatment
- Stock status and delivery cost
- A content hash of the page, so you can prove what you saw without keeping what you saw
Storing a hash instead of the full HTML removes most of the exposure in one change. If you do keep raw pages for debugging, put a short retention on them. Seven to thirty days is usually enough to fix a parser, and stripping review and chat blocks before writing costs one function.
What you still have to write down
Even a minimal setup produces paperwork, and it is short paperwork:
- A record of processing entry that says what you collect and why
- A legitimate interests assessment covering the residual personal data you cannot avoid
- A retention schedule, including raw pages and screenshots
- A processor agreement under Article 28 with any scraping or proxy vendor
- A transfer mechanism if that vendor hosts outside the EEA
- A route for a seller who objects, and a person who owns answering them
Add one internal rule that prevents the breach that actually happens: names collected while monitoring prices must never reach the sales team. Scraped contact details used for outreach is where a price project turns into a marketing complaint.
Where price data genuinely becomes personal data
Two situations flip the answer, and both are worth checking before you assume you are outside scope.
First, personalised pricing. If a competitor shows a different price to an identified individual and you capture the price against that individual, you now hold information about how a person was treated. That is personal data whatever the number means.
Second, one-person businesses. Across much of Europe the sole trader is legally the same entity as the person. Their prices remain product data, but their name, address, VAT number and telephone are personal data, and the Article 14 duty attaches to the whole set you took.
Neither case makes competitor monitoring unlawful. Both change what you must keep, and both are cheaper to design around than to explain later.