GDPR & Cookie Consent
Integrate Pixel Plus with your store's cookie consent banner so the Facebook pixel only fires after a visitor has explicitly agreed to tracking.
Available since v2.3
Overview
If your store operates under GDPR or similar privacy regulations, you need to hold the Facebook pixel back until a visitor actively accepts cookies. Pixel Plus has a built-in consent integration that handles this without relying on a third-party blocker to strip script tags from your pages.
The integration works by telling Pixel Plus exactly how your consent banner signals acceptance. On every page load, the module checks for that signal — either a cookie (the most common approach) or a localStorage variable (used by some modern consent platforms). If the signal is present and valid, pixel events fire normally. If not, all browser events are paused.
Internal vs external cookies
Cookie consent modules typically store the visitor's choice in one of two places:
- Internal cookie — the consent flag is written inside the PrestaShop cookie object. PrestaShop encrypts this cookie in the browser, so its contents are not directly readable in DevTools. Pixel Plus can still read it server-side (PrestaShop decrypts the cookie automatically), and the panel includes a tool to display its contents in a readable format (see Cookie inspector tool).
- External cookie — the consent flag is written as a separate, standalone cookie by the consent module or a third-party banner. It is plainly visible in DevTools > Application > Cookies. Most third-party consent platforms (Axeptio, Didomi, Cookiebot, etc.) use external cookies.
The Is an External Cookie? switch tells Pixel Plus which of the two it should look in.
The key advantage over external blockers is reliability. Modules that block Pixel Plus by removing script tags can accidentally strip JavaScript needed for other features, break the Back Office panel, and prevent the Conversion API from functioning even for staff. The built-in integration leaves all module code in place and simply pauses the event queue in the visitor's browser.
The browser pixel is what this panel controls. The server-side Conversion API is not automatically blocked here — consult your legal counsel if your compliance requirements include blocking CAPI as well.
Configuration
Cookie-based consent (most common)
- Go to Modules > Module Manager > Pixel Plus for Facebook > Configure.
- Locate the GDPR & Cookies Consent panel.
- Enable Block the script?.
- Set GDPR Block Mode to Cookies.
- Open your storefront in a private/incognito window and accept cookies. Open browser DevTools (F12) > Application > Cookies and find the cookie your consent banner sets.
- Enter its exact name in Add the cookie name to look for (names are case-sensitive — copy-paste from DevTools).
- Enter the value that signals marketing acceptance in Specific Cookie Value?. This field is the key to the whole configuration. In most cases the consent cookie holds a JSON object with one entry per cookie category — copy the fragment that says marketing was accepted, for example
"marketing":"true". Pixel Plus will then check whether that exact fragment appears anywhere inside the cookie value. Leave blank only if the cookie's mere presence already means "all categories accepted". - If the cookie is stored as a standalone browser cookie (visible in DevTools), set Is an External Cookie? to External. If the consent flag lives inside the PrestaShop cookie object instead, leave it disabled (Internal). Most third-party banners use external cookies; PrestaShop's native CMS-driven consent modules typically use internal ones.
- If your banner reloads the page after the visitor accepts, leave Page reloads after the consent? enabled (the default) — no selector is needed because the next page load picks up the new cookie automatically. If your banner activates without a reload, disable this option and enter a CSS selector for the consent dialog buttons in Selector for the Cookies Button. Use a selector that matches all the buttons on the banner (accept, reject, customise, save preferences) rather than just the accept button. That way any choice the visitor makes triggers Pixel Plus to re-check the consent state, keeping the module perfectly in sync with the banner — events fire the moment marketing consent is granted, and stay blocked otherwise.
- Click Save.
- Test in incognito: the pixel should not fire before consent and should fire (or resume after reload) once you accept.
localStorage-based consent
- Follow steps 1–4 above, but set GDPR Block Mode to Local Storage.
- In browser DevTools > Application > Local Storage, find the variable your consent platform writes.
- Enter the path to the consent value in Variable path to look for. Use
>>as a separator for nested objects — for example, if localStorage contains aconsentobject with amarketingproperty, enterconsent >> marketing. - Enter the exact value that signals acceptance (for example
true) in Expected Value/s. - Click Save and test as above.
Configuration fields reference
| Field | Values | Default | Description |
|---|---|---|---|
| Block the script? | Enabled / Disabled | Disabled | Master switch. When enabled, all browser pixel events are paused until the configured consent signal is detected. |
| GDPR Block Mode | Cookies / Local Storage | Cookies | Which mechanism your consent banner uses to record consent. If you are unsure, start with Cookies. |
| Add the cookie name to look for | Text | — | Exact name of the consent cookie (case-sensitive). Required when Block Mode is Cookies. |
| Specific Cookie Value? | Text | — | The fragment the cookie must contain to be treated as marketing consent given. Typically a JSON pair like "marketing":"true". Separate multiple accepted fragments with ` |
| Is an External Cookie? | Internal / External | Internal | Internal: the consent flag is inside the encrypted PrestaShop cookie object. External: the consent flag is a separate, plain browser cookie (most third-party banners). |
| Variable path to look for | Text | — | Path to the consent flag in localStorage, using >> for nested keys. Required when Block Mode is Local Storage. |
| Expected Value/s | Text | — | The value that signals consent has been granted (for example true). Required when Block Mode is Local Storage. |
| Page reloads after the consent? | Enabled / Disabled | Enabled | Enable if your consent banner reloads the page when the visitor accepts — Pixel Plus then picks up the new cookie automatically on the next load and no selector is needed. Disable if the banner activates without reloading, then provide the button selector below. |
| Selector for the Cookies Button | CSS selector | — | Only required when the page does not reload after consent. Ideally a CSS selector that matches every button in the consent dialog (accept, reject, customise, save preferences) — for example .consent-banner button. Matching all buttons lets Pixel Plus re-check the consent state on any visitor choice, keeping it perfectly synchronised with the banner. |
If you enable Block the script? but leave the cookie name (or localStorage path) blank, Pixel Plus will block all pixel events for every visitor. The Back Office will display a warning until you finish the configuration or disable the feature.
How It Works
On every page load, the module reads the configured consent signal from the visitor's browser:
- Cookie mode: The module checks whether the named cookie exists (via the PrestaShop cookie object for internal cookies, or directly from
$_COOKIEfor external ones). If a specific value was configured, the cookie content must contain that value. Multiple values separated by|||are checked one by one — a match on any of them grants consent. - localStorage mode: Because localStorage is not readable on the server, the module injects a small JavaScript snippet that reads the configured variable path and, if the expected value is found, calls back to your store to set a server-side session cookie (
fctp_localstorage_consent). On the next page load, the server reads that session cookie to determine consent.
When consent is detected, pixel events fire normally. When it is not detected, all browser-side pixel events are suppressed.
After the visitor accepts
Page reloads (standard flow): After the visitor clicks the consent banner's accept button, the page reloads. On the fresh load, the module finds the consent cookie and fires all events for that page normally.
No page reload: When Page reloads after the consent? is disabled, the module attaches a click listener to the CSS selector you specify. When that element is clicked, pixelConsent(true) is called: it calls fbq('consent', 'grant') immediately to activate the Facebook pixel in the visitor's browser session, and makes an AJAX call to update the server-side consent state so subsequent server-side checks are consistent.
The doNotConsentToPixel JavaScript variable
Setting window.doNotConsentToPixel = true in your own JavaScript will block all pixel events regardless of the cookie or localStorage state. This is useful for custom integrations — for example, if you manage consent through your own code and want direct control over when events fire.
Cookie inspector tool
The PrestaShop cookie object is encrypted in the visitor's browser — if you open DevTools, all you see is an opaque hash, so you cannot tell which keys and values it contains. To work around this, Pixel Plus includes a built-in inspector: a "click here" link next to the Is an External Cookie? field generates a short-lived security token and fetches the storefront cookie contents in a decrypted, readable format (excluding sensitive session fields like id_customer, passwd, session_token, etc.).
Use the inspector when your consent module writes its flag inside the internal PrestaShop cookie. The decrypted view shows you the exact key/value pair the module uses, which you then copy verbatim into Specific Cookie Value? (typically the JSON fragment that records marketing acceptance, e.g. "marketing":"true"). Without this tool, configuring an internal-cookie consent integration would require reading the module's source code or guessing.
For external cookies the tool is rarely needed — those are visible directly in DevTools > Application > Cookies.
Usage Examples
Example: Axeptio consent banner
Axeptio sets an external cookie named axeptio_cookies containing a JSON string with the accepted categories. Set Add the cookie name to look for to axeptio_cookies, set Is an External Cookie? to External, and enter "Facebook Pixel":true (or whatever fragment Axeptio writes when marketing tracking is accepted — open DevTools to confirm the exact spelling) in Specific Cookie Value?. Axeptio reloads the page after acceptance by default, so leave Page reloads after the consent? enabled.
Example: Custom banner without a page reload
Your designer built a custom consent overlay with Accept all, Reject all, and Customise buttons that update the consent cookie without triggering a page reload. Disable Page reloads after the consent? and set Selector for the Cookies Button to a selector that matches every button in the overlay — for example #consent-overlay button. Pixel Plus attaches a click listener to all of them and re-checks the consent state on each click. If the visitor accepts marketing, events fire immediately; if they reject or change their mind, the pixel stays paused — perfectly in sync with the banner.
Example: Internal cookie set by a PrestaShop consent module
Your store uses a PrestaShop consent module that writes the visitor's choice into the encrypted PrestaShop cookie object. You cannot see what's inside from DevTools. Click the click here link next to Is an External Cookie? to inspect the decrypted cookie contents in the Back Office. You spot a key like "consent_marketing":"1". Copy that fragment verbatim into Specific Cookie Value?, leave Is an External Cookie? set to Internal, and save.
Example: Multiple accepted values in one cookie
Your consent cookie can hold either "marketing":"true" or, for legacy visitors, "adv":"1". Enter "marketing":"true"|||"adv":"1" in Specific Cookie Value?. The module grants consent if any one of the fragments is present in the cookie value.
Example: localStorage with Didomi
Didomi stores consent in a didomi_token localStorage variable. Set GDPR Block Mode to Local Storage, Variable path to look for to didomi_token >> user >> status >> consent >> analytics >> enabled, and Expected Value/s to true. Pixel Plus reads this path on each page load and activates the pixel once the value resolves to true.
Important Notes
- CAPI is not blocked by this panel. The Conversion API fires from your server and is unaffected by the browser consent settings here. If your legal requirements include blocking CAPI, a custom implementation is needed.
- No server-side consent memory. The module re-reads the consent signal on every page load. It does not store a long-term "this visitor has consented" record on the server beyond the current session. If the consent cookie expires, the next page load will block the pixel again.
- Configuration is per-shop. In multi-shop setups, each shop can have its own consent cookie name, mode, and related fields. There is no global override for the GDPR settings.
- Misconfigured blocking blocks everyone. If Block the script? is on but the cookie name (or localStorage path) is empty, every visitor is blocked. The Back Office shows a warning — resolve it before the site goes live.
- Multiple pixel IDs. If you run multiple pixel IDs (via the multi-pixel feature), the consent state applies to all of them equally. You cannot consent to one pixel while blocking another through this panel.
- External cookie lookup. When Is an External Cookie? is enabled, the module reads from the raw browser
$_COOKIEsuperglobal. The value comparison is URL-decoded — both the raw value and its URL-encoded form are checked to handle banners that encode special characters.
Troubleshooting
| Problem | Solution |
|---|---|
| Pixel fires before consent is given | Confirm Block the script? is saved as enabled. Check the cookie name is exact — copy-paste from DevTools (Application > Cookies). Cookie names are case-sensitive. |
| Pixel never fires after accepting | Use the cookie inspector link in the GDPR panel to print all active storefront cookies. Verify the name and value match exactly what you have entered. Also confirm whether the cookie is internal (PrestaShop) or external. |
| All visitors are blocked after enabling | The Cookie name field is blank or incorrect. The Back Office warning confirms this. Temporarily disable Block the script?, fix the cookie name, then re-enable. |
| Pixel fires on acceptance but not on the next page | The consent cookie expires before the visitor navigates to the next page. Check the cookie's expiry in DevTools > Application > Cookies. This is a consent banner configuration issue, not a Pixel Plus issue. |
| localStorage mode works on the first page but not on subsequent ones | The fctp_localstorage_consent session cookie that Pixel Plus sets may be expiring with the browser session. This is expected — localStorage consent is re-validated on each new browser session. |
| No-reload mode: pixel doesn't activate after clicking accept | Verify your CSS selector targets the correct element. Open DevTools and run document.querySelector('.your-selector') in the console to confirm it finds the button. |
Does configuring this panel make my store fully GDPR-compliant?
The module provides the technical mechanism to block the pixel until consent is detected. Full GDPR compliance also depends on your consent banner's design, how consent is recorded and renewed, and your privacy policy. Consult your legal counsel for a complete compliance review.
Why shouldn't I just use a third-party module that blocks Pixel Plus entirely?
External blockers that remove Pixel Plus script tags from the page can interfere with Back Office features and break the Conversion API — which fires from your server regardless of browser scripts. The built-in consent integration pauses only the browser event queue and leaves everything else intact, making it both more reliable and less likely to cause side effects.
Does blocking the browser pixel also block the Conversion API?
No. CAPI fires from your server based on order and customer events and is unaffected by the browser consent panel. If your legal requirements include blocking CAPI for visitors who decline cookies, that requires a separate server-side implementation.
What does the doNotConsentToPixel JavaScript variable do exactly?
Setting window.doNotConsentToPixel = true in your own JavaScript suppresses all browser pixel events, regardless of the cookie or localStorage state configured in the Back Office. It is an escape hatch for custom integrations where you need to manage consent logic outside of Pixel Plus.
What is the cookie inspector tool and when should I use it?
When Is an External Cookie? is enabled, a link appears next to the field that generates a short-lived security token and prints your storefront's active cookies directly in the Back Office (excluding sensitive session fields). Use it when you do not know the exact name or value of the cookie your consent banner sets — it saves you from switching between the Back Office and DevTools.
Can I require multiple cookie values — for example, consent to both analytics and marketing?
The ||| separator in Specific Cookie Value? matches any of the listed values, not all of them. For an AND condition (all values must be present), you would need to use a single combined value that your consent banner writes, or handle the logic through the doNotConsentToPixel JavaScript variable in your theme.
My consent banner supports the IAB TCF standard. Does Pixel Plus integrate with that?
Pixel Plus does not have a built-in TCF integration. You can bridge it by configuring your TCF-compatible banner to write a standard cookie or localStorage variable when consent is granted, then pointing Pixel Plus at that signal.