Zien hoeveel mensen op dit moment door je site navigeren klinkt als een premium dashboardfunctie, maar je kunt het bouwen met onderdelen die je al hebt. Het interessante deel is niet de teller: het is de signaalinterpretatie zonder jezelf voor de gek te houden. Laten we naar de echte opzet gaan.
Stap 1: kies de databron voordat je iets aanraakt
Er zijn drie wegen en ze zijn niet uitwisselbaar:
- Tag van de analytics-provider (GA4, Matomo, Plausible). Geen ontwikkeling, maar de aggregatielatentie zorgt ervoor dat het “realtime” van GA4 niet direct is: volgens de officiële documentatie van Google weerspiegelen realtime-rapporten activiteit van de afgelopen 30 minuten en kunnen gegevens later worden geconsolideerd.
- Serverlogs. Dit is de meest betrouwbare data, inclusief bots en downloads die JavaScript nooit ziet. Vereist toegang tot het log en een parser.
- Streaming vanaf de site zelf (WebSocket of Server-Sent Events). Volledige controle, maar jij draagt de infrastructuurkosten.
Voor een mkb-bedrijf met WordPress is weg 1 voldoende. Voor het auditen van bot-crawling of abnormale verkeerspieken is weg 2 verplicht.
Stap 2: activeer de live-weergave in GA4 en controleer deze
- Ga naar Beheren → Gegevensstromen en bevestig dat de tag wordt geactiveerd (browserextensie of het DebugView-rapport).
- Open Rapporten → Realtime en navigeer zelf door een URL met parameter ?utm_source=test.
- Controleer of je met die bron verschijnt. Als je niet verschijnt, ligt het probleem bijna altijd in een toestemmingsvoorwaarde die de tag blokkeert, niet in de tag.
De fout die bijna iedereen de eerste keer maakt
Een typisch geval: je installeert het snippet in de header, de teller van actieve gebruikers toont 0 en je raakt in paniek. In werkelijkheid heeft de cookieblokkering het script geweigerd of serveert een cache-plugin HTML met de tag dubbel en uitgeschakeld. Voordat je iets opnieuw installeert, open je de browserconsole en zoek je de aanvraag naar collect of het endpoint van je tool. Als die niet verschijnt, is het een laadprobleem; als die met 204 verschijnt, werkt de meting en zit de fout in de interne filtering.
Stap 3: bouw je eigen dashboard met de logs (optioneel maar onthullend)
Als je verzoeken per seconde wilt zien zonder afhankelijk te zijn van derden, is een terminalcommando genoeg om te beginnen:
tail -f /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
Dit geeft je de IP’s met de meeste verzoeken in het venster dat je open laat. Het dient om in seconden een agressieve scraper te detecteren, maar het onderscheidt geen gebruikers van bots of sessies: daarvoor heb je aggregatie per tijdvenster nodig en een Grafana-achtig dashboard dat het log leest.
Wat realtime je niet gaat vertellen
Hier is eerlijkheid gepast: live verkeer is niet geschikt voor het meten van conversies of attributie. Een gebruiker die koopt, kan drie dagen geleden via een ander kanaal zijn gekomen. Het onderscheidt ook niet goed tussen een menselijk bezoek en een bot met vervalste user-agent. En als je site veel verkeer heeft, verbruikt elke seconde verversen resources en toont het je ruis, geen trend.
Volgens studies in de webanalysesector correspondeert een relevant deel van het verkeer dat in live-dashboards als “direct” wordt geclassificeerd met intern verkeer, monitoringtools en verkeerd gelabelde links. Filter je eigen IP en dat van je team voordat je conclusies trekt.
Checklist voor minimale configuratie
- Tag die laadt in alle templates, inclusief de bedankt-pagina.
- Filter voor interne IP’s actief.
- Aangepaste gebeurtenis voor klikken op CTA’s, ook zichtbaar in het live-rapport.
- Melding (e-mail of Slack) wanneer de datastroom meer dan 30 minuten stopt: een uitgevallen tag komt vaker voor dan een uitgevallen server.
- Wekelijkse controle van het log om te vergelijken met de tool: als ze sterk uiteenlopen, zijn er bots of scriptblokkering.
Hiermee heb je functionele live-monitoring en, belangrijker nog, je weet wanneer je dat wat je ziet moet wantrouwen.