- Server-side tracking stuurt conversie-events, zoals aankopen, vanaf een server naar de API van het advertentieplatform in plaats van alleen vanuit een pixel in de browser.
- Wordt de aankoop verstuurd vanuit de bestelgegevens van je webshop, dan leiden adblockers en een bedankpagina die nooit laadt niet meer tot verloren verkopen.
- De browser is nog steeds nodig om het click-id op te slaan bij de landing, en de pixel kan naast de server blijven draaien met hetzelfde event_id, zodat elke aankoop één keer telt.
- Server-side tagging, zoals een server container van Google Tag Manager, begint nog steeds bij browserevents en kan dus geen aankopen terughalen die de browser nooit heeft verstuurd.
- Server-side tracking is geen manier om toestemming te omzeilen: de privacyregels gelden voor de gegevens, welke route ze ook nemen.
Bij server-side tracking worden conversie-events, zoals een aankoop, vanaf een server naar advertentieplatforms gestuurd in plaats van alleen vanuit een script in de browser van de shopper. Bij een webshop stuurt de server elke bestelling via hun API's naar Meta, TikTok of Google, zodat de verkoop ook wordt gerapporteerd als de browserpixel is geblokkeerd of nooit laadt.
Deze gids legt het verschil uit tussen een browserpixel en server-side tracking, volgt de data van de advertentieklik naar het advertentieplatform en laat zien wat een serverevent bevat. Ook komen ontdubbeling, server-side tagging, toestemming en de vraag of je webshop het nodig heeft aan bod. Voor de Shopify-instelling zelf lees je server-side tracking op Shopify.
Browserpixel versus server-side tracking
Een browserpixel is een stukje JavaScript van het advertentieplatform. Het draait op je pagina's en stuurt events vanaf het apparaat van de shopper rechtstreeks naar het platform: een paginaweergave, een toevoeging aan de winkelwagen, een aankoop op de bedankpagina. Het werkt alleen als het script laadt, draait en het platform bereikt voordat de shopper de pagina verlaat.
Server-side tracking verplaatst het verzenden naar een server. Het event kan beginnen bij gegevens die je webshop al heeft, zoals een betaalde bestelling, en de server stuurt het naar de API van het platform. Meta noemt deze API de Conversions API en TikTok noemt hem de Events API. Google Ads gebruikt enhanced conversions, die gehashte klantgegevens aan een conversie toevoegen.
- Draait in de browser van de shopper
- Stuurt events rechtstreeks naar het advertentieplatform
- Zet en leest first-party cookies, zoals _fbp voor Meta
- Stuurt niets als het script wordt geblokkeerd of de pagina niet laadt
- Draait op een server die jij of een dienstverlener beheert
- Stuurt events naar de API van het platform
- Kan beginnen bij de bestelling in je webshop
- Hangt er niet van af of de bedankpagina laadt
Beide tegelijk gebruiken geeft het platform de meest complete data. Het browserevent voegt cookies en paginacontext toe. Het serverevent komt ook aan als de browser faalt. Met een gedeeld event-id weet het platform dat het elke aankoop maar één keer moet tellen.
Hoe werkt server-side tracking?
Server-side tracking voor een webshop heeft twee helften. De eerste helft vindt plaats in de browser: wanneer een shopper via een advertentie landt, slaat een script het click-id uit de URL op. De tweede helft vindt plaats op de server: wanneer de bestelling is betaald, koppelt de server dat click-id aan de bestelling en verstuurt hij de aankoop.
De klik vastleggen
Advertentieplatforms voegen een click-id toe aan de landings-URL: fbclid voor Meta, ttclid voor TikTok, gclid voor Google Ads en msclkid voor Microsoft Ads. Het click-id is de sterkste schakel tussen een verkoop en de advertentie die die heeft veroorzaakt, dus het moet bij de eerste paginaweergave worden opgeslagen. UTM-parameters voegen de namen van campagne, advertentieset en advertentie toe in een formaat dat je zelf bepaalt.
De bestelling koppelen
De server moet dan weten welke bezoeker de bestelling heeft geplaatst. De betrouwbaarste koppeling is een waarde die met de winkelwagen mee in de bestelling terechtkomt, zoals een bezoeker-id dat op de winkelwagen is opgeslagen. Andere methoden zijn zwakker: een e-mailadres dat de bezoeker eerder op de site heeft ingevuld, of hetzelfde IP-adres en dezelfde browser kort vóór de bestelling. Elk webshopplatform biedt andere opties. In onze gids voor andere webshops staan de methoden die ROASaurus per platform gebruikt.
Het event verzenden
Ten slotte stuurt de server de aankoop naar de API van elk platform. Het event bevat de bestelwaarde, het click-id en klantgegevens waarmee het platform de persoon kan vinden die heeft geklikt. Is een platform offline of geeft het een fout terug, dan probeert een goede opzet het later opnieuw, zodat de aankoop niet verloren gaat.
Wat bevat een serverevent?
Elk platform heeft eigen veldnamen, maar een aankoopevent bevat overal dezelfde soorten gegevens. Hier is een ingekort voorbeeld voor de Meta Conversions API:
{
"data": [{
"event_name": "Purchase",
"event_time": 1793009700,
"event_id": "order-1042",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkout/thank-you",
"user_data": {
"em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
"ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
"fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
"fbp": "fb.1.1792832529000.1234567890"
},
"custom_data": { "currency": "USD", "value": 84.00 }
}]
}| Veld | Wat het is | Gehasht? |
|---|---|---|
| Eventnaam en tijdstip | Purchase, en wanneer de bestelling is geplaatst | Nee |
| Waarde en valuta | De bestelwaarde die het platform gebruikt voor ROAS en bieden op basis van waarde | Nee |
event_id | Een uniek id per event, in de browser en op de server hetzelfde, voor ontdubbeling | Nee |
| E-mailadres, telefoonnummer, naam, adres | Klantgegevens uit de bestelling, genormaliseerd en gehasht met SHA-256 | Ja |
| Click-id (fbc, ttclid, gclid) | Het id van de advertentieklik, opgeslagen toen de shopper landde | Nee |
| IP-adres en user agent | Helpen het platform het event aan een apparaat te koppelen | Nee |
Hashen verandert een e-mailadres in een vaste reeks tekens. Hetzelfde adres geeft altijd dezelfde reeks, maar de reeks laat het adres niet zien. Het platform gebruikt de gehashte waarden alleen om een match te zoeken onder zijn eigen gebruikers. Zo kan een aankoop worden gekoppeld aan de persoon die de advertentie zag of erop klikte, ook als de browser van die persoon de pixel blokkeerde.
Hoe werkt ontdubbeling?
Wanneer de pixel en de server dezelfde aankoop allebei versturen, moet het platform die één keer tellen. Beide kopieën hebben dezelfde eventnaam en hetzelfde event-id, bijvoorbeeld order-1042. Meta vergelijkt het paar en houdt één kopie, zolang de tweede kopie binnen 48 uur na de eerste aankomt.
Purchase event_id=order-1042 browserOntvangen van de pixelPurchase event_id=order-1042 serverZelfde naam en id: één keer geteldPurchase event_id=order-1043 serverDe pixel was geblokkeerd: de kopie van de server is de enigePurchase event_id=1044 serverDe browser stuurde order-1044: de id's verschillen, dus het telt twee keerDubbel tellen komt meestal door twee afzenders die geen id's delen. Een typisch geval is de eigen shop-app van een platform en een aparte trackingtool die allebei aankopen met hun eigen id's versturen. In ons helpartikel over dubbeltelling voorkomen staan de gebruikelijke oorzaken en oplossingen.
Server-side tagging versus verzenden vanuit bestelgegevens
De term server-side tracking wordt voor twee verschillende opzetten gebruikt. Beide sturen events vanaf een server, maar ze beginnen op een andere plek.
Server-side tagging, zoals de server containers van Google Tag Manager
Bij server-side tagging stuurt de browser zijn events naar je eigen server in plaats van naar elke leverancier afzonderlijk. De server container van Google Tag Manager is een bekend voorbeeld. Die draait in je eigen Google Cloud-project of in een andere omgeving die je kiest. Hij ontvangt verzoeken van de browser en zijn tags sturen de data door naar Google Analytics, Meta en andere leveranciers. Jij bepaalt welke data waarheen gaat, en de server kan op een subdomein van je site draaien.
De events beginnen nog steeds in de browser. Wordt de tag in de browser geblokkeerd, of laadt de bedankpagina nooit, dan heeft de server container niets om door te sturen. Je moet de server ook zelf draaien, betalen en bijwerken.
Verzenden vanuit bestelgegevens
De tweede aanpak laat de aankoop beginnen bij de bestelling in je webshop. De webshop meldt de betaalde bestelling via een webhook of een API aan de server, en de server stuurt die naar elk gekoppeld platform. De browser is alleen eerder nodig, om het click-id op te slaan wanneer de shopper landt.
| Server-side tagging | Verzenden vanuit bestelgegevens | |
|---|---|---|
| Waar de aankoop begint | Een tag in de browser | De betaalde bestelling in je webshop |
| Bedankpagina te vroeg gesloten | Aankoop verloren | Aankoop verstuurd |
| Tag geblokkeerd in de browser | Aankoop verloren, tenzij het first-party endpoint erdoor komt | Aankoop verstuurd |
| Betaling bij levering en externe betaalpagina's | Hangt af van de bedankpagina | Verstuurd wanneer de bestelling wordt aangemaakt of betaald |
| Events tijdens het browsen (paginaweergaven, toevoegingen aan de winkelwagen) | Ja | Heeft een aparte browsercollector nodig |
| Wie de server beheert | Jij: hosting en updates | Jij of een dienstverlener |
De twee aanpakken kunnen worden gecombineerd. Veel webshops verzamelen paginaweergaven en toevoegingen aan de winkelwagen in de browser en sturen de aankoop vanuit bestelgegevens. De aankoop is het event dat advertentieplatforms gebruiken om ROAS te rapporteren en het bieden te optimaliseren, dus dat event moet het meest compleet zijn.
Wat lost server-side tracking op en wat niet?
- Aankopen die verloren gaan doordat een adblocker de pixel blokkeerde
- Aankopen die verloren gaan doordat de bedankpagina niet laadde
- Aankopen met betaalmethoden die buiten je site worden afgerond
- Zwakke matching, doordat aan elk event gehashte klantgegevens worden toegevoegd
- Toestemming: een bezoeker die heeft geweigerd, blijft een bezoeker die heeft geweigerd
- Verschillende attributieperioden en modellen per platform
- Dubbele afzenders die verschillende event-id's gebruiken
- Click-id's die bij de landing nooit zijn opgeslagen
Toestemming blijft van toepassing
Server-side tracking is een manier om data te bezorgen, geen manier om privacyregels te omzeilen. Waar de wet toestemming vereist voor marketingcookies of tracking, geldt die eis voor de data die je verzamelt, welke route die ook naar het platform neemt. Een tracker naar je server verplaatsen verandert niets aan waarmee een bezoeker heeft ingestemd.
Attributie blijft per platform verschillend
Elk platform schrijft aankopen nog steeds toe volgens zijn eigen perioden en regels. Serverevents geven elk platform betere data, maar de totalen van Meta, TikTok en Google kunnen nog steeds samen hoger uitkomen dan de omzet van je webshop. Wil je kanalen met één set regels vergelijken, gebruik dan één attributiemodel voor allemaal, zoals de modellen in ROASaurus-attributie.
Heeft je webshop server-side tracking nodig?
Een webshop die een serieus budget uitgeeft aan betaalde social- of zoekadvertenties heeft er meestal baat bij. De zaak is het sterkst als meerdere van deze punten kloppen:
- Het advertentieplatform ontvangt duidelijk minder aankoopevents dan je webshop webbestellingen heeft. In onze gids over adblockers en tracking lees je hoe je dit verschil meet.
- Veel van je bezoekers gebruiken Safari op iPhone of Mac, waar cookies die door scripts zijn gezet maximaal 7 dagen meegaan. Zie Safari ITP en advertentietracking.
- Shoppers kopen vaak dagen na de eerste advertentieklik.
- De betaling wordt buiten je site afgerond, of bestellingen worden later betaald, zoals bij betaling bij levering of bankoverschrijving.
- Je optimaliseert campagnes op aankopen of aankoopwaarde, dus het platform heeft elke verkoop nodig om van te leren.
Zo verandert een verschil de beslissingen in de praktijk. Een voorbeeldwebshop heeft in een maand 1,000 webbestellingen. De Meta-pixel meldde 820 Purchase-events, dus 18% van de bestellingen bereikte Meta nooit vanuit de browser.
De break-even-ROAS van de webshop is 2.5 en Ads Manager toont op basis van pixeldata een ROAS van 2.3. Op die cijfers verliezen de campagnes geld. Als bestellingen uit advertenties met hetzelfde percentage van 18% werden gemist, is de echte ROAS ongeveer 2.3 ÷ 0.82 = 2.8, en dat ligt boven break-even. Dat is een bovengrens, omdat niet elke ontbrekende bestelling uit een advertentie kwam. Het laat toch zien hoe een trackinggat een winstgevende campagne als verlieslatend kan laten lijken.
Server-side tracking is minder belangrijk voor een webshop die niet adverteert of heel weinig aan advertenties uitgeeft.
Hoe ROASaurus server-side events verstuurt
ROASaurus legt bij de landing 19 click-id's en zes UTM-velden vast en slaat ze op met een first-party bezoeker-id. Het stuurt elke aankoop uit de betaalde bestellingen van je webshop naar Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll en Outbrain. Bij Shopify worden Google Ads-conversies verstuurd vanuit de Shopify-checkout. Browserpixels kunnen naast de serverevents draaien met hetzelfde event-id, en Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin en Spotify ontdubbelen ze. Elke levering en het antwoord van het platform staan in de Event log.
Lees meer op de pagina over server-side tracking, of zoek je webshop op de pagina integraties.
Bronnen
- Meta for Developers: Conversions API
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Customer Information Parameters
- Google for Developers: An introduction to server-side tagging
- Google Ads Help: About enhanced conversions