Meta Pixel stuurt nu automatisch productinformatie mee: wat betekent dat?

Sinds het voorjaar van 2026 verstuurt de Meta Pixel meer dan de events die je zelf hebt ingericht. Meta kondigde op 15 april 2026 een functie aan die met AI pagina-, product- en bedrijfsinformatie uit je HTML haalt en die met je bestaande pixel-events meestuurt. Het gaat dan om gegevens als productnamen, prijzen, beschikbaarheid en bedrijfsgegevens. Bestaande pixels kregen eerst een melding en daarna 30 dagen om de functie te bekijken voordat die aanging. Voor pixels die in aanmerking komen, staat de instelling standaard aan.

Dat roept twee vragen op. Wat stuurt je pixel nu precies mee, bovenop wat je zelf via de dataLayer en je tags hebt vastgelegd? En hoe stel je dat zelf vast, zonder alleen af te gaan op een schakelaar in Gebeurtenisbeheer (Events Manager)? Het antwoord zit voor een deel in Meta's instellingen en voor een deel in de pixel zelf: in de configuratie die de pixel per site ophaalt en in het verzoek naar facebook.com/tr dat je in de Network-tab van je browser kunt lezen.

Hieronder lees je eerst hoe het mechanisme werkt en welke drie functies vaak door elkaar lopen. Daarna komen de schakelaar in Gebeurtenisbeheer en de code-instelling autoConfig aan bod, gevolgd door de gevolgen voor toestemming, voor gevoelige sites en voor je Conversions API-koppeling. Tot slot volgen een checklist en een advies per type website. Waar Meta iets niet officieel bevestigt, staat dat er expliciet bij.

Wat Meta in april 2026 heeft aangezet, en voor wie

De functie heet in het Engels Automatically include more detailed page and product info. Daarmee stuurt de pixel met AI extra pagina- en productinformatie mee, zoals productnamen, beschikbaarheid en bedrijfsgegevens. Bestaande pixelgebruikers kregen een melding met een termijn van 30 dagen. Daarna staat de functie aan voor pixels die in aanmerking komen. Bij een nieuwe pixel die je handmatig installeert, is het een optionele schakelaar ('if eligible'). Of die schakelaar bij een nieuwe pixel al aan staat, is niet vastgesteld.

Meta deelt de gegevens op in drie groepen, en noemt daarbij uitdrukkelijk voorbeelden ('this may include'), geen uitputtende lijst:

• basispagina-informatie: paginatitel, beschrijving en paginatype;
• productinformatie: productnaam, prijs, valuta en beschikbaarheid;
• bedrijfsinformatie: bedrijfsnaam en locatie.

Als voordelen noemt Meta verrijkte events, aangepaste conversies per product zonder extra parameters, een betere cataloguskwaliteit doordat productdetails automatisch worden gesynchroniseerd, en het aanmaken van een catalogus op basis van de pixel. Gestructureerde data (structured data) volgens Schema.org of Open Graph herkent en deelt de pixel ook, los van de vraag of de nieuwe functie aan of uit staat.

De functie werkt niet als de pixel in een iframe draait, als het een IMG-pixel is, als de gegevensbron beperkingen heeft voor het delen van gegevens of als de pixel in Core setup staat. Adverteerders met bepaalde categorieën gegevensbronnen krijgen de functie mogelijk helemaal niet.

Twee punten zijn onzeker. De precieze datum waarop de functie per account aanging, staat nergens officieel. Praktijkmeldingen noemen 15 mei, 30 mei en 5 juni 2026, wat op een gefaseerde uitrol wijst. Daarnaast tonen schermafbeeldingen van de interface negen gegevenstypen in plaats van drie hoofdgroepen. Meta bevestigt die indeling niet officieel. Wat je in je eigen account ziet, is dus leidend.

Hoe de 'AI' werkt: regels van Meta, uitgevoerd in je browser

Meta beschrijft de functie als AI, maar zegt niet hoe die technisch werkt. Een deel daarvan kun je zelf zien. De pixel laadt fbevents.js en haalt daarna per pixel-ID een configuratie op via connect.facebook.net/signals/config/<pixel-ID>. In die configuratie zet Meta per pixel modules aan met regels als optIn("<pixel-ID>", "SmartSetup", true), en op dezelfde manier PageMetadata, MicrodataCoverage en MicrodataFieldTransmission.

In dezelfde configuratie staat een blok smartSetup met extractieregels die per site zijn gegenereerd. Elke regel koppelt een CSS-selector aan een sleutel en heeft als bron ml_suggestion. Een ingekort fragment uit de configuratie van een publieke pixel op een WordPress-site met Elementor (regel-ID's vervangen):

"<regel-id-1>": {"type":"basic_css","selector":"title","key":"page_title","source":"ml_suggestion"},
"<regel-id-2>": {"type":"basic_css","selector":"h1","key":"page_title","source":"ml_suggestion"},
"<regel-id-3>": {"type":"basic_css","selector":".elementor-heading-title.elementor-size-default","key":"author_article_name","source":"ml_suggestion"},
"<regel-id-4>": {"type":"basic_css","selector":".elementor-heading-title.elementor-size-default","key":"entity_name","source":"ml_suggestion"}

Het patroon is dus: Meta leidt aan zijn kant regels af voor jouw site, en de pixel voert die regels in de browser van de bezoeker uit. Het resultaat gaat mee in hetzelfde verzoek naar facebook.com/tr als het event. Deze uitleg is gebaseerd op eigen analyse van fbevents.js versie 2.9.433 en een pixelconfiguratie van 2 november 2026. Meta beschrijft het zelf niet zo. Of een deel van de AI-stap daarnaast server-side gebeurt op gegevens die de pixel al verstuurt, is niet bekend.

Het praktische gevolg is dat wat er wordt opgehaald afhangt van je HTML. De selectors in het fragment zijn generiek: de paginatitel, de eerste kop en een class van een paginabouwer. Een kop die in je thema voor iets anders dient, kan zo als author_article_name of entity_name worden meegestuurd. Op een webshop met nette productmarkup levert dat bruikbare productgegevens op. Op een site waar de paginatitel zelf iets over de bezoeker zegt, levert het juist een risico op.

Meta bepaalt per website welke elementen de pixel uitleest; de pixel stuurt die waarden mee met je bestaande events.

Drie functies die door elkaar lopen

De nieuwe verrijking wordt vaak verward met twee bestaande functies die ook automatisch werken. Ze hebben elk een eigen schakelaar en een eigen werking.

Automatische gebeurtenissen worden ontdubbeld met events die je zelf verstuurt, en Meta raadt aan ze aan te laten. Maak je een nieuwe pixel aan via Google Tag Manager, dan vraagt Meta tijdens de setup of je automatische gebeurtenissen wilt instellen. Die vraag kun je weigeren, en Meta breidt deze werkwijze geleidelijk uit.

Automatisch geavanceerd overeenkomsten zoeken (AAM) kijkt naar formuliervelden, hasht de waarden in de browser en gooit de gegevens na de match weg. De functie is niet beschikbaar voor beperkte branches zoals bank, lening, financiële diensten, verzekeringen, farmacie en gezondheid, en ook niet in een iframe of bij een IMG-pixel. In de pixelcode is de klassieke AAM-module (AutomaticMatching) een aparte module. Daardoor heeft autoConfig, dat verderop aan bod komt, geen invloed op AAM.

Uitzetten in Gebeurtenisbeheer

De officiële route om de verrijking te beheren is de schakelaar bij de pixel. Het pad in de Nederlandse interface:

1. In Gebeurtenisbeheer klik je links op het pictogram Gegevensbronnen.
2. Je selecteert de naam en het ID van je Meta-pixel en opent het tabblad Instellingen.
3. Onder Meta-pixelinstellingen staat de optie Automatisch meer gedetailleerde pagina- en productinformatie toevoegen.
4. Via Gegevenstypen weergeven zet je per gegevenstype de schakelaar aan of uit.

Per pixel uit te zetten in Gebeurtenisbeheer. Vereenvoudigd nagebouwd; de echte interface kan iets afwijken.

Meta adviseert alle gegevenstypen aan te laten. Je kunt ook per type kiezen, bijvoorbeeld productgegevens aan en basispagina-informatie uit.

De Nederlandse labels komen uit Meta's eigen vertaling. In de live interface kan de formulering afwijken. Er zijn accounts waarin de optie 'Automatisch meer gedetailleerde pagina- en productinformatie gebruiken' heet, onder 'Instellingen van Meta-pixel'. Ook in het linkermenu wisselt Meta tussen Gegevensbronnen en Datasets. In dezelfde tab staan de schakelaars voor Automatic events (onder Event setup) en voor AAM, met Show customer information parameters per klantparameter.

Twee dingen zijn niet gedocumenteerd: of de functie na het uitzetten ook bij latere wijzigingen uit blijft, en wat de schakelaar aan Meta's kant precies stopt. Er zijn meldingen dat de functie na uitzetten niet opnieuw aangaat, maar Meta bevestigt dat niet. Een controle na een paar weken in de Network-tab, zoals hieronder beschreven, geeft daar zekerheid over.

autoConfig: wat het officieel doet en wat de code laat zien

Naast de schakelaar bestaat er een code-instelling. Met Automatic Configuration (autoConfig) verstuurt de pixel 'button click and page metadata', zoals gegevens volgens Open Graph of Schema.org. Dat zet je uit met autoConfig, boven de init-aanroep:

fbq('set', 'autoConfig', false, 'PIXEL_ID');
fbq('init', 'PIXEL_ID');
fbq('track', 'PageView');

Die officiële beschrijving dateert van vóór de aankondiging en zegt niets over de AI-verrijking. Meta bevestigt dus niet officieel dat autoConfig de nieuwe functie uitzet. De code van fbevents.js 2.9.433 laat wel het volgende zien:

• autoConfig op false met een pixel-ID roept intern optOut(ID, "AutomaticSetup") aan. Zonder ID wordt een globale vlag disableAutoConfig gezet. De boolean false en de string 'false' werken allebei.
• De groep AutomaticSetup omvat onder meer InferredEvents, Microdata, AutomaticParameters, PageMetadata, MicrodataCoverage, MicrodataFieldTransmission, AutomaticMatchingAI en SmartSetup.
• De opt-out wordt per module vastgelegd. De serverconfiguratie zet modules aan met optIn(ID, module, true), en die derde parameter zorgt ervoor dat een eerdere opt-out van de site niet wordt overschreven.
• De module SmartSetup doet niets als disableAutoConfig aan staat of als de pixel is afgemeld voor AutomaticSetup.

In de huidige code zet autoConfig op false, vóór init, de verrijking in de browser dus uit. Dat is een uitkomst van eigen analyse, geen officiële garantie. Meta kan dit in een volgende release veranderen. Een test in de Network-tab na elke wijziging blijft daarom nodig.

autoConfig is breder dan de AI-schakelaar. Je zet er ook SubscribedButtonClick, het meesturen van microdata en de automatische gebeurtenissen mee uit. Gebruik je een catalogus op basis van de pixel of vertrouw je op automatische events, dan verlies je die functionaliteit.

In de code staat ook een smaller commando dat alleen de module SmartSetup uitschakelt. Microdata en automatische gebeurtenissen blijven dan werken:

fbq('set', 'smartSetup', false, 'PIXEL_ID');
fbq('init', 'PIXEL_ID');

Dit commando is niet gedocumenteerd en daarmee ook niet ondersteund. Het is een optie om te testen, niet iets om zonder controle op een productiesite te zetten.

Toestemming en AVG: wat er verandert en wat niet

De juridische basis verandert niet. Artikel 5(3) van de ePrivacy-richtlijn, in Nederland artikel 11.7a van de Telecommunicatiewet, is van toepassing op pixel- en URL-tracking. De EDPB werkt dat uit in Guidelines 2/2023. Voor trackingpixels gelden dezelfde regels als voor trackingcookies: een grondslag, tijdige informatie en goede beveiliging. Meta's Business Tools Terms eisen voor de EU aantoonbare toestemming voordat Meta-cookies of andere informatie op het apparaat worden opgeslagen of uitgelezen.

Voor het verzamelen en doorgeven van de gegevens ben je samen met Meta gezamenlijk verwerkingsverantwoordelijke, in lijn met het Fashion ID-arrest (HvJ EU, C-40/17). Voor matching, meting en analyse is Meta verwerker. Event-gegevens worden maximaal twee jaar bewaard.

Technisch regel je toestemming met de consent-API van de pixel. Je roept revoke aan vóór init, op elke pagina, en grant pas nadat de bezoeker via je CMP toestemming heeft gegeven:

fbq('consent', 'revoke');
fbq('set', 'autoConfig', false, 'PIXEL_ID'); // optioneel
fbq('init', 'PIXEL_ID');
fbq('track', 'PageView');

// na toestemming via de CMP:
fbq('consent', 'grant');

De verrijking zit in hetzelfde /tr-verzoek als het event. Laad je de pixel pas na toestemming, of staat revoke aan tot er toestemming is, dan gaat de verrijking ook pas daarna mee. De werking van je toestemmingsregeling hoeft dus niet anders. Wat wel verandert, is de hoeveelheid pagina-inhoud die per event meegaat. Hoe je toestemming in GTM inricht, lees je in Consent Mode v2 instellen met Cookiebot en GTM. Welke cookies zonder toestemming mogen, staat in Cookies zonder toestemming.

Extra opletten bij zorg-, juridische en financiële sites

Op de meeste sites zijn een paginatitel en een H1 onschuldig. Op een zorg- of advocatensite kunnen juist die gegevens de aard van een hulpvraag prijsgeven, bijvoorbeeld bij titels als 'Behandeling depressie' of 'Echtscheiding aanvragen'. Meta's voorwaarden verbieden het delen van gezondheids-, financiële en andere gevoelige gegevens, en de verantwoordelijkheid daarvoor ligt bij de adverteerder. Dat geldt ook voor gegevens die de nieuwe functie ophaalt. Daarnaast valt informatie over gezondheid onder de bijzondere persoonsgegevens van artikel 9 AVG.

Meta kent gegevensbronnen een categorie met beperkingen toe, zoals Health and wellness, Financial service, Politics, Religion of Personal hardship. Een categorie die Meta zelf heeft toegekend, kun je niet wijzigen. Met Core setup worden aangepaste parameters en alles in de URL na het domein beperkt. AAM kan daardoor wegvallen en updates van een pixelcatalogus kunnen stoppen. Meta noemt Core setup uitdrukkelijk geen vervanging voor je eigen compliancemaatregelen.

Of EER-adverteerders of gezondheidscategorieën standaard zijn uitgezonderd van de verrijking, is onduidelijk. Er is geen officiële bron, en de meldingen uit de praktijk spreken elkaar tegen. Zo is er een melding van een pixel op een site met gezondheidsgerelateerde pagina's zonder beperkte categorie die de functie wel kreeg.

Op zo'n site kun je de verrijking uitzetten en eventueel ook autoConfig. Daarnaast kun je Core setup of een passende categorie overwegen, de paginatitels en URL's doorlopen, en de pixel alleen laden op pagina's die niets over een hulpvraag zeggen. Of je de pixel op zo'n site überhaupt gebruikt, is een afweging die bij jou als adverteerder ligt.

Conversions API: Meta-enabled CAPI versus je eigen sGTM-container

In dezelfde aankondiging introduceerde Meta de Meta-enabled Conversions API ('Conversions API with Meta'): een gratis koppeling met één klik, alleen voor web. De parameters die via de pixel worden gedeeld, gaan ook via deze koppeling mee, en de events worden automatisch ontdubbeld. Daaruit volgt dat de verrijkte parameters waarschijnlijk ook via deze route bij Meta komen. Dat is een afleiding: Meta zegt het niet specifiek over de verrijking. Gebruik je al een CAPI-koppeling via een partner of een eigen implementatie, dan verandert er voor die koppeling niets.

Je zet de koppeling aan via Settings → Conversions API with Meta → Connect now en koppelt hem los via Actions → Disconnect. Op bedrijfsniveau kies je onder meer tussen 'Connect all owned datasets automatically' en 'Never connect all datasets at once'.

Een minder zichtbaar punt zit in het officiële Meta Pixel-webtemplate voor GTM. Sinds 15 juni 2026 heeft dat template de checkbox Opt in to a Meta-enabled Conversions API integration, en die staat standaard aan. Ook bestaande tags zonder dat veld worden als opt-in behandeld, en het template roept vóór init het commando fbq('optinMetaEnabledCapi', pixelId) aan. De huidige versie is 2.0.9 van 23 september 2026. Gebruik je dit template, dan heb je je dus mogelijk aangemeld zonder dat je dat bewust hebt gekozen.

Een eigen CAPI-tag in een server-side GTM-container werkt anders. Die tag bouwt het event op uit de event data die binnenkomt, bijvoorbeeld een GA4-stream naar je container op ujgsedfr3jdfgh.voorbeeld.nl, met automatische mapping van custom data en user data of met handmatige overrides. De verrijking zit in het browserverzoek naar facebook.com/tr en komt daardoor niet vanzelf in je server-event. Ook dat is een afleiding uit de werking van de tag. Je server-event bevat in die opzet alleen wat je zelf mapt.

Voor het hosten van de container zijn Taggrs en Stape twee gangbare opties. Taggrs gebruikt voor de CAPI-tag het template van Stape, dus de werking van de tag is bij beide gelijk. Voor de ontdubbeling stuur je hetzelfde event_id mee in de pixel en in het server-event. Meta ontdubbelt op event_name plus een identiek event_id, of op event_name plus external_id of fbp. Het eerst ontvangen event heeft voorrang. De volledige inrichting staat in Meta Conversions API via server-side GTM, en wat zo'n container kost, lees je in Wat kost server-side tagging per maand?

Browser-pixel, Meta-enabled CAPI of je eigen servercontainer: alleen de laatste stuurt uitsluitend wat jij kiest.

WooCommerce, Shopify en GTM: wat er per platform gebeurt

Shopify

App-pixels draaien op Shopify in een 'strict' sandbox, een Web Worker zonder toegang tot de DOM. Custom pixels draaien in een 'lax' sandbox-iframe zonder toegang tot het hoofdframe. Functies die de DOM uitlezen, werken daar anders of helemaal niet. Meta sluit pixels in een iframe uit, en in de code stopt SmartSetup in een Web Worker. Via de Meta-app op Shopify werkt de verrijking daarom waarschijnlijk niet. Dat is een afleiding, geen bevestiging. Een eigen fbq-snippet direct in de theme-code valt hier niet onder.

WooCommerce

De plugin Meta for WooCommerce (versie 3.7.8) deelt per event een event_id tussen pixel en CAPI. Toestemming loopt via fbq('consent', 'revoke') en fbq('consent', 'grant'). Een optie voor autoConfig heeft de plugin niet, dus de schakelaar in Gebeurtenisbeheer is hier de directe route. Sommige plugins beschrijven de nieuwe functie als het uitlezen van microdata. Dat is niet hetzelfde: gestructureerde data wordt gedeeld, los van de schakelaar.

Google Tag Manager

Het officiële Meta Pixel-template heeft onder 'More settings' de checkbox Disable Automatic Configuration. Die zet per pixel-ID fbq('set', 'autoConfig', false, pixelId) vóór init. Het template roept als eerste fbq('consent', ...) aan, met 'grant' als standaard, tenzij je het veld Consent Granted (GDPR) op false zet. De volgorde in het template is daarmee consent, autoConfig en dan init. Het veld Event ID is bedoeld voor ontdubbeling met server-side events, en de opt-in voor Meta-enabled CAPI staat standaard aan. Werk je met een eigen tagopzet, dan lees je in GTM server-side vs. client-side wat het verschil in datastroom is.

Checklist: zo controleer je zelf wat je pixel verstuurt

De betrouwbaarste controle is het verzoek zelf. In de Network-tab van de developer tools filter je op facebook.com/tr en open je de queryparameters van een event. De meeste parameters hieronder documenteert Meta niet. De betekenis komt uit analyse van de pixelcode en is daarom een werkhypothese.

Een eenvoudige test: je noteert welke parameters een event bevat, zet de schakelaar of autoConfig uit, en laadt de pagina opnieuw. Werkt de uitschakeling, dan horen ss, pmd en imft te verdwijnen. Zo kun je het verzoek vergelijken:

Filter: facebook.com/tr
Voor:  ev=PageView … ss={…} & iss=1 & pmd[…] & imft=1 & ap[…]
Na:    ev=PageView … (geen ss, pmd of imft)

Filter in de Network-tab op facebook.com/tr: na het uitzetten horen ss, pmd en imft te verdwijnen.

Daarnaast zijn er deze controles:

• signals/config: in de Network-tab het verzoek naar connect.facebook.net/signals/config/<pixel-ID>. Daarin zie je welke modules aan staan (optIn(…, "SmartSetup", true), "PageMetadata") en welke ml_suggestion-regels Meta voor jouw site heeft gemaakt.
• Meta Ads Data Advisor (voorheen Meta Pixel Helper), een extensie voor Chrome en Edge die de verzonden events en parameters toont.
• Test events in Gebeurtenisbeheer, met het filter voor automatisch gelogde pixel-events. Die kunnen HTML-metadata, knopklikgegevens en paginametadata bevatten. De testgegevens blijven 24 uur bewaard.
• Het tabblad Diagnostiek, met meldingen in de groepen Active, Previously detected en Ignored. Meldingen over gevoelige gegevens verdienen hier de meeste aandacht.
• In de servercontainer de preview en de logs. Bij Stape zijn logs beschikbaar vanaf het Pro-plan, met een bewaartermijn van 3 dagen. Je kijkt welke custom_data en user_data naar graph.facebook.com gaan, en of het event_id gelijk is aan eid in de browser.
• Een nulmeting: conversies, Event Match Quality en de catalogusdiagnostiek vóór en na een wijziging. Daarmee kun je meetverschillen achteraf verklaren.

Mijn advies per type website

Een webshop die productgegevens al netjes via de dataLayer meestuurt (content_ids, value, currency), heeft het minst te winnen of te verliezen. De verrijking voegt dan vooral gegevens toe die je zelf niet doorgeeft, zoals beschikbaarheid, en kan de catalogus helpen. Wat er gebeurt als jouw waarden en de afgeleide waarden verschillen, beschrijft Meta niet. Het beste kun je een event met de functie aan en uit vergelijken in Test events en de Network-tab, en eventueel alleen de productgegevens aan laten.

Voor een leadsite of dienstverlener is het voordeel kleiner, omdat er weinig productgegevens zijn. Daar kun je de verrijking uitzetten of beperken tot basispagina-informatie, afhankelijk van hoe je campagnes optimaliseert. Ben je afhankelijk van automatische gebeurtenissen, dan is de schakelaar in Gebeurtenisbeheer een logischere keuze dan autoConfig.

Voor zorg-, juridische en financiële sites kun je de verrijking het beste uitzetten, eventueel aangevuld met autoConfig, Core setup of een passende categorie en een pixel die alleen op niet-gevoelige pagina's laadt.

Ongeacht het type site kun je bewust kiezen voor Meta-enabled CAPI of voor een eigen server-side koppeling, in plaats van de standaardinstelling in het GTM-template te laten beslissen. Met een eigen container bij Taggrs of Stape bepaal je zelf welke velden meegaan. Meta-enabled CAPI kost minder inrichting, maar neemt alles over wat de pixel stuurt.

Tot slot

De verrijking is geen nieuw type tracking, maar een uitbreiding van wat hetzelfde /tr-verzoek bevat. Meta's schakelaar is de officiële route. autoConfig werkt in de huidige code ook, maar zonder garantie. Doordat Meta deze functies blijft aanpassen, geeft alleen een eigen controle in de Network-tab zekerheid over wat je pixel op dit moment verstuurt.

Bronnen

https://www.facebook.com/business/news/pixel-conversionsapi-updates
https://www.facebook.com/business/help/1304388211684481
https://www.facebook.com/business/help/1567320497668753
https://www.facebook.com/business/help/952192354843755
https://www.facebook.com/business/help/555177831677798
https://www.facebook.com/business/help/1292598407460746
https://www.facebook.com/business/help/611774685654668
https://www.facebook.com/business/help/1993001664341800
https://www.facebook.com/business/help/124742407297678
https://www.facebook.com/business/help/1402913027039332
https://www.facebook.com/business/help/198406697184603
https://www.facebook.com/business/help/2040882565969969
https://www.facebook.com/business/help/667164051342757
https://www.facebook.com/business/help/823677331451951
https://www.facebook.com/business/help/433493041367251
https://www.facebook.com/business/help/1861378164396295
https://developers.facebook.com/docs/meta-pixel/advanced/
https://developers.facebook.com/docs/meta-pixel/implementation/gdpr
https://www.facebook.com/legal/businesstech
https://connect.facebook.net/en_US/fbevents.js
https://github.com/meta/GoogleTagManager-WebTemplate-For-FacebookPixel
https://github.com/stape-io/facebook-tag
https://taggrs.io/docs/server-side-tracking/facebook/meta-capi
https://taggrs.io/docs/server-side-tracking/facebook/event-deduplication
https://stape.io/price
https://shopify.dev/docs/apps/build/marketing/pixels
https://wordpress.org/plugins/facebook-for-woocommerce/
https://www.autoriteitpersoonsgegevens.nl/themas/internet-slimme-apparaten/andere-volgsoftware/tracking-pixel
https://www.edpb.europa.eu/documents/guideline/guidelines-22023-on-technical-scope-of-art-53-of-eprivacy-directive_en
https://curia.europa.eu/juris/liste.jsf?num=C-40/17