What GDPR is and why e-commerce cares
The GDPR (General Data Protection Regulation) is a European Union regulation in force since 25 May 2018. It sets out the conditions under which a company may collect and process personal data, and what rights belong to the person whose data is processed.
For an online store this is not an abstract legal frame but a set of architectural requirements: where profiles are stored, who can access them, how tracking is switched on, and what happens when a customer asks for everything about them to be deleted.
One caveat: this material is written for product and marketing teams as an explanation of practice. It is not legal advice — the perimeter of applicability and the wording of policies and contracts are matters for a lawyer.
Key concepts
| Concept | What it means in practice |
|---|---|
| Lawful basis | Before collecting data you need to know why you may: consent, performance of a contract, legitimate interest |
| Consent | An explicit action by the user. A pre-ticked box, or “by continuing to use the site you agree”, is not consent |
| Data minimisation | Collect only what the stated purpose requires. “Let’s gather it just in case” is an anti-pattern |
| Purpose limitation | Data collected to deliver an order cannot be quietly reused for ad targeting |
| Retention period | Every category of data has a period after which it is deleted or anonymised |
| Right of access | A user can ask what data you hold about them and where it came from |
| Right to erasure | An erasure request is executed across every system, not only the main database |
| Right to portability | Data is handed over in a machine-readable format so the person can take it elsewhere |
| Controller / processor | The controller decides why data is processed; the processor does it on the controller’s instructions |
Sensitive data deserves separate mention — health, religious and political views, biometrics. For e-commerce this is a non-obvious trap: a pharmacy or intimate product category in the purchase history effectively turns the behavioural profile into sensitive data, and it has to be handled more strictly than a history of browsing home appliances.
Consent to analytics, consent to ad targeting and consent to marketing communications are three different consents. Merging them into a single “I agree to everything” checkbox is the most common practical mistake, and it damages opt-in rates as well: the user declines all of it at once.
GDPR alongside the other privacy regimes
GDPR is the reference point, but it is not the only frame a growing retailer meets. The table below generalises how teams usually organise the work rather than listing legal obligations.
| Aspect | GDPR (EU) | Other regimes (CCPA/CPRA, UK GDPR, LGPD, localisation laws) |
|---|---|---|
| Main focus | Grounds for processing and the rights of the data subject | Often disclosure and the right to opt out of a “sale” of data, plus notification duties |
| Where data is stored | Rules on cross-border transfer, but not on geography as such | Some regimes require the database on citizens to sit on local servers |
| Consent | Explicit, revocable, separated by purpose | From explicit opt-in to an opt-out model, depending on the jurisdiction |
| User rights | Access, rectification, erasure, portability, objection | Usually access and deletion, with portability less universal |
| Regulator | The supervisory authority of each EU member state | A national or state-level authority |
What teams do in practice when they work across several markets:
- Separate the data perimeters. Where a localisation rule applies, that market’s data sits on local infrastructure and the rest is kept separately. The shared part is the consent model and the register of processing purposes.
- Write one register of processing. A table of “what data, from where, for what purpose, where it lives, how long it is kept, who receives it”. The same table becomes the basis for answering a user request.
- Make the strictest regime the default. Maintaining two fundamentally different tracking logics costs more than building consent management once and switching it on everywhere.
- Fix processor relationships in contracts. The personalization platform, the ESP, hosting, analytics are all processors, and the scope of data passed to each is described explicitly.
What this means for a CDP and for personalization
Personalization runs on the user profile, which makes the CDP the central point where all the regulatory requirements converge.
Consent management. Consent is an attribute of the profile, not a line in a legal team’s spreadsheet. The profile needs a machine-readable state: which purposes the user agreed to, when, from which source (a CMP banner, a checkbox in a form, the account area), and which version of the text they were shown. Personalization mechanics read that state before they run.
Auditing data sources. For every profile attribute it pays to know the origin: did it come from an order, a form, behavioural tracking or an external upload? Attributes of unknown origin are the first candidates for deletion, because the lawfulness of processing them cannot be demonstrated.
Executing an erasure request. This is an engineering task, not a support email:
Erasure request ->
single customer ID (see deduplication)
-> CRM / orders (what can be deleted, what must be retained under tax and trade law)
-> CDP: profile, attributes, segment membership
-> behavioural events and the affinity profile
-> recommendation engine: interaction history
-> analytics and BI marts
-> exports into ad platforms and the ESP
-> backups: rotation period and a rule against reuse
-> confirmation to the user
Without a single customer identifier that route cannot be completed: one person’s data is spread across systems under different keys. This is why customer deduplication is not only about segment quality but about the ability to execute an erasure request at all.
The shift to first-party. Restrictions on the third-party cookie and frameworks such as ATT in the mobile environment are pushing the industry towards first-party data and zero-party data — what the user told you in a quiz, a subscription or their account. That data is easier to explain to the user and easier to defend.
A checklist for the product team
- Register of processing. Build the table “data -> purpose -> lawful basis -> system -> retention -> recipients”. Without it, every other item rests on what individual employees happen to remember.
- Separate consents. At least three independent switches: analytics, ad targeting, marketing communications. Declining one must not break the others.
- Consent as a profile attribute. The consent state is available to every system through an API, not stored only in a browser cookie.
- One-step withdrawal. Unsubscribing and withdrawing consent must be no harder than giving it.
- A retention period per category. Behavioural events usually live far less long than order history. Data with no assigned period is kept forever — and that is the risk.
- A rehearsed erasure run. Once a quarter, run an end-to-end erasure request on a test customer and check every system in the data flow map.
- Processor contracts. For every external service it is documented which data it receives and why.
- A segment review. Confirm that the segments you have built do not use attributes you have no consent to process.
A practical way to test data maturity: ask the team to answer, within one working day, “what data do we hold on customer X, and in which systems?” If the answer takes weeks, an erasure request will not be executed correctly either.