PHPSESSIDsesja klientamage-cache-storagecache prywatnych sekcjimage-cache-sessidID cache klientaprivate_content_versionwersjonowanie sekcji prywatnychsection_data_idscustomer-section syncform_keyCSRF na checkoutieX-Magento-Varyvarnish keying per klient
Zgodny sklep Magento 2
w 10 minut, bez edycji szablonu.
Cookies Magento (sesja, koszyk, form_key, mage-cache-storage) domyślnie sklasyfikowane jako niezbędne — checkout działa bez kliknięcia w banner. Banner pyta tylko o GA4 enhanced ecommerce, Meta Pixel, Google Ads.
Co banner NIE pyta, a co pyta
_ga, _ga_*GA4 enhanced ecommerce_gcl_*, IDEGoogle Ads + remarketing_fbp, frMeta Pixel_hjSessionUser_*Hotjar nagrania_clck, _clskMicrosoft Clarityexternal_no_cachemoduły 3rd-party gdy ustawione przez analitykę
Pobierz moduł
Załóż konto na cjakciasteczko.pl, dodaj domenę sklepu, w panelu Integracje pobierz cjakciasteczko-magento.zip. Plik ~10 KB.
Magento 2
v1.0.0Moduł Magento 2 dla CJakCiasteczko. Cookies sklepu auto-niezbędne.
Wgraj do app/code/
Rozpakuj zip do app/code/ — powstanie app/code/Aveneo/CJakCiasteczko/. Włącz moduł: bin/magento module:enable Aveneo_CJakCiasteczko, potem setup:upgrade i 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:cleanWklej klucz w admin config
Stores → Configuration → aveneo → CJakCiasteczko. Wklej klucz instalacyjny, Save Config. Moduł zweryfikuje raz przy zapisie i pokaże powiązaną domenę poniżej.
Sklep zgodny
bin/magento cache:clean (Magento agresywnie cachuje config). Otwórz produkt w incognito — banner. Akceptuj → GA4 + Ads odblokowują się przez Consent Mode v2. Odrzuć → koszyk i checkout działają bez analityki.
Używamy GA4 enhanced ecommerce do mierzenia konwersji. Bez nich sklep też działa — koszyk i checkout zawsze są dostępne.
U realnego sklepu Magento
„W Magento mieliśmy custom banner od dewelopera za 8 tysięcy złotych który psuł się przy każdym update. CJakCiasteczko wgrane przez naszego DevOpsa w 15 minut, działa niezależnie od wersji M2."
Magento Open Source vs Adobe Commerce
Moduł działa z obiema dystrybucjami. Adobe Commerce dorzuca kilka funkcjonalności (B2B, customer segmentation, page builder personalization) które wpływają na cookie footprint — moduł sklasyfikuje je odpowiednio.
Magento Open Source
- · Standardowy zestaw cookies (sesja, koszyk, form_key)
- · Banner integruje się z natywnym GTM container Magento
- · Działa od 2.3.x wzwyż (rekomendowane 2.4.4+)
- · Brak licencji Adobe → instalacja przez composer/manual
Adobe Commerce
- · Wszystko z Open Source PLUS:
- ·
_b2b_*— segmentation cookies (analytics) - · Page Builder personalization tags (marketing)
- · Sensei tracker (Adobe Sensei AI) — analytics
- · Dodatkowe powierzchnie wymagają zgody, banner je obsłuży
Wydajność — czemu moduł nie spowolni sklepu
Magento agresywnie cachuje przez Varnish + Full Page Cache (FPC). Banner musi być cache-friendly, inaczej zerwiemy hit-rate na pierwszej stronie produktu.
Single block, before="-"
Moduł rejestruje JEDEN block w view/frontend/layout/default.xml z atrybutem before="-" — render na samym początku <head>. Block nie wykonuje DB query (czyta config z scope-config który już jest w pamięci), więc nie rozbija FPC.
Async script, 0 render-blocking
Tag <script async src="..."> ładuje się w tle, nie blokuje parse'owania HTML. CrUX / PageSpeed Insights nie widzą wpływu na LCP / CLS.
Brak cookies wstrzykniętych przez Magento
Cookies dla bannera ustawia visitor's browser z naszego CDN-a (cjakciasteczko.pl) — nie z Twojego origin. To znaczy że Cache-Control Twojego sklepu nie ma niczego do cachowania per-visitor — FPC hit-rate stays at 100%.
FAQ — Magento 2
Multi-store / multi-website — różne klucze per sklep?
Tak. Backend model ApiKey zapisuje klucz na poziomie scope (default → website → store). W system.xml ustawiliśmy showInWebsite=1 + showInStore=1, więc admin może mieć inny klucz dla każdego store_view. Każdy store ma swoją domenę CJakCiasteczko z własną konfiguracją bannera.
Jak działa z Adobe Commerce Cloud (managed Magento)?
Identycznie jak self-host. Jedyna różnica: na Cloud nie masz SSH dostępu do CLI, więc bin/magento module:enable robi się przez deploy z repo. Dodaj nasz moduł do composer.json projektu, push, Cloud sam zrobi setup:upgrade w build phase.
Headless / PWA Studio / Hyvä — czy banner zadziała?
Tak, ale jest pułapka. Headless frontend (Vue Storefront, PWA Studio, Hyvä SPA) nie używa Magento layout XML, więc nasz default.xml block się nie wczyta. W tych przypadkach wstaw 2-line snippet ręcznie w app shell albo index.html headless frontu — najpierw inline window.CookieConsentConfig z polem domain, dopiero potem async script tag z naszym CDN.
GraphQL / REST API requesty — czy moduł je gateuje?
Nie. Moduł wstrzykuje skrypt tylko na frontend HTML pages (view/frontend/layout). API endpoints (GraphQL, REST V1) nie mają head'a do wstrzyknięcia. Jeśli chcesz zgateować API requesty na 3rd-party tagi, użyj server-side GTM (sGTM) — to inna warstwa, niezależna od bannera.
bin/magento setup:upgrade błąd przy aktywacji?
Najczęstsze przyczyny: (1) cache nie został wyczyszczony przed enable — odpal bin/magento cache:flush najpierw; (2) deploy:mode=production wymaga di:compile po enable — dodaj bin/magento setup:di:compile do flow; (3) rights na app/code/Aveneo/CJakCiasteczko/ — chmod -R 755 + chown www-data:www-data.
10 minut do RODO-zgodnego sklepu Magento.
30 dni za darmo, bez karty. Działa od Magento 2.3 + PHP 7.4.