← Back to home

Working with Encore under the GDPR

What we handle, what you handle, and the five things we need from you before your first EU user sees an offer.

Last updated: 18 August 2026

The short version

Encore shows your users a third-party offer at a moment you choose. That involves personal data — a pseudonymous identifier, a device model, a country — so both of us have obligations, and they are not the same obligations.

We have done our half: a data protection impact assessment, a documented lawful basis, enforced retention, and working access, erasure and portability across every store we hold. Your half is five steps, and only you can do them, because you own the relationship with your user and we do not.

Who is what

Offer serving

Joint controllers

We choose which offers exist and which are eligible; you choose when to ask. Article 26 applies and we each carry our own responsibilities.

Entitlement delivery

We are your processor

Where we grant a reward back into your app, we do it on your instruction to fulfil your promise. This applies to the churn-intervention use case — it is not part of every integration.

Your portal account

We are the controller

Your staff's names, emails and permissions are our own business relationship with you, not something we process on your behalf.

This matters practically: for offer serving you cannot simply point at us as a vendor. The arrangement has to say what each of us does, and your users have to be told we exist.

What we need from you

1

Sign the DPA and Article 26 arrangement

One document. The DPA covers the processor half, with the Standard Contractual Clauses and the UK Addendum for transfers to the United States. The Article 26 arrangement covers the joint-controller half and records who does what. It comes with your onboarding pack — you do not need to request it.

Your legal team · once

2

Add the disclosure to your privacy notice

Your users have to be told that a third party selects and delivers these offers, what it receives, and why. The text is below, ready to copy. Fill in your opt-out path before you publish. This step is what discharges Article 14 for your users — nothing we do on our side substitutes for it.

Your legal or web team · once, then keep current

3

Make your marketing opt-out cover third-party offers

This usually needs a product change rather than a policy change. Most publishers already let a user opt out of marketing; very few of those opt-outs currently cover an offer served through an embedded SDK. Where a user has objected, do not call the SDK for that user. That is how the objection is honoured, and it is the only way it can be.

Your product or engineering team · once

4

Tell us who uses your app

Declare whether the app is directed at children or likely to be accessed by them, and the youngest age band you expect. We enforce it: an advertiser only reaches your app if your youngest user is old enough for it, and an app declared child-directed is served nothing at all. You can always declare something stricter than we assessed; you cannot relax an assessment we made. Tell us before you move the SDK to a different surface.

Your product team · at onboarding, then whenever it changes

5

Send us only the data we use

Our SDK accepts around twenty optional attributes. We use two. Everything else — email, phone, name, date of birth — is accepted by the contract and read by nothing. If you operate outside the United States, do not send them. We would rather not hold what we cannot justify holding.

Your engineering team · at integration

Step 3 is the one that fails quietly

If your opt-out only governs your own email, a user can object, believe they have objected, and keep seeing offers — because nothing in the chain told us to stop. Neither of us would find out from our own systems. It is worth checking rather than assuming.

Everything you need to copy

Three things your teams can lift directly. If you would rather have them as a document, ask us and we will send the pack.

Privacy notice text — for step 2
Offers from Encore

When you decline a purchase in this app, or reach certain other points, we may show you an offer from a third party — for example a free trial, a discount or credit. These offers are selected and delivered by Peach Works, Inc, trading as Encore, which acts as a joint controller with us for this purpose.

What Encore receives. An identifier for you within this app, your device model, platform and app version, and your country, which Encore works out from your IP address at the moment of the request and does not store. Encore does not receive your name, email address or date of birth from us.

What Encore does with it. Encore uses the identifier to make sure you are not shown an offer you have already taken, to apply limits on free trials, and to confirm that you completed an offer so that we are paid correctly. Encore does not build a profile of you and does not use your personal data to choose which offer you see. Which offers are available depends on this app and the country you are in, not on you as an individual.

Why we are allowed to do this. Encore relies on its legitimate interests in operating the service and in preventing fraud (Article 6(1)(f) GDPR). You can ask for a copy of Encore's assessment of that balance.

How long. For as long as your account with us is active, plus 30 days. Analytics records are deleted after 25 months.

Your choices. You can object to being shown these offers at any time, and we will stop. Use [YOUR OPT-OUT PATH]. You can also ask us or Encore for a copy of your data, or ask for it to be deleted. Encore can be reached at privacy@encorekit.com.
SDK attributes we actually use — for step 5
// Encore uses exactly two optional attributes.
// Everything else the contract accepts is unused — do not send it.
Encore.showOffers({
  userId: yourInternalUserId,   // pseudonymous; we never resolve it to a person
  attributes: {
    countryCode: 'DE',          // used: geo eligibility
    language: 'de',             // used: creative locale
  },
});
Audience declaration — for step 4
App: <bundle id>
Directed at children:            yes / no
Likely to be accessed by under-16s: yes / no
Youngest audience age band:      all ages / 13+ / 18+ / 21+
Store age rating (Apple / Play): ...
Where the SDK is placed:         e.g. subscription-decline screen, settings, post-purchase

The privacy notice text contains one placeholder, [YOUR OPT-OUT PATH]. Replace it before publishing.

What we do on our side

Lawful basis

Legitimate interests (Art. 6(1)(f)) with a documented balancing test. We do not profile: offer ranking uses app-level aggregate statistics with no per-user input, so nothing evaluates or predicts anything about an individual.

Access, erasure, portability

Implemented end to end across PostgreSQL and BigQuery, with a request ledger and an identity-verification record. Where a record cannot be proven exhaustive, the response says so rather than staying silent.

Retention

Enforced by a scheduled job, not by policy: application data for the life of the account plus 30 days, analytics under a 25-month partition expiry.

Children

An audience age band per app and per advertiser, compared on every request and enforced in the database query rather than in campaign configuration — so no amount of campaign curation can bypass it.

Transfers

Data is held in the United States (GCP us-central1), under the Standard Contractual Clauses and the UK Addendum.

Security

Encrypted at rest and in transit; application-layer AES-256-GCM on stored platform credentials through a single audited access point; role-controlled admin access with an audit trail.

Our current subprocessors are listed on the subprocessors page.

Questions your legal team will ask

What personal data do you actually receive?

An identifier for the user within your app — either one you supply, or one our SDK generates and stores on the device if you supply none. Device model, platform and SDK version. An IP address, which we resolve to a country in memory and do not store. Plus countryCode and language if you send them.

Do you build a profile of our users?

No. The trigger is uniform — every user who reaches it enters the same flow. The identifier is used to avoid showing an offer already taken, to apply trial limits, and to confirm a completed offer so you are paid. It is never an input to which offer gets chosen.

What happens if one of our users makes a request directly to you?

We action it and tell you within five business days. Under Article 26(3) a user may exercise their rights against either of us, and we will not refuse a request on the basis that it was allocated to you.

How long does this take to put in place?

Steps 1, 2 and 4 are usually a single week. Step 3 depends on how your opt-out is built. Step 5 is a line in your SDK integration.

Getting started

Ask your Encore contact for the data protection pack, or write to privacy@encorekit.com. We will send the DPA and Article 26 arrangement, the notice text above as a document, and the audience declaration form.