GDPR and cookie compliance for PrestaShop: what you actually need

Regulatory references (Consent Mode v2, CNIL enforcement) summarise the relevant rules; this is technical guidance for PrestaShop, not legal advice; check specifics with a data-protection adviser for your markets.

Here is the confusion that costs PrestaShop merchants the most: they install the official GDPR module, see "GDPR" in the title, tick the box, and assume they are covered. They are not, and not because the module is bad. It is because "GDPR compliance" and "cookie compliance" are two separate legal duties that happen to land on the same store, and PrestaShop's native tooling only addresses the first one. The GDPR module manages personal data (access requests, deletion, consent on forms). It does not show a cookie banner, it does not block a single tracking script, and it has no idea Google Consent Mode exists. So the most common compliant-looking PrestaShop store is half-compliant: tidy data handling, and a Google Analytics tag firing on page one before anyone clicked anything.

This guide is the PrestaShop-specific map of both duties: what the platform gives you out of the box, exactly where it stops, and what you have to add yourself. It is deliberately the overview that ties the two together. The deep legal reading of cookie consent (what counts as valid consent, dark patterns, banner mechanics) lives in cookie consent for PrestaShop: what the law actually requires, and the general "what you must do and what you can skip" checklist for any online store is in GDPR for online stores. This post stays on PrestaShop ground: back-office paths, the actual module, and what to wire up.

Two duties, one store: the distinction that catches everyone

Before touching a setting, get the legal geography right, because it decides which tool solves which problem.

So what? If you only solve one of these, an automated regulator scan still flags you. The cookie side is the one PrestaShop leaves entirely to you, and it is the one that triggers fines. The French regulator CNIL has made non-compliant cookie banners a standing enforcement priority, and its targets are not only household names. The GDPR side is mostly handled natively, as long as you actually configure it rather than just installing it.

What PrestaShop gives you natively for GDPR

PrestaShop provides an official GDPR module, technical name psgdpr, maintained by PrestaShop itself and available from the module catalog / Module Manager, you install and configure it rather than relying on it being there by default. It is genuinely useful, for data, not cookies. Find it under Modules → Module Manager, search "GDPR", install it, and configure from there. What it actually does:

• Data access export. A logged-in customer can request, straight from their account, an export (PDF or CSV) of their core account and order data plus data from compliant modules that integrate with psgdpr. That covers much of the Article 15 "right of access" without you building an export by hand, but it does not automatically include data held by third-party modules that do not integrate, so audit those separately.
• Right to be forgotten. Customers can request deletion; you action it from the module. So what? Instead of digging through Customers, Addresses and Orders to scrub one person, you get a single workflow, and a record that you honoured the request.
• Consent checkboxes on forms. The module can add and log consent on supported forms (such as registration, newsletter and contact) and on modules that integrate with it via its integration hooks. You write the text; it logs the agreement.
• A consent log. Each agreement is timestamped and stored, which is your proof when someone asks "did this person opt in?"

Alongside the module, PrestaShop exposes account-related controls at Shop Parameters → Customer Settings (the B2B toggle, "Ask for a birthdate", and partner-offer options), and it is here that psgdpr surfaces its consent text on the registration and account forms. The native settings do not log consent on their own. That is the module's job, but they shape what data the account flow collects in the first place. None of this is glamorous, but it is the part you do not have to buy or build.

How a module gets its data into the export, the four psgdpr hooks

The reason the export and deletion tools work cleanly is that compliant modules register with psgdpr and answer four hooks. This is worth seeing even if you never write a line of it, because it tells you what to look for when you audit a third-party module: if it stores customer data and does not implement these, that data is silently missing from every export you hand a customer. The four hooks, and what each does:

// In your module's install() – declare it to psgdpr and answer its hooks
public function install()
{
    return parent::install()
        && $this->registerHook('registerGDPRConsent')   // advertise a consent checkbox to psgdpr
        && $this->registerHook('actionExportGDPRData')   // return this customer's data for export
        && $this->registerHook('actionDeleteGDPRCustomer'); // erase this customer's data on request
}

// psgdpr asks every registered module for the customer's data (right of access / portability).
// Return the data as JSON – psgdpr merges it into the PDF/CSV export.
public function hookActionExportGDPRData($params)
{
    $idCustomer = (int) $params['id_customer'];
    $rows = Db::getInstance()->executeS(
        'SELECT message, date_add FROM `' . _DB_PREFIX_ . 'mymodule_log`
         WHERE id_customer = ' . $idCustomer
    );

    return json_encode($rows ?: []);
}

// psgdpr asks every registered module to erase the customer (right to be forgotten).
// Delete your rows and return json_encode(true) to confirm.
public function hookActionDeleteGDPRCustomer($params)
{
    if (!isset($params['id_customer'])) {
        return;
    }
    Db::getInstance()->execute(
        'DELETE FROM `' . _DB_PREFIX_ . 'mymodule_log`
         WHERE id_customer = ' . (int) $params['id_customer']
    );

    return json_encode(true);
}

The fourth hook, displayGDPRConsent, is the front-office counterpart to registerGDPRConsent: psgdpr calls it to render the consent checkbox your module advertised, in the place you asked for (a registration form, a newsletter block, a review form). So what for a merchant who doesn't code? You don't need to write this. You need to know it exists, so that when you evaluate a module that stores customer data, "does it implement the psgdpr hooks?" becomes a concrete question you can ask the developer. If the answer is no, that module's data won't appear in exports or be erased on a deletion request, and the gap is yours to close.

Where the native GDPR module stops, flatly

The single most important sentence in this article: the PrestaShop GDPR module does nothing about cookies. It does not display a cookie banner. It does not block, delay or gate a single analytics or marketing script. It is unaware of Google Consent Mode. Merchants conflate "GDPR module installed" with "cookie compliant" constantly, and that gap is precisely what regulators scan for. Everything in the next section is on you to add.

The cookie side PrestaShop leaves entirely to you

Cookies are governed by the ePrivacy Directive, a separate rule from GDPR, and PrestaShop ships no native mechanism for it. The legal detail of what makes consent valid, prior consent, granular categories, equal-prominence buttons, easy withdrawal, no dark patterns, is covered in depth in our cookie-consent law guide, so here we stay on the PrestaShop mechanics: where the leaks actually are in a PrestaShop install, and how to find them.

Where tracking scripts get injected in PrestaShop

On a typical store, the tags that need gating arrive through a handful of predictable routes. Knowing them turns "audit my cookies" from vague advice into a checklist:

• Modules hooking displayHeader / displayBeforeBodyClosingTag. Most analytics and pixel modules (and PrestaShop's own Google Analytics module, ps_googleanalytics) inject their JavaScript here, unconditionally, on every page. That is why the GA4 cookie often appears before the banner is even rendered.
• Theme template edits. Tags pasted directly into header.tpl or via a "raw HTML" module fire the instant the page loads, with no consent check at all.
• Server-side cookies. A client-side banner cannot stop a module that sets cookies in PHP through setcookie() or PrestaShop's Cookie class. These slip past most consent tools entirely.

To find what your own install is doing, two checks. First, the visitor's view: open the store in an incognito window, open DevTools → Application → Cookies before touching any banner. If you see _ga, _gid, _fbp or _gcl_au, scripts are firing without consent. Second, the code view: search your modules folder for server-side cookie setters,

grep -r "setcookie\|new Cookie" modules/ --include="*.php"

, and you will usually find one or two modules quietly setting cookies the banner never knew about. So what? A banner that records a "reject" while these keep running is not a shield; it is documented evidence that you knew and did nothing.

The four cookie categories on a PrestaShop store

When you map your cookies, they fall into four buckets. The essential column is the one PrestaShop itself populates and is exempt from consent:

Google Consent Mode v2, the part PrestaShop modules forget

Since March 2024, sites using Google Ads, remarketing or conversion-measurement features, or Google tags that feed those features, for EEA users should implement Consent Mode v2. It mainly applies to Google's advertising and measurement features for EEA/UK/Swiss users (Ads remarketing, personalization and conversion measurement) rather than every basic GA4 or Tag Manager deployment. It is a small JavaScript layer that tells Google tags whether the visitor consented, across four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization), all defaulting to denied until your banner says otherwise.

The mechanic is two gtag calls. The default block must run before any Google tag loads, setting everything to denied; the update block runs when the visitor accepts, flipping the categories they agreed to:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }

  // DEFAULT – must run before any Google tag loads. Deny everything up front.
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>

<!-- ...your banner runs, visitor clicks Accept on analytics + marketing... -->

<script>
  // UPDATE – fired by your banner's accept handler, only for the categories chosen.
  gtag('consent', 'update', {
    'ad_storage': 'granted',
    'ad_user_data': 'granted',
    'ad_personalization': 'granted',
    'analytics_storage': 'granted'
  });
</script>

One honest caveat: Consent Mode models the conversions you lose from visitors who decline, it estimates them statistically. It does not "recover" or recreate their real data, and it is not a substitute for prior blocking. The restricted, cookieless pings Google sends while consent is denied still have to be assessed for your situation rather than assumed fine. So what for a PrestaShop owner? Without Consent Mode you lose even the modelled read on declining visitors, because Google increasingly drops measurement from sites that send no consent signal at all. PrestaShop's stock Google Analytics module does not implement Consent Mode v2, so this is a gap you fill with a dedicated cookie module or a Google Tag Manager setup. The implementation specifics belong in the cookie-consent guide; the point here is simply that it is not handled for you.

The PrestaShop GDPR + cookie checklist, in order

Pulling both duties together, here is the sequence we recommend for a PrestaShop store, native tools first:

• 1. Install and configure psgdpr. Not just install, write the consent text, enable export and deletion, confirm the consent checkboxes appear on registration, newsletter and contact forms. This is your GDPR-data baseline, native and free.
• 2. Audit your cookies. Incognito + DevTools, list every cookie before consent, plus the grep for server-side setters. You cannot gate what you have not inventoried.
• 3. Add a cookie consent layer. PrestaShop ships none, so this is an add-on: a banner that genuinely blocks non-essential scripts until consent, with granular categories and equal-prominence accept/reject. The legal bar is detailed in the cookie-consent guide.
• 4. Wire up Consent Mode v2. Default all four signals to denied, update on the visitor's choice, so Google tags behave and you keep modelled data.
• 5. Keep demonstrable cookie-consent records. The psgdpr log covers form consent; cookie consent needs its own demonstrable record (timestamp, the choice made, the banner version and the method) as audit proof. Server-side logging is a robust way to do this, but the requirement is to be able to demonstrate consent. It can be implemented in different ways as long as it is adequate.
• 6. Publish a cookie policy page. A CMS page listing every cookie, its purpose, duration and the third party behind it, linked from the footer alongside a "Cookie settings" link that reopens the banner.
• 7. Re-audit after every module or theme change. A new module can quietly add a tracker; quarterly is a sane minimum.

Frequently asked questions

I installed psgdpr. Do I still need a cookie banner?

Yes. psgdpr handles personal-data rights, export, deletion, form consent logging, and does nothing about cookies. It shows no banner and blocks no script. The cookie/ePrivacy duty is separate and PrestaShop ships nothing native for it, so the consent layer is always an addition on top of psgdpr, never a replacement for it.

Does the official GDPR module make my store GDPR-compliant?

No module can do that. psgdpr provides the technical means to honour several data-subject rights, but compliance also depends on your privacy policy, your lawful bases, your retention periods, your processor contracts, and your cookie handling. All of which are your responsibility as the data controller. Treat the module as technical enablement for one part of the picture, and treat anything beyond that as a question for a data-protection adviser, not a setting.

Will Consent Mode v2 give me back the data from visitors who reject cookies?

Not their real data. Consent Mode models, statistically estimates, the conversions you'd otherwise lose, so your reports stay directional rather than going blank for declining visitors. It does not reconstruct individual journeys, and it is not a way around prior blocking: you still must stop non-essential cookies until the visitor opts in.

How do I know if a third-party module's data is included in a customer's export?

Check whether the module implements the psgdpr hooks, actionExportGDPRData and actionDeleteGDPRCustomer. If it stores customer data but doesn't answer those hooks, that data is silently absent from exports and won't be erased on a deletion request. Ask the developer directly, or grep the module's main PHP file for hookActionExportGDPRData. A module that stores reviews, wishlists or messages but skips these hooks is a gap you own.

Where in the back office do I action a deletion request?

From the psgdpr configuration page (Modules → Module Manager → configure psgdpr), not by editing the database. The module gives you a controlled delete/anonymize workflow and records that you honoured the request. Which is exactly the audit trail running raw SQL against the customer and orders tables would leave you without.

How this fits the rest of your store's legal duties

GDPR and cookies are one corner of running a compliant European store. Rather than cram everything here (the cannibalising trap that gets posts demoted), here is the map to the siblings that own each topic:

• The full picture of what EU law expects of an online shop: e-commerce law in the EU.
• The general GDPR checklist beyond PrestaShop specifics. What you must do and what you can skip: GDPR for online stores.
• The legal mechanics of a valid cookie banner: cookie consent for PrestaShop.
• What your store's legal pages must contain: terms and conditions for your store.
• And on the security side that GDPR also touches, protecting payment data: payment security in PrestaShop.

Where mypresta.rocks fits

The native psgdpr module covers your data obligations, and we would never sell you a replacement for something PrestaShop hands you free. The hole is the cookie side, script-blocking, granular categories, Consent Mode v2 and a banner light enough not to wreck your PageSpeed. Plenty of consent platforms solve it by loading 200–500KB of third-party JavaScript onto a store that is already heavy, trading a compliance problem for a speed problem. Our approach is the opposite: a lightweight Cookies Revolution / cookie-consent module that gates the scripts, signals Google correctly, and logs consent for audit, configured from the back office, without forking your theme. So what does that buy you? The technical half of the work PrestaShop leaves open, handled without a developer invoice and without slowing the store you spent so long making fast. It is technical enablement, not a compliance guarantee, the controller responsibilities above stay yours.

Cookie and GDPR compliance is not glamorous, and it does not lift conversions on its own. But on PrestaShop the danger is specific and avoidable: assuming the GDPR module covered cookies when it never touched them. Configure psgdpr properly, audit what is actually firing on your pages, and add the cookie layer the platform leaves out, and you move from compliant-looking to actually compliant, before an automated scan makes the decision for you.