PHPSESSIDcustomer sessionmage-cache-storageprivate-section cachemage-cache-sessidcustomer cache IDprivate_content_versionprivate-section versioningsection_data_idscustomer-section syncform_keycheckout CSRFX-Magento-Varyper-customer Varnish keying
A compliant Magento 2 shop
in 10 minutes, no theme edits.
Magento cookies (session, cart, form_key, mage-cache-storage) classified as necessary by default — checkout works without clicking the banner. Banner only asks about GA4 enhanced ecommerce, Meta Pixel, Google Ads.
What the banner doesn't ask about vs asks about
_ga, _ga_*GA4 enhanced ecommerce_gcl_*, IDEGoogle Ads + remarketing_fbp, frMeta Pixel_hjSessionUser_*Hotjar recordings_clck, _clskMicrosoft Clarityexternal_no_cache3rd-party modules when set by analytics
Download the module
Sign up at cjakciasteczko.pl, add your shop's domain, grab cjakciasteczko-magento.zip from the Integrations panel. ~10 KB.
Magento 2
v1.0.0CJakCiasteczko Magento 2 module. Shop cookies auto-necessary.
Drop into app/code/
Unzip into app/code/ — produces app/code/Aveneo/CJakCiasteczko/. Enable the module: bin/magento module:enable Aveneo_CJakCiasteczko, then setup:upgrade and cache:clean.
$ unzip cjakciasteczko-magento-1.0.0.zip -d app/code/$ bin/magento module:enable Aveneo_CJakCiasteczko$ bin/magento setup:upgrade$ bin/magento cache:cleanPaste the key in admin config
Stores → Configuration → aveneo → CJakCiasteczko. Paste the install key, Save Config. The module verifies once on save and shows the bound domain below.
Shop compliant
bin/magento cache:clean (Magento aggressively caches config). Open a product in incognito — banner. Accept → GA4 + Ads unblock via Consent Mode v2. Reject → cart and checkout work without analytics.
We use GA4 enhanced ecommerce to measure conversions. Without them the shop still works — cart and checkout are always available.
From a real Magento shop
“On Magento we had a custom banner from a developer for 8,000 PLN that broke on every update. CJakCiasteczko deployed by our DevOps in 15 minutes, works regardless of M2 version.”
Magento Open Source vs Adobe Commerce
The module works with both distributions. Adobe Commerce adds features (B2B, customer segmentation, page builder personalization) that affect the cookie footprint — the module classifies them appropriately.
Magento Open Source
- · Standard cookie set (session, cart, form_key)
- · Banner integrates with Magento's native GTM container
- · Works from 2.3.x upward (2.4.4+ recommended)
- · No Adobe license → composer or manual install
Adobe Commerce
- · Everything from Open Source PLUS:
- ·
_b2b_*— segmentation cookies (analytics) - · Page Builder personalization tags (marketing)
- · Sensei tracker (Adobe Sensei AI) — analytics
- · Extra surfaces require consent, banner handles them
Performance — why the module won't slow your shop
Magento aggressively caches via Varnish + Full Page Cache (FPC). The banner has to be cache-friendly or we'd break hit-rate on the first product page.
Single block, before="-"
The module registers ONE block in view/frontend/layout/default.xml with before="-" — rendered at the very start of <head>. The block doesn't hit the DB (reads scope-config that's already in memory), so it doesn't bust FPC.
Async script, zero render-blocking
<script async src="..."> loads in the background, doesn't block HTML parsing. CrUX / PageSpeed Insights see no impact on LCP / CLS.
No banner cookies set by Magento
Banner cookies are set by the visitor's browser via our CDN (cjakciasteczko.pl) — not via your origin. That means your shop's Cache-Control has nothing per-visitor to cache — FPC hit-rate stays at 100%.
FAQ — Magento 2
Multi-store / multi-website — different keys per shop?
Yes. The ApiKey backend model writes the key at scope level (default → website → store). In system.xml we set showInWebsite=1 + showInStore=1, so admins can set a different key per store_view. Each store has its own CJakCiasteczko domain with its own banner config.
How does it work with Adobe Commerce Cloud (managed Magento)?
Identically to self-host. The only difference: on Cloud you don't have CLI SSH access, so bin/magento module:enable happens via deploy from repo. Add our module to the project's composer.json, push, Cloud runs setup:upgrade in the build phase.
Headless / PWA Studio / Hyvä — does the banner work?
Yes, with a caveat. Headless frontends (Vue Storefront, PWA Studio, Hyvä SPA) don't use Magento's layout XML, so our default.xml block doesn't load. In those cases paste the 2-line snippet manually in the app shell or index.html of the headless front — first the inline window.CookieConsentConfig with the domain field, then the async script tag from our CDN.
GraphQL / REST API requests — does the module gate them?
No. The module only injects on frontend HTML pages (view/frontend/layout). API endpoints (GraphQL, REST V1) have no head to inject into. If you want to gate API requests for 3rd-party tags, use server-side GTM (sGTM) — different layer, independent of the banner.
bin/magento setup:upgrade error on activation?
Most common causes: (1) cache wasn't flushed before enable — run bin/magento cache:flush first; (2) deploy:mode=production requires di:compile after enable — add bin/magento setup:di:compile to the flow; (3) permissions on app/code/Aveneo/CJakCiasteczko/ — chmod -R 755 + chown www-data:www-data.
10 minutes to a GDPR-compliant Magento shop.
30 days free, no card. Works from Magento 2.3 + PHP 7.4.