Offerwalls and GDPR: Consent, User IDs and Privacy

This guide is general information, not legal advice. Check the rules that apply to your business, and ask a privacy lawyer when in doubt.

How do offerwalls fit with the GDPR?

When an EU or UK user opens an offerwall on your site, personal data flows between you, the offerwall, and your server: a user ID, the user’s IP address and device details, and the offers they complete. To handle that well, use a pseudonymous user ID in the wall link, never an email or name; tell users in your privacy policy that an offerwall partner receives that ID and the information their browser sends when the wall opens; get consent where your own cookies or trackers need it; store only the postback fields you need; have a process for deletion requests; and keep the wall away from children.

None of this is complicated, and most of it is good practice anyway: less data means less risk, fewer questions, and an easier publisher review.

Who is responsible for what

Under the GDPR, a controller decides why and how personal data is processed. On a typical offerwall setup there are two:

• You, the publisher, control your user accounts, the rewards you give, your payouts, and your own privacy notice.
• The offerwall provider processes data about the users who open its wall: which offers they see and complete, and checks for fraud.

Sharklio’s Privacy Policy describes this split. Sharklio decides independently how offer activity is recorded, attributed, and checked for fraud, so it acts as a controller for that processing. The publisher is responsible for its own privacy notice, including telling users that the offerwall is provided by Sharklio and obtaining any consent their jurisdiction requires before their data reaches it. Other providers may describe their role differently, so read each partner’s policy and terms.

What data moves when a user opens the wall

On Sharklio specifically, the privacy policy lists what is processed about end users: the pseudonymous identifier the publisher assigns, the publisher and property they came from, their IP address and approximate location, device, browser, and language characteristics, a device identifier used for fraud prevention, the offers they view, start, and complete, any proof they submit, completion and reversal status with timestamps, and click identifiers exchanged with offer partners. Advertisers see a separate pseudonymous ID that cannot be traced back to yours, and they do not receive names or contact details from Sharklio. Sharklio asks publishers not to send names, email addresses, or other direct identifiers, and the wall does not ask users for them.

Use a pseudonymous user ID, never an email

The wall link carries the ID of the user in your system. Use a random ID that never changes for the same person, such as a UUID or a random string stored on the account. Do not use:

• An email address. It identifies the person directly, and links end up in browser history, logs, and screenshots.
• A username users chose. Many people reuse usernames across sites.
• A sequential database ID if you can avoid it, because it reveals how many users you have and is easy to guess.

A pseudonymous ID is still personal data. GDPR Recital 26 says pseudonymised data that could be attributed to a person by using additional information should be treated as information on an identifiable person. The point of a random ID is not to escape the GDPR, it is to share as little as possible with each party.

Two more rules: never reuse a deleted user’s ID for a new account, because late reversals would hit the wrong person, and keep personal data out of sub IDs too. Sub IDs are for things like the placement, such as sub1=header, not for emails.

What to say in your privacy policy

Your privacy notice should tell users, in plain words, that the offerwall exists, who provides it, what it receives, and why. Sharklio checks that a publisher’s privacy notice covers the data that reaches it when users open the wall, as part of the publisher review.

Also cover your own side: what you store from postbacks, such as the offer name, reward, country, and IP address, why you store it, for example to credit rewards and prevent fraud, and how long you keep it. List the offerwall provider wherever your policy lists recipients or partners, and keep the list current when you add or remove a wall.

Cookies, consent banners, and the wall

In the EU, storing or reading information on a user’s device, such as cookies or local storage, generally needs consent under Article 5(3) of the ePrivacy Directive. There are narrow exceptions, including storage that is strictly necessary to provide a service the user explicitly asked for. The UK has similar rules.

For an offerwall, that means:

• Your own trackers on the Earn page, such as analytics or ad pixels, follow your normal consent banner. Do not load them before consent just because the wall is on the page.
• The wall itself. Sharklio’s privacy policy says that inside a publisher property, the offerwall may use browser storage that is strictly necessary to attribute completions and prevent duplicate or fraudulent activity. Describe it as part of the offerwall in your notice. Other providers may use different technologies, so check their documentation.
• Advertiser pages. When a user opens an offer, they go to the advertiser’s site or app, which sets its own cookies under its own policy. Say so in your notice.

Whether your setup needs additional consent before the wall loads depends on your partners and your jurisdiction. If you are unsure, ask your provider what it stores and get advice.

Data minimisation: keep less, for less time

Article 5 of the GDPR requires personal data to be limited to what is necessary for its purpose, and kept in identifiable form no longer than necessary. For a publisher, that translates into a few concrete habits:

• Choose your postback fields. On Sharklio you pick the macros in your postback URL, from the list in the docs. If you do not use the IP address or the device for fraud checks, do not request them.
• Set a retention period for postback logs and fraud data, and delete or anonymise older records. Keep payout and accounting records as long as the law requires.
• Limit access. Support staff need the offer name, status, and date for a ticket, not every IP address a user ever used.
• Be honest about fraud signals. IP addresses and device signals used against duplicate accounts are personal data too. Stop multi-accounting and VPN abuse covers how to use them proportionately.

Handling deletion and access requests

Users can ask you to access, correct, or delete their data. Under Article 12, you generally answer without undue delay and within one month, which can be extended by two further months for complex or numerous requests, as long as you tell the user within the first month. A workable process:

1. Verify the request comes from the account holder, for example from their signed-in session.
2. Delete or anonymise the account, the balance history, and postback logs linked to it, except records you must keep by law, such as payout records for accounting. The right to erasure has exceptions like this.
3. Handle late postbacks. A reversal or a delayed credit can still arrive for that user ID. Answer it with a 2xx status and ignore it, so it is not retried, and never assign the ID to someone else.
4. Point the user to the offerwall for the data it holds. Sharklio’s privacy policy asks end users to write to [email protected] with the name of the publisher and, if possible, their user identifier there, which the wall shows to the user as “Your ID” in its History view.

Note that questions about a reward balance or payouts belong with you, the publisher, because you credit and pay your users.

Children and age limits

Offerwalls are built for adults and older teens, not children. Two rules overlap here:

• The GDPR. Under Article 8, where consent is the legal basis for an online service offered directly to a child, the child must be at least 16, or parental consent is needed. EU countries may lower that age, but not below 13.
• The offerwall’s terms. Sharklio’s offerwall is not intended for anyone under 16, and publishers must not show it to them, whatever the local age of consent.

In practice: ask for a date of birth or an age confirmation at sign-up, hide the Earn page from accounts below the limit, and keep the wall out of products aimed at children. Google Play’s Families policy, for example, does not allow offerwalls in apps that target children. The US rules and the app store policies are covered in Offerwall COPPA rules: kids’ apps and app stores.

Offerwall privacy checklist

• The wall link uses a random, permanent user ID, never an email or a name.
• Sub IDs contain no personal data.
• Your privacy notice names the offerwall provider, what it receives, why, and links to its policy.
• Your own trackers on the Earn page respect the consent banner.
• You request only the postback fields you use, and you have a retention period for them.
• You have a process for deletion requests that also handles late postbacks.
• Users under 16 cannot reach the wall.

Frequently asked questions