Sell App Data Legally: GDPR Guide for UK Businesses

Plenty of companies look at the data their app collects and wonder whether it could become a second revenue line. It can, but the honest answer to how to sell app data in the UK or the EU is narrower than most people expect. Once the data relates to an identifiable person, UK GDPR and EU GDPR decide what you can do with it, and handing it to a third party for money is one of the hardest uses to justify.

This guide is for founders, product owners and CTOs who are building or running an app and want to earn money from its data without ending up in front of a regulator. It covers what counts as selling personal data, which legal bases can support it, the monetisation models that avoid selling personal data altogether, and the technical decisions that have to be made while the app is still being built. Most of the risk sits in those early decisions. Retrofitting consent and data minimisation into a live product is slow and expensive, and it usually means rebuilding parts of the backend.

Contents

What selling app data means under GDPR
The legal basis you need to sell app data
Ways to monetise app data without selling personal data
How to build data monetisation into your app from day one
What a compliant data layer costs to build

What selling app data means under GDPR

GDPR applies to personal data, meaning any information relating to a person who is identified or can be identified. In an app that covers the obvious fields, such as name, email address and phone number. It also covers device identifiers, advertising IDs, IP addresses, precise location and in-app behaviour linked to an account or a device.

For monetisation purposes it helps to split what your app holds into three groups:

Personal data. Anything linked to a person directly or through an identifier. Passing it to another company for its own use is a disclosure that needs a legal basis and has to be explained to users before it happens.
Pseudonymised data. Data where names and emails have been replaced by a key or a hash. It is still personal data if the people behind it can reasonably be re-identified, as Recital 26 of the GDPR makes clear.
Anonymised data. Data that can no longer be linked to anyone, by you or by the buyer. It falls outside GDPR, but the bar is high: a dataset of location traces is rarely anonymous even with every name removed, because a home and a workplace are enough to identify most people.

There is a fourth group to watch: special category data, which includes health, religion, sexual orientation and biometric data. It has its own stricter rules, and an app can reveal it without asking for it directly. If the app is about fertility, mental health or dating, the simple fact that someone uses it may already be sensitive.

The legal basis you need to sell app data

The GDPR lists six legal bases for processing personal data. When the plan is to sell app data to other companies for their own purposes, only one of them works reliably in practice: consent.

Legitimate interests is sometimes suggested as an alternative, but it depends on a balancing test that the sale of user data rarely passes. People do not expect an app they use to sell information about them, and that expectation weighs heavily against you. Performance of a contract does not help either, because selling data is not needed to deliver the service the user signed up for.

Consent only counts if it meets the conditions in Article 7 of the GDPR. In an app, that means:

It is asked for separately, not buried in the terms and conditions.
Each purpose is named, and the companies receiving the data are identified or at least described by category.
Saying no does not block access to features that do not need the data.
Withdrawing consent is as easy as giving it, ideally from the settings screen.
You can prove who consented, when, and to which version of the text.

In the UK the rules come from UK GDPR, the Data Protection Act 2018 and PECR, which requires consent before an app stores or reads information on the user’s device for non-essential purposes. That catches most advertising and tracking SDKs. The ICO’s UK GDPR guidance is the best starting point for UK companies.

Regulators have already shown how this goes wrong. The Norwegian data protection authority fined Grindr NOK 65 million, roughly €5.8 million, for sharing users’ location, advertising IDs and other details with advertising partners without valid consent, and the Court of Appeal upheld the fine in 2025. The court also agreed that using a dating app for gay and bisexual men is itself special category data. Under Article 83, the most serious infringements can be fined up to €20 million or 4% of worldwide annual turnover, whichever is higher; the UK equivalent is £17.5 million.

Ways to monetise app data without selling personal data

Selling user-level data is the highest-risk option and, for most apps, not the most profitable one. These models bring in revenue with far less exposure:

Aggregated insight reports. Trends built from large groups, for example footfall by day of the week across retail parks, with minimum group sizes so nobody can be singled out.
Anonymised datasets. Only after a documented anonymisation assessment that considers what the buyer could combine the data with.
Better pricing and products with first-party data. The data stays inside your company and supports decisions about your own service.
Processor partnerships. The partner provides a service to you under an Article 28 processing contract and cannot use the data for its own purposes.
Contextual advertising. Ads chosen from what is on the screen, not from a profile of the user.
Paid analytics for business customers. In B2B apps, dashboards that show customers insights from their own data are often easier to sell than any third-party dataset.

Model	Personal data leaves your company?	Usual legal basis	Risk
Selling user-level data	Yes	Consent	High
Behavioural ads through third-party SDKs	Yes	Consent, plus PECR in the UK	High
Aggregated insight reports	No, if group thresholds apply	Legitimate interests for the analysis	Low to medium
Anonymised datasets	No, if truly anonymous	None needed once anonymous	Medium: re-identification
Processor partnership	Shared under contract only	Same as the original purpose	Low
Contextual advertising	No	No profiling involved	Low

How to build data monetisation into your app from day one

Before you sell app data, or even plan to, the app has to be built so that consent, minimisation and deletion work at the level of each data field. These are the decisions to make during design, not after launch.

Map the data before anyone writes code

List every field the app will collect, why it is needed, where it is stored, who receives it and how long it is kept. This data map becomes the basis for the privacy notice, the consent screens and the store declarations, and it quickly shows which data you do not need at all.

Privacy by design and a DPIA

Article 25 requires data protection by design and by default. For monetisation projects that usually means collecting coarse location instead of precise location, keeping identifiers separate from behavioural data, and switching optional sharing off by default. If the plan involves profiling or large-scale location data, a data protection impact assessment under Article 35 is mandatory before processing starts.

A consent management platform inside the app should record each choice with a timestamp and the version of the text shown. Withdrawal must stop the flow of data to partners as well as inside your own systems, so the backend needs a way to pass that signal on, usually through an API call to each recipient.

Audit every SDK

Analytics, attribution and advertising SDKs often send identifiers and events by default. Review what each one transmits, switch off what you do not need and remove the rest. From a regulator’s point of view, whatever an SDK sends is a disclosure made by you.

Apple and Google requirements

On iOS, tracking users across other companies’ apps and websites requires the App Tracking Transparency prompt, and the App Store privacy details must describe the data the app collects and shares. Google Play asks for the same information in its Data safety section. If these declarations do not match what the app does, the stores can reject updates or remove the app.

User rights and retention

Users can ask to see their data, correct it, delete it or object to its use. Build internal tools that let the team handle these requests in minutes, including the copies held by partners, and set automatic deletion once the retention period ends.

What a compliant data layer costs to build

The cost depends less on the monetisation model than on how early privacy is designed in. A consent layer, a clean data model and SDK controls planned from the first sprint add a few weeks of work. Adding them to an app that is already live can mean rewriting the data layer and re-submitting to both stores.

Team location also matters. Development companies in Spain work under EU GDPR every day and are used to building consent flows and DPIAs into their projects, and their rates are usually well below those of London or US agencies for the same seniority. At Yeeply we match companies with certified development firms selected for each project, compare several proposals and supervise delivery. You can see how it works on our pages about mobile app development and hiring programmers.

If you are planning an app that will use its data commercially, have the data architecture reviewed before development starts. Click “Receive price estimate” at the top right of yeeply.com/en or write to sales@yeeply.com, tell us what the app collects and how you want to use it, and we will put you in touch with companies that have already built GDPR-compliant apps.

This article is general information and not legal advice. For a specific project, check your plans with a data protection specialist.