{"id":81801,"date":"2026-09-18T09:37:00","date_gmt":"2026-09-18T09:37:00","guid":{"rendered":"https:\/\/taggrs.io\/?p=81801"},"modified":"2026-09-24T09:01:53","modified_gmt":"2026-09-24T09:01:53","slug":"woocommerce-server-side-tracking","status":"publish","type":"post","link":"https:\/\/taggrs.io\/nl\/woocommerce-server-side-tracking\/","title":{"rendered":"WooCommerce Server-side Tracking: een complete installatiehandleiding"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">De standaard WooCommerce-trackingopstelling bestaat uit een pixel op de site en een aankoop-tag op de bedankpagina. Het is snel te installeren en het werkt bij een testbestelling, en daarom gebruiken zoveel webwinkels het. <\/p>\n\n<p class=\"wp-block-paragraph\">Het probleem is hoe zo\u2019n testbestelling eruitziet. Je kiest \u00e9\u00e9n product, betaalt met je kaart en komt op de bevestigingspagina terecht, waar de aankoop wordt weergegeven. Het probleem is dat maar heel weinig mensen op die manier kopen. Een echte klant voegt iets toe aan zijn winkelwagen vanaf een categoriepagina die niet opnieuw wordt geladen, dus er is geen paginaweergave waaraan de gebeurtenis kan worden gekoppeld. Als ze via iDEAL of Klarna betalen, worden ze van je site weggeleid, en als ze het tabblad sluiten voordat de omleiding ze terugbrengt, registreert WooCommerce een bestelling die je tracking niet heeft gezien. Tel daar nog eens gecachete afrekenpagina\u2019s bij op die oude waarden laten zien, banners voor geweigerde toestemming, en adblockers die het verzoek tegenhouden voordat het de browser verlaat.     <\/p>\n\n<p class=\"wp-block-paragraph\">Dit wordt niet als fout gemeld. Je winkel blijft bestellingen aannemen en de rapporten blijven vollopen, dus de opzet ziet er prima uit \u2013 totdat iemand de cijfers probeert af te stemmen. <\/p>\n\n<p class=\"wp-block-paragraph\">Met tracking aan de server-side vervang je die versnipperde opzet door \u00e9\u00e9n enkele route die je zelf beheert. In het volgende deel wordt uitgelegd wat dat inhoudt, en de rest van de handleiding gaat over de installatie, de specifieke problemen bij WooCommerce en hoe je kunt controleren of het bij jou werkt. <\/p>\n\n<h2 id=\"what-server-side-tracking-actually-does\" class=\"wp-block-heading\">Wat tracking aan de server-side eigenlijk doet<\/h2>\n\n<p class=\"wp-block-paragraph\">In een normale opzet laadt je webshop een script van Google, een ander van Meta en misschien nog een derde van TikTok. Elk script stuurt gegevens rechtstreeks vanuit de browser van de bezoeker naar dat bedrijf. Je hebt geen controle over wat er wordt verzonden en er is geen centrale plek om dit te controleren.  <\/p>\n\n<p class=\"wp-block-paragraph\">Bij tracking aan de server-side komt er een extra stap tussendoor. De browser stuurt gegevens naar een server die jij beheert, op je eigen webadres. Die server bepaalt vervolgens wat er naar GA4 gaat, wat naar Google Ads gaat, wat naar Meta gaat en wat er als eerste wordt verwijderd.  <\/p>\n\n<p class=\"wp-block-paragraph\">Daardoor veranderen er drie dingen. Je krijgt de controle, want je kunt waarden aanpassen of persoonlijke gegevens verwijderen voordat er iets wordt verzonden. Je krijgt een betrouwbaardere levering, want het advertentieverzoek komt niet meer vanuit de browser. En je krijgt een betere attributie, want je server kan bezoekersgegevens langer opslaan dan de browser toestaat.   <\/p>\n\n<h3 id=\"what-you-gain-and-what-you-do-not\" class=\"wp-block-heading\">Wat je erbij wint en wat niet<\/h3>\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Wat mensen verwachten<\/strong><\/td><td><strong>Wat er echt gebeurt<\/strong><\/td><\/tr><tr><td>Hiermee wordt mijn tracking gerepareerd<\/td><td>Dit lost het probleem met de aflevering op. Als je configuratie een verkeerde waarde rapporteert, wordt die verkeerde waarde nu altijd correct afgeleverd. <\/td><\/tr><tr><td>Ik kan mijn Meta-pixel uitschakelen<\/td><td>Meta werkt beter als je zowel browser- als servergegevens combineert. Alleen servergegevens zijn de uitzondering. <\/td><\/tr><tr><td>Het omzeilt de regels rond toestemming<\/td><td>Nee, dat is niet zo. De regels voor toestemming gelden nog steeds. <\/td><\/tr><tr><td>Je hoeft dit maar \u00e9\u00e9n keer in te stellen<\/td><td>De route is stabiel, maar je winkel niet. Test het opnieuw na het afrekenen en na wijzigingen aan plug-ins en thema\u2019s. <\/td><\/tr><\/tbody><\/table><\/figure>\n\n<h2 id=\"why-woocommerce-tracking-breaks\" class=\"wp-block-heading\">Waarom de tracking van WooCommerce niet werkt<\/h2>\n\n<p class=\"wp-block-paragraph\">WooCommerce kun je aanpassen tot bijna elk soort webwinkel. Die flexibiliteit is handig voor je bedrijf, maar maakt het lastig om alles bij te houden. <\/p>\n\n<h3 id=\"block-checkout-and-classic-checkout-behave-differently\" class=\"wp-block-heading\">'Block Checkout' en 'Classic Checkout' werken anders<\/h3>\n\n<p class=\"wp-block-paragraph\">Bij de klassieke afrekenprocedure wordt gebruikgemaakt van shortcodes en al lang bestaande WooCommerce-hooks. De winkelwagen- en afrekenblokken maken gebruik van de Store API en hun eigen gebeurtenissensysteem. Sommige oudere jQuery-winkelwagenevents zijn omgezet in native browserevents met het voorvoegsel `wc-blocks_`.  <\/p>\n\n<p class=\"wp-block-paragraph\">Een trigger die is gebaseerd op een klassieke jQuery-gebeurtenis ontvangt mogelijk niet de verwachte gegevens van een op blokken gebaseerde pagina. WooCommerce beschrijft de huidige <a href=\"https:\/\/developer.woocommerce.com\/docs\/block-development\/extensible-blocks\/cart-and-checkout-blocks\/dom-events\/\" target=\"_blank\" rel=\"noopener\">DOM-events van de winkelwagen- en afrekenblokken<\/a>, maar de gegevenslaag moet deze nog wel omzetten naar een stabiel analyseformaat. <\/p>\n\n<h3 id=\"your-cart-updates-without-reloading-the-page\" class=\"wp-block-heading\">Je winkelmandje wordt bijgewerkt zonder dat de pagina opnieuw wordt geladen<\/h3>\n\n<p class=\"wp-block-paragraph\">Veel thema\u2019s en productoverzichten maken gebruik van AJAX om een item toe te voegen zonder dat er een nieuwe pagina wordt geladen.<\/p>\n\n<p class=\"wp-block-paragraph\">Een trigger op basis van paginaweergaven kan die wijziging niet zien. Voor een betrouwbare meting is een \u2018add_to_cart\u2019-event nodig met het juiste product, de juiste prijs en de juiste hoeveelheid op het moment dat WooCommerce de actie bevestigt. <\/p>\n\n<h3 id=\"payment-flows-leave-the-store\" class=\"wp-block-heading\">De betalingsstromen verlaten de winkel<\/h3>\n\n<p class=\"wp-block-paragraph\">Bij sommige betaalmethoden word je als klant ergens anders naartoe geleid voordat WooCommerce het afrekenen als voltooid markeert. Een aankoop-tag die alleen gekoppeld is aan het bekijken van de bedankpagina, neemt die onzekerheid over. Als je de pagina vernieuwt, kan de tag ook opnieuw worden geactiveerd, tenzij het transactie-ID op de juiste manier wordt gebruikt.  <\/p>\n\n<p class=\"wp-block-paragraph\">Het probleem zit hem hierin. Iemand rondt zijn betaling af en sluit vervolgens het venster, in plaats van te wachten tot hij teruggestuurd wordt naar je webshop. WooCommerce registreert de bestelling, maar je tracking werkt niet, omdat niemand de bevestigingspagina heeft geladen. Je ziet dit terug als een verschil tussen de omzet in WooCommerce en de omzet op het platform, dat nog groter wordt op mobiele apparaten en nog erger bij lokale betaalmethoden.   <\/p>\n\n<p class=\"wp-block-paragraph\">Er zijn twee manieren om dit op te lossen. Je kunt de verkoop direct vanuit WooCommerce doorsturen zodra de bestelling wordt aangemaakt, zodat het helemaal niet afhankelijk is van de browser. TAGGRS ondersteunt dit via webhooks. Of je kunt het verschil accepteren en het maandelijks controleren. De webhook-methode is completer; je hoeft maar \u00e9\u00e9n ding in te stellen. Google Ads heeft de klik-ID nodig om een verkoop toe te wijzen, en WooCommerce slaat die standaard niet op. Als je die eerder in het traject vastlegt en aan de bestelling koppelt, kan een TAGGRS-webhook die doorgeven. Zonder die stap hebben verkopen die alleen via de webhook binnenkomen geen klik-ID om aan toe te wijzen. Een veelgebruikte aanpak is om de browser-event te gebruiken als die beschikbaar is, en de webhook als back-up voor bestellingen waarbij die nooit is gegenereerd.        <\/p>\n\n<h3 id=\"wordpress-plugins-overlap\" class=\"wp-block-heading\">WordPress-plugins overlappen elkaar<\/h3>\n\n<p class=\"wp-block-paragraph\">Een datalaag-plugin, Meta-plugin, Google-integratie, consent management platform (CMP) en themacode kunnen elkaar allemaal overlappen. Geen van deze zal je waarschuwen, want vanuit het perspectief van elke plugin werkt alles prima. Je komt er pas achter als Meta het dubbele van je werkelijke omzet rapporteert, of als je een ogenschijnlijk overbodige plugin verwijdert en de omzet flink daalt.  <\/p>\n\n<h3 id=\"safari-is-stricter-than-most-setups-expect\" class=\"wp-block-heading\">Safari is strenger dan de meeste mensen verwachten<\/h3>\n\n<p class=\"wp-block-paragraph\">Safari beperkt de geldigheidsduur van cookies tot 7 dagen. Als een Safari-bezoeker niet binnen een week terugkomt, wordt hij of zij weer als een compleet nieuwe bezoeker gezien, zonder dat er gegevens zijn over waar hij of zij vandaan kwam. Dit geldt voor elke browser op de iPhone, inclusief Chrome en Firefox, omdat Apple eist dat ze de Safari-engine gebruiken.  <\/p>\n\n<p class=\"wp-block-paragraph\">Het gebruikelijke advies is dat tracking server-side dit oplost, omdat gegevens die door je eigen server worden opgeslagen langer bewaard blijven dan gegevens die in de browser worden opgeslagen. Vroeger was dat het hele verhaal. <\/p>\n\n<p class=\"wp-block-paragraph\">Sinds 2023 voert Safari nog een extra controle uit. Als je trackingserver bij een andere host staat dan je webwinkel, beschouwt Safari die als een externe partij en past het sowieso dezelfde limiet van zeven dagen toe. Dit is een veelvoorkomend probleem voor webwinkels. Als je webwinkel bijvoorbeeld op een WordPress-host draait en je trackingserver op Google Cloud, lijken die twee niet met elkaar verbonden.   <\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Hoe je dit kunt controleren:<\/strong> Plaats een testbestelling in Safari en kijk vervolgens naar de trackingcookie die je server plaatst. Als die na zeven dagen verloopt in plaats van de periode die je hebt ingesteld, heb je hier last van. <\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Wat je kunt doen:<\/strong> Zet je trackingserver naast je webshop, zodat ze op elkaar aansluiten, of gebruik een speciale herstelfunctie hiervoor. TAGGRS <a href=\"https:\/\/taggrs.io\/nl\/cookie-recovery-ios\/\">Cookie Recovery<\/a> herstelt gegevens die door Safari en iOS worden verwijderd. Hiervoor moet het Enhanced Tracking Script zijn ingeschakeld.  <\/p>\n\n<p class=\"wp-block-paragraph\">Adblockers vormen de andere helft van het probleem. Zelfs als gegevens naar je eigen webadres worden gestuurd, kan het adres zelf nog steeds duidelijke trackingwoorden bevatten die door adblockers worden herkend. Tracking server-side kan niets verwerken wat al is tegengehouden voordat het de browser verliet.  <\/p>\n\n<h2 id=\"woocommerce-server-side-gtm-architecture\" class=\"wp-block-heading\">WooCommerce-architectuur voor GTM server-side<\/h2>\n\n<p class=\"wp-block-paragraph\">De route van het evenement ziet er zo uit:<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>WooCommerce-winkel \u2192 datalaag \u2192 GTM op de website \u2192 GTM op de server \u2192 analyse- en advertentieplatforms<\/strong><\/p>\n\n<p class=\"wp-block-paragraph\">Elk onderdeel heeft \u00e9\u00e9n taak:<\/p>\n\n<ol class=\"wp-block-list\">\n<li><strong>De winkel houdt het hele proces bij<\/strong>, van het bekijken van een product tot een afgeronde bestelling.<\/li>\n\n\n\n<li><strong>De gegevenslaag beschrijft dit<\/strong> met een GA4-event en de relevante product- of bestelgegevens.<\/li>\n\n\n\n<li><strong>Web GTM verzamelt de gegevens<\/strong>, verwerkt de toestemming en stuurt ze naar de URL van de servercontainer.<\/li>\n\n\n\n<li><strong>Server GTM verwerkt de gegevens<\/strong> voordat ze naar GA4, Google Ads, Meta of een andere bestemming worden verzonden.<\/li>\n<\/ol>\n\n<p class=\"wp-block-paragraph\">De gegevenslaag is de vertaallaag tussen WooCommerce en GTM. Zonder die laag kan elke wijziging aan een thema of plug-in uitmonden in een apart JavaScript-project. Een plug-in die het <a href=\"https:\/\/developers.google.com\/analytics\/devguides\/collection\/ga4\/ecommerce\" target=\"_blank\" rel=\"noopener\">GA4-e-commerce-event-model<\/a> volgt, biedt een stabielere basis.  <\/p>\n\n<h2 id=\"before-you-start\" class=\"wp-block-heading\">Voordat je begint<\/h2>\n\n<p class=\"wp-block-paragraph\">Zorg dat je de volgende dingen bij de hand hebt voordat je de server-side tracking in WordPress instelt:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Beheerdersrechten voor WordPress en WooCommerce<\/li>\n\n\n\n<li>Een webcontainer van Google Tag Manager<\/li>\n\n\n\n<li>Een Google Tag Manager-servercontainer en hosting<\/li>\n\n\n\n<li>Een first-party tagging-URL, zoals https:\/\/sending.example.com<\/li>\n\n\n\n<li>Een GA4-property en een webdatastroom<\/li>\n\n\n\n<li>Toegang tot de betreffende Google Ads- en Meta-accounts<\/li>\n\n\n\n<li>Een CMP die toestemmingskeuzes kan doorgeven aan GTM<\/li>\n\n\n\n<li>Een testwinkel of een andere veilige manier om proefbestellingen te plaatsen<\/li>\n\n\n\n<li>Een lijst met plug-ins die al pixels, GTM of e-commerce-events toevoegen<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">E\u00e9n gegevenslaag moet verantwoordelijk zijn voor het e-commerce-event, en \u00e9\u00e9n tag moet verantwoordelijk zijn voor elke platformbestemming. Noteer die verantwoordelijken voordat je iets verandert. Met deze korte inventarisatie kun je heel wat problemen opsporen.  <\/p>\n\n<h2 id=\"how-to-set-up-woocommerce-server-side-tracking\" class=\"wp-block-heading\">Hoe stel je server-side tracking in WooCommerce in?<\/h2>\n\n<p class=\"wp-block-paragraph\">De schermen en instellingen van de hosting en plug-ins veranderen, dus deze stappen richten zich op het verloop van het event en de controles die ertoe doen.<\/p>\n\n<h3 id=\"1-host-the-server-gtm-container\" class=\"wp-block-heading\">1. Zet de GTM-container op de server<\/h3>\n\n<p class=\"wp-block-paragraph\">Zet de servercontainer in en koppel deze aan een eigen tagging-URL, zoals sending.example.com. Vermijd voor de hand liggende termen die met tracking te maken hebben, zoals \u2018metrics\u2019, \u2018analytics\u2019 of \u2018data\u2019, in het subdomein. Filterlijsten van adblockers kunnen zowel herkenbare domeinnamen als verzoekpaden als doelwit nemen.  <\/p>\n\n<p class=\"wp-block-paragraph\">Gebruik de <a href=\"https:\/\/taggrs.io\/docs\/server-side-tracking\/setup\/subdomain\">handleiding voor het instellen van een aangepast subdomein<\/a> om het domein te configureren en te controleren. Voeg de productie-URL toe onder de instellingen van de servercontainer en controleer of alles goed werkt voordat je het verkeer naar de winkel doorstuurt. De servercontainer moet ook goed openen in GTM Preview.  <\/p>\n\n<h3 id=\"2-add-a-woocommerce-data-layer-for-ga4\" class=\"wp-block-heading\">2. Voeg een WooCommerce-gegevenslaag toe voor GA4<\/h3>\n\n<p class=\"wp-block-paragraph\">Installeer \u00e9\u00e9n datalaagintegratie die de gebruikte storefront- en afrekentypes ondersteunt. Deze moet standaard e-commerce-events doorsturen met een array van artikelen en consistente product-ID\u2019s. <\/p>\n\n<p class=\"wp-block-paragraph\">Test in ieder geval het volgende:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>view_item_list en view_item<\/li>\n\n\n\n<li>add_to_cart en remove_from_cart<\/li>\n\n\n\n<li>view_cart en begin_checkout<\/li>\n\n\n\n<li>purchase<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Controleer bij een aankoop de transaction_id, waarde, valuta en artikelgegevens. Google vereist een unieke ID voor elke bestelling. Gebruik het WooCommerce-bestelnummer \u2013 GA4 gebruikt dit om te zien of dezelfde bestelling twee keer binnenkomt en om later terugbetalingen te verwerken.  <\/p>\n\n<p class=\"wp-block-paragraph\">Er zijn drie dingen die je moet weten:  <\/p>\n\n<ul class=\"wp-block-list\">\n<li>Het werkt alleen voor websitegegevens \u2013 het werkt niet voor app-gegevens.<\/li>\n\n\n\n<li>Het registreert alleen dubbele gegevens van dezelfde bezoeker, dus hetzelfde bestelnummer dat van twee verschillende mensen binnenkomt, wordt twee keer geteld.<\/li>\n\n\n\n<li>Als het veld leeg is, behandelt GA4 al die bestellingen als \u00e9\u00e9n en voegt ze samen tot \u00e9\u00e9n, waardoor je dagelijkse omzet zomaar kan verdwijnen zonder dat er ergens een foutmelding verschijnt.<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Zie dit als een vangnet. Als het verversen van je bevestigingspagina een tweede aankoop kan uitlokken, los dat dan op in plaats van erop te vertrouwen dat GA4 het wel opknapt. <\/p>\n\n<h3 id=\"3-route-ga4-through-server-side-gtm\" class=\"wp-block-heading\">3. Stuur GA4 via GTM aan de server-side<\/h3>\n\n<p class=\"wp-block-paragraph\">Configureer in de webcontainer de Google-tag met de parameter `server_container_url`. De waarde hiervan is de first-party-URL die is gekoppeld aan de servercontainer. <\/p>\n\n<p class=\"wp-block-paragraph\">Eventtags moeten dezelfde route volgen. Controleer binnen de servercontainer of de GA4-client het verzoek oppikt en stuur het vervolgens door naar de juiste property. <\/p>\n\n<h3 id=\"4-configure-google-ads-and-meta\" class=\"wp-block-heading\">4. Stel Google Ads en Meta in<\/h3>\n\n<p class=\"wp-block-paragraph\">Maak voor Google Ads de vereiste conversietag aan de server-side aan en koppel de aankoopwaarde, de valuta en het transactie-ID. Verwijder of pauzeer een oudere browserconversie voor dezelfde actie, tenzij de configuratie op een bewuste manier is ingesteld om dubbele rapportage te voorkomen. <\/p>\n\n<p class=\"wp-block-paragraph\">Meta gebruikt meestal een opzet met twee signalen: de Meta Pixel in de browser en de Conversions API (CAPI) vanaf de server. Beide versies van dezelfde actie moeten dezelfde gebeurtenisnaam en hetzelfde gebeurtenis-ID hebben. In de browser-Pixel wordt de parameter geschreven als eventID; bij de servergebeurtenis is dat event_id. Meta gebruikt dat paar om duplicaten te herkennen.   <\/p>\n\n<p class=\"wp-block-paragraph\">Daar zitten twee timingregels achter. Meta vergelijkt de twee kopie\u00ebn alleen als ze binnen 48 uur na elkaar binnenkomen, dus bij elke opzet waarbij servergegevens in vertraagde batches worden verstuurd, wordt er dubbel geteld. Als beide kopie\u00ebn ongeveer tegelijkertijd binnenkomen \u2013 wat normaal is \u2013 houdt Meta de browserversie aan.  <\/p>\n\n<p class=\"wp-block-paragraph\">Je kunt dit controleren zonder te hoeven gissen. In Meta Events Manager wordt een correct gekoppelde bestelling weergegeven als \u00e9\u00e9n event uit twee bronnen. Als er \u00e9\u00e9n event uit \u00e9\u00e9n bron wordt weergegeven, of als je verkoopcijfers ongeveer verdubbeld lijken, kloppen de naam of de ID van het event niet.  <\/p>\n\n<p class=\"wp-block-paragraph\">Genereer de ID \u00e9\u00e9n keer en gebruik die vervolgens in de gegevenslaag en in beide tags. Een nieuwe willekeurige waarde die apart in elke tag wordt gegenereerd, zorgt er niet voor dat dubbele gegevens worden verwijderd. <\/p>\n\n<p class=\"wp-block-paragraph\">E-mail of telefoon kunnen de koppeling verbeteren als de winkel de gegevens al heeft verzameld en er toestemming is om ze te gebruiken. Houd je aan de normalisatie- en hashing-vereisten van elk platform. Laat klantgegevens niet langer dan nodig in een openbare gegevenslaag staan.  <\/p>\n\n<h3 id=\"5-pass-consent-into-the-full-route\" class=\"wp-block-heading\">5. Geef toestemming door naar de volledige route<\/h3>\n\n<p class=\"wp-block-paragraph\">Tracking aan de server-side is geen vervanging voor toestemming. Het CMP moet de relevante GTM-toestemmingsstatussen instellen voordat tags advertentie- of analysegegevens verwerken. <\/p>\n\n<p class=\"wp-block-paragraph\">Voor Google kunnen dat bijvoorbeeld analytics_storage, ad_storage, ad_user_data en ad_personalization zijn. Andere platforms hebben instellingen op tag-niveau nodig die zijn gebaseerd op dezelfde keuze van de bezoeker. Controleer beide containers in plaats van er zomaar vanuit te gaan dat de servertag het juiste gedrag heeft overgenomen.  <\/p>\n\n<h3 id=\"6-test-the-complete-purchase-flow\" class=\"wp-block-heading\">6. Test het volledige aankoopproces<\/h3>\n\n<p class=\"wp-block-paragraph\">Voer GTM Preview uit voor beide containers. Test het toevoegen aan het winkelmandje via AJAX, afrekenen als gast, de belangrijkste betaalmethoden en zowel de mobiele als de desktoplay-outs. <\/p>\n\n<p class=\"wp-block-paragraph\">Controleer bij een aankoop het volgende:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>De gegevenslaag bevat \u00e9\u00e9n aankoopgebeurtenis met de juiste bestelgegevens<\/li>\n\n\n\n<li>Web GTM stuurt het verzoek naar de URL van de first-party-server<\/li>\n\n\n\n<li>De serverclient ontvangt en verwerkt de gebeurtenis<\/li>\n\n\n\n<li>GA4- en Google Ads-tags worden geactiveerd met dezelfde waarde en valuta<\/li>\n\n\n\n<li>Meta ontvangt browser- en serverevents met dezelfde naam en hetzelfde gebeurtenis-ID<\/li>\n\n\n\n<li>De opdracht verschijnt \u00e9\u00e9n keer in de test- of debugweergave van elk platform<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Het voorbeeld laat zien dat er een verzoek is verzonden, niet dat de bestellingen van de afgelopen week kloppen. Vergelijk na de lancering de WooCommerce-bestellingen met de aankopen op het platform aan de hand van het transactie-ID. <\/p>\n\n<h2 id=\"woocommerce-pitfalls-to-check-before-launch\" class=\"wp-block-heading\">Valkuilen bij WooCommerce die je voor de lancering moet controleren<\/h2>\n\n<h3 id=\"block-checkout-updates\" class=\"wp-block-heading\">Updates voor Block Checkout<\/h3>\n\n<p class=\"wp-block-paragraph\">Test de funnel opnieuw nadat je hebt gewisseld tussen de klassieke checkout en Checkout Blocks. Doe hetzelfde nadat je een checkout-plugin of betalingsintegratie hebt vervangen. De zichtbare pagina kan er bijna hetzelfde uitzien, terwijl de onderliggende events wel zijn veranderd.  <\/p>\n\n<h3 id=\"cache-on-cart-checkout-and-account-pages\" class=\"wp-block-heading\">Cache op de winkelwagen-, afreken- en accountpagina\u2019s<\/h3>\n\n<p class=\"wp-block-paragraph\">WooCommerce raadt aan om de winkelwagen-, afreken- en accountpagina\u2019s uit te sluiten van volledige paginacaching, omdat ze inhoud bevatten die specifiek is voor elke bezoeker. Voeg de orderbevestigingspagina toe aan die lijst voor trackingdoeleinden. Een gecachete pagina kan oude waarden weergeven of ervoor zorgen dat de orderdetails helemaal niet worden geladen, waardoor het aankoopevent wordt geactiveerd met ontbrekende of verkeerde gegevens.  <\/p>\n\n<h3 id=\"duplicate-native-pixels\" class=\"wp-block-heading\">Native pixels dupliceren<\/h3>\n\n<p class=\"wp-block-paragraph\">WooCommerce-uitbreidingen kunnen Google-, Meta- of TikTok-tags laden zonder GTM. Laat ze alleen staan als ze deel uitmaken van het gekozen ontwerp. Anders zet je ze even op pauze en kijk je in het netwerklogboek van de browser om te controleren of alleen de bedoelde verzoeken overblijven.  <\/p>\n\n<h3 id=\"guest-email-timing\" class=\"wp-block-heading\">Tijdstip van e-mails aan gasten<\/h3>\n\n<p class=\"wp-block-paragraph\">Als je als gast afrekent, kan het zijn dat het e-mailadres pas later verschijnt dan de gegevens uit je winkelmandje. Koppel het aan de events waarbij het veld daadwerkelijk voorkomt, meestal bij het afrekenen of bij de aankoop. Neem nooit een waarde over die misschien van een andere klant is.  <\/p>\n\n<h3 id=\"tax-shipping-and-currency\" class=\"wp-block-heading\">Belasting, verzendkosten en valuta<\/h3>\n\n<p class=\"wp-block-paragraph\">Bepaal wat een waarde precies inhoudt en gebruik die definitie overal. Als de ene tag een totaalbedrag inclusief btw doorgeeft en de andere exclusief btw, ontstaat er een discrepantie in de rapportage, zelfs als beide dezelfde bestelling registreren. <\/p>\n\n<p class=\"wp-block-paragraph\">Winkels die met meerdere valuta\u2019s werken, moeten extra worden gecontroleerd. De valutacode, de prijzen van de artikelen en de orderwaarde moeten allemaal dezelfde transactievaluta aangeven, en niet een mix van de basisvaluta van de winkel en de valuta die aan de klant wordt getoond. <\/p>\n\n<h3 id=\"redirects-reloads-and-failed-payments\" class=\"wp-block-heading\">Omleidingen, herlaadbeurten en mislukte betalingen<\/h3>\n\n<p class=\"wp-block-paragraph\">Test alle belangrijke betalingsgateways, niet alleen de standaardkaartoptie. De aankoop moet een voltooide bestelling weergeven. Herlaadtransacties mogen geen tweede conversie opleveren, en een mislukte betaling mag er niet uitzien als een verkoop.  <\/p>\n\n<h3 id=\"refunds-and-cancellations\" class=\"wp-block-heading\">Terugbetalingen en annuleringen<\/h3>\n\n<p class=\"wp-block-paragraph\">Je aankoopevent registreert de bestelling zoals die is geplaatst. Er wordt niets bijgewerkt als de klant de helft ervan terugstuurt, dus Google en Meta blijven optimaliseren op basis van het oorspronkelijke bedrag. In een winkel met hoge retourpercentages is dat verschil groot genoeg om te bepalen welke campagnes winstgevend lijken.  <\/p>\n\n<p class=\"wp-block-paragraph\">Elk platform pakt dit anders aan. GA4 doet dit via een terugbetalingsevent. Je stuurt het ordernummer door, en GA4 zoekt de bijbehorende aankoop op om de waarde daarvan af te trekken. Als de ordernummers niet overeenkomen, wordt de terugbetaling genegeerd en blijft de verkoop in je rapporten staan voor de volledige waarde. Google Ads gebruikt conversieaanpassingen, die de verkoop ofwel verwijderen ofwel de waarde ervan aanpassen. Meta corrigeert het via de Conversions API aan de hand van het ordernummer.     <\/p>\n\n<p class=\"wp-block-paragraph\">Bepaal voor de lancering wat als een verkoop telt. Schrijf het op en zorg ervoor dat elk platform dezelfde regel hanteert. <\/p>\n\n<h3 id=\"common-problems-and-where-to-look\" class=\"wp-block-heading\"><strong>Veelvoorkomende problemen en waar je moet zoeken<\/strong><\/h3>\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Wat je ziet<\/strong><\/td><td><strong>Meest waarschijnlijke oorzaak<\/strong><\/td><td><strong>Waar kun je dat controleren?<\/strong><\/td><\/tr><tr><td>De omzet van GA4 is ongeveer het dubbele van die van WooCommerce<\/td><td>Er zijn twee dingen die de verkoop be\u00efnvloeden: meestal een plug-in en hoe je je tags hebt ingesteld<\/td><td>Plaats een testbestelling en tel hoeveel aankoopevents er verschijnen<\/td><\/tr><tr><td>Meta meldt een omzet die ongeveer twee keer zo hoog is<\/td><td>The two copies of the event are not being paired<\/td><td>De evenementenmanager zou moeten zeggen: \u00e9\u00e9n evenement uit twee bronnen<\/td><\/tr><tr><td>De omzet via GA4 ligt steevast zo\u2019n 10% lager dan die via WooCommerce<\/td><td>Belasting of verzendkosten zijn bij de ene wel inbegrepen en bij de andere niet<\/td><td>Vergelijk de waarde van \u00e9\u00e9n bestelling met het totaalbedrag in WooCommerce<\/td><\/tr><tr><td>Bij \u2018Toevoegen aan winkelwagen\u2019 wordt altijd hetzelfde product weergegeven<\/td><td>De tag leest de pagina in plaats van de gebeurtenis<\/td><td>Controleer de gegevenslaag op een categoriepagina<\/td><\/tr><tr><td>Er ontbreken alleen omzetcijfers voor \u00e9\u00e9n betaalmethode<\/td><td>De klant is nooit teruggekomen via de betalingsprovider<\/td><td>WooCommerce-bestellingen filteren op betaalmethode en vergelijken<\/td><\/tr><tr><td>Bezoekers via Safari worden altijd als nieuw weergegeven<\/td><td>De limiet van zeven dagen van Safari wordt nu toegepast<\/td><td>Controleer de geldigheidsduur van de cookie na een testbestelling in Safari<\/td><\/tr><tr><td>Bij het verversen verschijnen er weer aankoopmeldingen<\/td><td>De tag is gekoppeld aan de pagina en niet aan de bestelling<\/td><td>Laad de bevestigingspagina opnieuw en kijk maar<\/td><\/tr><tr><td>De server krijgt helemaal niks binnen<\/td><td>Het serveradres ontbreekt, of het domein is nog niet actief<\/td><td>Ga naar het tabblad \u2018Netwerk\u2019 in je browser en zoek naar verzoeken aan je trackingdomein<\/td><\/tr><tr><td>De omzet is plotseling gedaald na een update van de website<\/td><td>Het type checkout is gewijzigd, of een thema-update heeft de pagina veranderd<\/td><td>Test het hele traject opnieuw<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<h2 id=\"dual-signal-or-server-only\" class=\"wp-block-heading\">Tweesignaal of alleen server?<\/h2>\n\n<p class=\"wp-block-paragraph\">\u2018Server-side\u2019 betekent niet automatisch dat de browser buiten beeld blijft. Welk model je moet kiezen, hangt af van het doel. <\/p>\n\n<p class=\"wp-block-paragraph\">Meta en TikTok raden aan om browser- en serversignalen samen te gebruiken, waarbij overeenkomende ID\u2019s worden ingezet om dubbele registraties te voorkomen. Google Ads biedt twee opties die op verschillende manieren werken. Je kunt een conversie importeren vanuit GA4, waarbij GA4 de meting uitvoert en Google Ads het resultaat overneemt. Je kunt de conversie ook rechtstreeks vanuit je servercontainer versturen.   <\/p>\n\n<p class=\"wp-block-paragraph\">De tweede optie hangt ervan af of de klik-ID van Google Ads het hele traject intact blijft. Als een betalingsprovider die ID op de terugweg uit het webadres verwijdert, heeft Google Ads niets om de verkoop aan toe te schrijven. Kies \u00e9\u00e9n optie per conversie en schakel de andere uit, want als je beide opties gebruikt zonder een plan om ze aan elkaar te koppelen, worden je gerapporteerde verkopen opgeblazen en raakt het geautomatiseerde bieden in de war.  <\/p>\n\n<p class=\"wp-block-paragraph\">  Tools voor klantbetrokkenheid zonder goede ontdubbeling moeten misschien alleen op een server worden ge\u00efnstalleerd.<\/p>\n\n<p class=\"wp-block-paragraph\">Gebruik de <a href=\"https:\/\/taggrs.io\/nl\/which-platforms-support-server-side-gtm\/\">GTM-platformchecker server-side<\/a> om de huidige plaatsing voor elke bestemming te controleren. Kopieer het patroon van het ene platform niet naar het andere. Hun API\u2019s en regels voor het verwijderen van dubbele gegevens verschillen namelijk.  <\/p>\n\n<h2 id=\"where-taggrs-fits\" class=\"wp-block-heading\">Waar TAGGRS past<\/h2>\n\n<p class=\"wp-block-paragraph\">Voor de installatie heb je twee dingen nodig die niet bij een standaard WooCommerce-installatie zitten: een betrouwbare GA4-datalayer en een plek om de GTM-container op de server te draaien.<\/p>\n\n<p class=\"wp-block-paragraph\">TAGGRS biedt beheerde server-side GTM-hosting en een first-party tagging-URL. In <a href=\"https:\/\/taggrs.io\/docs\/server-side-tracking\/woocommerce-data-layer\/\">de documentatie van de WooCommerce Data Layer-plugin<\/a> vind je info over de installatie, de web-GTM-container-ID, ondersteunde GA4-e-commerce-events en de debugmodus. <\/p>\n\n<p class=\"wp-block-paragraph\">De plug-in ondersteunt ook het optionele <a href=\"https:\/\/taggrs.io\/nl\/enhanced-tracking-script-against-ad-blockers\/\">TAGGRS Enhanced Tracking Script (ETS) v3<\/a>, dat het volledige verzoek van de browser naar de server versleutelt, zodat filterlijsten geen overeenkomsten kunnen vinden met veelgebruikte trackingmarkeringen. De toestemmingsregels blijven van kracht, en geen enkel script kan een interactie doorsturen die de winkel nooit heeft geregistreerd. <\/p>\n\n<p class=\"wp-block-paragraph\">Voor winkels die van een ander platform overstappen, volgt <a href=\"https:\/\/taggrs.io\/nl\/?p=73337\">de handleiding voor server-side tracking van Shopify<\/a> hetzelfde principe, maar dan met een ander CMS. Shopify heeft zijn eigen pixel en afrekenmodel. Bij WooCommerce moet je wat meer letten op blokken, WordPress-plugins, caching en betaalgateways.  <\/p>\n\n<h2 id=\"conclusion\" class=\"wp-block-heading\">Conclusie<\/h2>\n\n<p class=\"wp-block-paragraph\">Een tag op de bedankpagina is een onbetrouwbare plek om je omzetrapportage op te baseren. Er gebeurt gewoon te veel voordat de klant daar terechtkomt, en WordPress geeft elke plug-in de kans om zich ermee te bemoeien. <\/p>\n\n<p class=\"wp-block-paragraph\">Een WooCommerce-datalaag en server-side GTM zorgen voor een duidelijkere scheiding. WooCommerce beschrijft het event \u00e9\u00e9n keer, web-GTM stuurt dit door met de juiste toestemmingsstatus, en de servercontainer regelt de levering aan het platform. De opzet moet nog wel grondig worden getest. Maar de fouten worden in ieder geval zichtbaar in \u00e9\u00e9n pijplijn, in plaats van verborgen te blijven in een wirwar van pixels.   <\/p>\n\n<p class=\"wp-block-paragraph\"><strong><em>Wil je server-side tracking eens uitproberen in je WooCommerce-installatie?<\/em><\/strong><a href=\"https:\/\/dashboard.taggrs.io\/register\"><em> <\/em><em>Maak een gratis TAGGRS-account aan<\/em><\/a><em> of<\/em><a href=\"https:\/\/taggrs.io\/nl\/demo-aanvragen\/\"><em> <\/em><em>boek een demo<\/em><\/a><em> om je specifieke trackingbehoeften te bespreken.<\/em><\/p>\n\n<h2 id=\"faq\" class=\"wp-block-heading\">FAQ<\/h2>\n\n<h3 id=\"do-i-still-need-web-gtm\" class=\"wp-block-heading\">Heb ik Web GTM nog steeds nodig?<\/h3>\n\n<p class=\"wp-block-paragraph\">Ja. Interacties via de webwinkel beginnen in de browser. Web GTM verzamelt ze en stuurt ze door naar de server. Om backend-bestelevents rechtstreeks te versturen, is een apart maatwerkontwerp nodig.   <\/p>\n\n<h3 id=\"can-server-side-tracking-bypass-every-ad-blocker\" class=\"wp-block-heading\">Kan tracking aan de server-side elke adblocker omzeilen?<\/h3>\n\n<p class=\"wp-block-paragraph\">Nee, het is niet zeker dat het elke adblocker omzeilt. De filterlijsten van adblockers worden voortdurend bijgewerkt, dus wat vandaag nog werkt, kan volgende maand al niet meer werken. <\/p>\n\n<p class=\"wp-block-paragraph\">Wat je kunt doen, is je tracking moeilijker te herkennen maken. Bij een standaardopstelling worden gegevens verstuurd naar webadressen die voor de hand liggende trackingwoorden bevatten waar blokkers naar zoeken. Het TAGGRS Enhanced Tracking Script v3 verwijdert die patronen, zodat er niets opvallends is om op te matchen. Bij TAGGRS ligt ons gemiddelde herstelpercentage tussen 9,1% en ~30%.   <\/p>\n\n<p class=\"wp-block-paragraph\">Er blijven twee beperkingen gelden. De regels rond toestemming gelden nog steeds, dus als een bezoeker tracking weigert, mag het event helemaal niet worden verzonden. Ten tweede beschermt het script alleen gegevens die onderweg zijn van de browser naar jouw server. Als je systeem de verkoop in de eerste plaats nooit heeft geregistreerd, kunnen de gegevens ook niet worden vastgelegd. Daarom is de gegevenslaag belangrijker dan welk script je er ook bovenop zet.    <\/p>\n\n<h3 id=\"should-meta-pixel-stay-enabled-with-meta-capi\" class=\"wp-block-heading\">Moet Meta Pixel ingeschakeld blijven bij Meta CAPI?<\/h3>\n\n<p class=\"wp-block-paragraph\">Meta raadt aan om zowel browser- als serversignalen te gebruiken als beide correct kunnen worden ge\u00efmplementeerd. De namen en ID\u2019s van de events moeten overeenkomen, zodat Meta de actie maar \u00e9\u00e9n keer kan tellen. <\/p>\n\n<h3 id=\"is-woocommerce-server-side-tracking-the-same-as-shopify-server-side-tracking\" class=\"wp-block-heading\">Is server-side tracking bij WooCommerce hetzelfde als server-side tracking bij Shopify?<\/h3>\n\n<p class=\"wp-block-paragraph\">De opzet is hetzelfde: commerce-event, gegevenslaag, web-GTM, server-GTM, bestemming. WooCommerce biedt meer variatie in afrekentypes, caching en plug-ins, dus het testen kost meestal wat meer moeite. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>De standaard WooCommerce-trackingopzet bestaat uit een pixel op de site en een aankoop-tag op de ...<\/p>\n","protected":false},"author":15,"featured_media":81796,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[326],"tags":[],"class_list":["post-81801","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-side-tracking-nl"],"acf":[],"_links":{"self":[{"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/posts\/81801","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/comments?post=81801"}],"version-history":[{"count":3,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/posts\/81801\/revisions"}],"predecessor-version":[{"id":81837,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/posts\/81801\/revisions\/81837"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/media\/81796"}],"wp:attachment":[{"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/media?parent=81801"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/categories?post=81801"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/taggrs.io\/nl\/wp-json\/wp\/v2\/tags?post=81801"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}