Server-side vs. client-side tracking

Wat is het verschil, in één zin?

Client-side tracking ziet context; server-side tracking ziet de waarheid. De browser kent de UTM-parameters, de referrer, het apparaat en de pagina – en verliest events aan blockers. Je back-end weet wat er echt gebeurde – een abonnement startte, een betaling mislukte – en weet niets over hoe de gebruiker daar kwam. Deze gids gaat over waar je meet. Wat je trackt – naamgeving en de lijst met events om mee te beginnen – staat in het trackingplan voor start-ups; waarom de data überhaupt first-party hoort te zijn, lees je in first-party data en tracking. Beide helften horen in één trackingplan.

Wat ziet client-side tracking – en wat mist het?

Aan de clientkant zit de context. De SDK in de browser legt UTM-parameters, de referrer, de landingspagina, het apparaat en het sessiegedrag vast – alles wat attributie en funnelanalyse nodig hebben. Wat hij mist, zijn hele gebruikers: volgens GWI-data die Backlinko bundelde, gebruikte 29,5% van de internetgebruikers wereldwijd in Q2 2025 minstens af en toe een adblocker – zo’n 1,77 miljard mensen. Veel blockers houden analysescripts samen met advertenties tegen, dus een meetbaar deel van je client-side events wordt nooit verstuurd.

Ook zonder blocker maakt Safari client-side tracking lek. Volgens de ITP-documentatie van WebKit beperkt Safari cookies die via JavaScript worden gezet tot een looptijd van zeven dagen en wist het alle andere opslag waarin scripts kunnen schrijven – localStorage, IndexedDB – na zeven dagen Safari-gebruik zonder interactie met je site. Zodra die periode van zeven gebruiksdagen voorbij is, ziet een terugkerende bezoeker eruit als gloednieuw en raak je de identiteit kwijt. Het verlies is meetbaar: toen Plausible eind augustus 2021 in een test zijn eigen tellingen vergeleek met Google Analytics op een site die trending was op Hacker News en Reddit, miste Google Analytics 58,67% van de bezoekers – een extreem geval met een technisch publiek; Plausible noemt eerder onderzoek dat de blokkering onder de 10% plaatst op lifestylesites en boven de 25% op sites met een technische focus.

Wat ziet server-side tracking – en wat mist het?

Bij server-side tracking meldt je back-end statuswijzigingen aan de events-API: subscription_started, payment_failed, plan_changed. Die events gebeuren op je servers, niet in de browser – ze daar vastleggen is geen omweg, het is de eerlijke bron. Er zit geen blocker in de weg, geen opslaglimiet laat ze verlopen, en de telling klopt met je database omdat ze uit je database komt. Een server-side event is leidend omdat het vastlegt wat je systeem deed, niet wat een browser wist door te geven. De blinde vlek is context: je back-end heeft geen idee welke campagne, referrer of welk apparaat de gebruiker binnenbracht – die context heeft altijd alleen aan de clientkant bestaan.

Client of server: welke events gaan waarheen?

Hoe verdeelt een klein team het?

• Alles wat met geld te maken heeft – proefperiodes, abonnementen, betalingen, terugbetalingen – gaat server-side. Als churn of MRR moet kloppen, is de server de bron van waarheid.
• Alles wat met attributie te maken heeft – paginaweergaven, campagnes, referrers – blijft client-side. Die context valt later niet meer te reconstrueren.
• Identificeer op beide paden met dezelfde user-ID, zodat funnels aan elkaar sluiten en A/B-tests met weinig verkeer elke gebruiker over apparaten heen aan één variant toewijzen.
• Accepteer het verschil. Clienttellingen vallen per definitie te laag uit; gebruik ze voor de richting, en serverevents voor alles wat je rapporteert.

Waarom kloppen de twee getallen nooit?

Draai je beide, dan wijken de tellingen van elkaar af – voorgoed. Het clientgetal valt te laag uit omdat blockers en ITP events opeten; het servergetal mist de context om te zeggen waar gebruikers vandaan kwamen. Dit is geen bug om te repareren, maar een eigenschap om te benoemen: verwacht een blijvend verschil tussen clientanalyses en de waarheid van de server, ken de ruwe omvang ervan voor jouw publiek en jaag er niet langer achteraan. Rapporteer elk getal vanaf zijn eerlijke kant – attributie en de richting van je funnel uit clientdata; alles wat in een pitchdeck of op een factuur belandt – churnrate, MRR, actieve abonnementen – berekend uit serverevents. Engagementplatforms als Iterable en Ortto accepteren om dezelfde reden beide bronnen.

Hoe pakt fromHello het aan?

fromHello gaat standaard uit van de verdeling. De JS/TS-SDK trackt client-side en houdt een offline queue bij in localStorage – events die tijdens een verbroken verbinding afgaan, blijven bewaard en worden opnieuw verstuurd zodra de browser weer online is – terwijl dezelfde events-API ook verzendingen vanaf de server accepteert, zodat subscription_started rechtstreeks uit je back-end komt, met een API-sleutel. Beide paden schrijven naar één profiel: de attributie die de SDK vastlegde en de omzetevents die je server stuurde, beschrijven dezelfde persoon. Segmenten, journeys en analyses lezen uit dat ene profiel – je verdeelt de instrumentatie, niet de identiteit.