Technische verdieping
Je Shopify-winkel plaatst waarschijnlijk cookies vóór toestemming. Zo bewijs je het in vijf minuten.
Zet Shopify's cookiebanner aan. Open het tabblad Network (Netwerk) in een privévenster. Tel de verzoeken die afgaan vóór je eerste klik. Bij heel wat winkels is dat aantal niet nul — en juist naar dat gat kijken toezichthouders.
Hier is een test die je nu meteen kunt uitvoeren, op je eigen winkel, zonder enig ander hulpmiddel dan je browser:
- Open je storefront in een vers privé-/incognitovenster.
- Voordat je iets op de cookiebanner aanklikt, open je DevTools en kijk je naar de cookies die er al staan en de netwerkverzoeken die al vertrokken zijn.
- Klik nu op Weigeren. Kijk wat er verdwijnt — en wat er alsnog blijft afgaan.
Als je dit nog nooit hebt gedaan, is het resultaat vaak verrassend. Niet omdat Shopify iets verkeerd doet — dat is niet zo — maar door de kloof tussen wat je in de admin geconfigureerd hebt en wat de browser bij het laden van de pagina daadwerkelijk doet.
De blinde vlek: wat je verklaart ≠ wat de browser doet
Er zijn twee heel verschillende dingen, en bijna iedereen haalt ze door elkaar.
De verklaring. In je Shopify-admin schakel je de toestemmingsbanner in, vink je de vakjes aan en koppel je de Customer Privacy API. Op papier is alles in orde.
Het gedrag. Wat een echte browser doet wanneer een echte bezoeker je pagina laadt: welke cookies naar schijf worden geschreven, welke pixels afgaan, welke domeinen van derden worden gecontacteerd — en cruciaal, wanneer, ten opzichte van de toestemmingsklik.
De verklaring leeft in je admin. Het gedrag leeft in de browser van de bezoeker. Een toezichthouder die een site controleert leest jouw admininstellingen niet — hij opent de pagina, kijkt naar het netwerk en leest de cookiejar. De browser is de bron van waarheid. Dit is niet specifiek voor Shopify; het geldt voor elke webstack. Maar de standaardinstellingen, thema's en het app-ecosysteem van Shopify maken het makkelijk om die kloof over het hoofd te zien.
Eerst een disclaimer: ik ben geen jurist, en niets hiervan is juridisch advies of een nalevingsoordeel. Het gaat hier om wat technisch waarneembaar is in je browser. Wat dat betekent voor jouw specifieke situatie is een vraag voor een gekwalificeerd adviseur.
Een typische storefront-load, op een tijdlijn
De vijf echte technische oorzaken
1. Shopify's eigen cookies, en de grijze zone tussen "noodzakelijk en analytics"
Shopify schrijft min of meer bij het laden een set first-party cookies: _shopify_y, _shopify_s, _y, _s, plus winkelwagen- en sessiecookies zoals cart, _secure_session_id, _shopify_essential. Sommige zijn echt noodzakelijk — een winkelwagencookie zorgt dat de winkelwagen werkt. Andere hebben een analytics-karakter (de _y/_s-familie voedt Shopify's storefront-analytics). Het label "strikt noodzakelijk" doet hier veel werk, en waar de grens precies ligt is omstreden. De praktische conclusie: ga er niet vanuit dat elke Shopify-cookie in het bakje "geen toestemming nodig" valt alleen omdat Shopify ze geplaatst heeft.
2. De Customer Privacy API meldt toestemming — maar dwingt die niet vanzelf af
Shopify's Customer Privacy API (window.Shopify.customerPrivacy) is een goede, echte tool. Hij stelt de toestemmingsstatus van de bezoeker beschikbaar — analyticsProcessingAllowed(), marketingAllowed() — en activeert een visitorConsentCollected-event wanneer de bezoeker beslist. Maar een signaal beschikbaar stellen is niet hetzelfde als blokkeren. Het is aan elk script, thema en app om dat signaal te lezen en zichzelf eraan te conformeren. Een pixel die customerPrivacy nooit controleert, gaat hoe dan ook af. De API geeft je de toestemmingsstatus op een presenteerblaadje; of je code er daadwerkelijk op wacht is een aparte vraag.
3. Pixels hard ingebakken bij het laden door oudere scripts of apps
Dit is de klassieker. Een Meta- (Facebook-)pixel, een TikTok-pixel of een Google-tag is twee jaar geleden rechtstreeks in theme.liquid geplakt, of geïnstalleerd door een app die hem op elke pagina injecteert. Hij draait in <head>, onmiddellijk, voordat de banner überhaupt is weergegeven. Shopify's moderne Customer Events / web pixels sandbox bestaat juist om deze door de toestemmingslaag te leiden — maar een oude, hard ingebakken tag omzeilt dat allemaal. Hij weet niet eens dat de banner bestaat.
4. Een weigering die niet volledig wordt doorgevoerd
Hier zijn twee faalwijzen. Ten eerste: cookies die al vóór de beslissing waren geschreven, worden niet verwijderd wanneer de bezoeker weigert — ze blijven gewoon staan. Ten tweede: een script leest de toestemmingsstatus één keer, vroeg, slaat "nog geen beslissing" op in de cache en gaat alsnog af omdat het nooit opnieuw controleert nadat de bezoeker op Weigeren klikt. De banner zegt "geweigerd". Het netwerk zegt iets anders.
5. Bronnen van derden buiten het bereik van de banner
Ingesloten YouTube-video's (youtube.com), Google Fonts opgehaald van Google's CDN, een chatwidget, een reviewwidget, een ingesloten kaart — elk hiervan kan bij het laden cookies plaatsen of een server van derden contacteren, en veel toestemmingsbanners dekken ze helemaal niet omdat het geen "tags" zijn, maar ingesloten content. Ze zitten in een blinde vlek van henzelf.
Wat je waarneemt vs wat je geconfigureerd hebt
De doe-het-zelf-audit van vijf minuten
Dit is het deel dat een bladwijzer waard is. Geen tooling, geen extensie, geen account. Alleen de DevTools van je browser en de eerste keer een kwartier, daarna elke keer vijf minuten. De stappen zijn geschreven voor Chrome; Firefox en Safari zijn vrijwel identiek.
- Open een schoon privévenster Gebruik Incognito (Ctrl/⌘ + Shift + N). Een schoon profiel betekent geen achtergebleven cookies die het resultaat vertekenen. Laad je winkel nog niet.
- Open eerst DevTools Druk op F12 (of ⌘ + Opt + I). Ga naar het tabblad Network (Netwerk). Vink Preserve log en Disable cache aan. Open het voordat je de pagina laadt, zodat je de allereerste verzoeken opvangt.
- Laad je storefront — en stop. Niet klikken. Laat de pagina tot rust komen. Raak de banner niet aan. Dit is scenario één: vóór enige toestemming.
- Lees de cookiejar Ga naar Application ▸ Storage ▸ Cookies (Firefox: Storage ▸ Cookies) en kies je domein. Maak een lijst van alles wat er al staat. Elk van deze is gezet voordat je iets besloot.
-
Lees het netwerk
Terug in Network, filter op domein. Typ
facebook, dantiktok, dangoogle-analytics,googletagmanager,doubleclick,youtube. Elke treffer betekent dat een derde partij is gecontacteerd vóór toestemming. Noteer ze. - Scenario twee: klik op "Weigeren" Weiger nu. Open daarna opnieuw het Cookies-paneel. Zijn de vooraf gezette cookies verdwenen? Vaak niet. Controleer de netwerkfilters opnieuw — gaan pixels nog steeds af na de weigering? Noteer het verschil.
- Scenario drie: vers venster, klik op "Accepteren" Sluit alles, open een nieuw incognitovenster, herlaad en accepteer dit keer. Dit is je referentie voor "wat er afgaat met volledige toestemming" — handig om te zien wat in scenario één en twee gegate had moeten zijn.
Sorteer in het tabblad Network op de kolom Time/Waterfall en zoek het verzoek dat door je toestemmingsklik werd geactiveerd. Alles erboven dat een domein van derden laadde, gebeurde vóór toestemming. Die ene weergave vertelt het hele verhaal.
Cookies die je doorgaans zult zien, en wanneer ze landen
Namen en levensduur verschillen per thema en Shopify-versie, dus behandel dit als een veldgids, niet als evangelie. De categorieën zijn breed gebruikte conventies, geen juridische classificaties.
| Cookie | Doorgaans gezet | Gebruikelijk doel |
|---|---|---|
_shopify_y / _y | bij het laden | Storefront-analytics, ~1 jaar |
_shopify_s / _s | bij het laden | Analytics-sessie, ~30 min |
_shopify_sa_p / _shopify_sa_t | bij het laden | Marketing- / attributie-analytics |
cart, cart_sig, cart_ts | functioneel | De winkelwagen zelf |
_secure_session_id | functioneel | Checkout / sessie |
_tracking_consent, _cmp_a | toestemming | Slaat de toestemmingsbeslissing zelf op |
_fbp | bij het laden* | Meta Pixel — zou op toestemming moeten wachten |
_ga, _gid | bij het laden* | Google Analytics — zou op toestemming moeten wachten |
* _fbp, _ga en aanverwanten zijn degene om kritisch te bekijken: als ze in scenario één verschijnen (vóór elke klik), is dat precies het gat waar dit artikel over gaat.
Wat eraan te doen — zonder te dramatiseren
Niets hiervan is een groot alarm. Het is een configuratie- en hygiëneprobleem, en het is op te lossen. Realistische stappen, ongeveer op volgorde van impact:
- Controleer je apps. Elke marketing-/analytics-app is een potentiële pixelinjector. Verwijder wat je niet gebruikt — verwijderen haalt meestal ook de tag weg. Minder apps, minder verrassingen.
- Verplaats pixels naar Shopify's Customer Events. Tags die via de web pixels sandbox worden toegevoegd, zijn gekoppeld aan de toestemmingslaag in plaats van rauw te draaien in
theme.liquid. Als je hard ingebakken pixels hebt, is het migreren ervan de fix met de allergrootste impact. - Zorg dat weigeren ook echt verwijdert. Wanneer een bezoeker weigert, moeten de eerder gezette cookies worden gewist, niet blijven staan. Controleer het in scenario twee.
- Gate ingesloten content van derden. Laad YouTube via de privacyverbeterde modus (
youtube-nocookie.com), host fonts zelf, en laad widgets waar mogelijk pas na toestemming. - Voer de audit opnieuw uit na elke thema-update of app-installatie. De blinde vlek duikt weer op zodra iets nieuws een tag injecteert. Vijf minuten, elk kwartaal.
Blokkeert Shopify's toestemmingsbanner tracking uit zichzelf?
Niet vanzelf. Hij verzamelt en stelt de toestemmingsbeslissing beschikbaar via de Customer Privacy API. Of een bepaald script die beslissing respecteert, hangt af van hoe dat script werd geïntegreerd — via Customer Events (gegate) of hard ingebakken (niet gegate).
Zijn Shopify's eigen cookies een probleem?
Veel zijn echt functioneel (de winkelwagen kan zonder eentje niet werken). Het grijze gebied zijn de cookies met een analytics-karakter. Het eerlijke antwoord is dat de grens tussen "noodzakelijk en analytics" omstreden is — wat precies de reden is waarom het waarnemen van het echte gedrag beter is dan aannames doen.
Is dit een Shopify-specifiek probleem?
Nee. Dezelfde kloof tussen verklaard en waargenomen bestaat op WordPress, custom stacks, overal. Shopify levert juist sterke bouwstenen (Customer Privacy API, Customer Events). De kloof zit in configuratie en code van derden, niet in het platform.
De omslag in hoe je over tracking denkt
Het ene idee om te onthouden: een trackingopzet is alleen zo goed als zijn waargenomen gedrag, niet zijn verklaarde configuratie. Een aangevinkt vakje in een adminpaneel is een bewering. Het tabblad Network is het bewijs. De twee lopen voortdurend uiteen — een nieuwe app, een thema-update, een geplakt snippet — en niemand merkt het omdat niemand kijkt.
Dus kijk. Vijf minuten in DevTools vertelt je meer over wat je winkel echt doet dan welke instellingenpagina dan ook ooit zal doen. Voer het vandaag uit op je eigen winkel. Voer het daarna uit op die van een concurrent — je leest nooit meer een cookiebanner op dezelfde manier.