Requesttypes en statussen in je logs begrijpen

Elke rij in je requestlogs is één HTTP-request die je tagging-server heeft bereikt. Zonder labels zou dat niet meer zijn dan een muur van URL's en statuscodes. Measurebase deelt elke request in naar wat hij werkelijk is, zodat een echte conversie, een stukje GTM-techniek en een scanner die zoekt naar een .env bestand er in de tabel niet hetzelfde uitzien.

De requesttypes

Elke request valt in precies één van deze categorieën:

• Enhanced tracking script — een request voor het Enhanced-loaderbestand zelf
• Ad-block protected request — verkeer dat via Enhanced Ad Blocker Protection wordt doorgesluisd met maskering
• Google Ads (ad-block protected) — dezelfde maskering, specifiek voor requests bestemd voor de advertentiedomeinen van Google
• GTM tracking script — een request voor het script van je GTM-container zelf
• Google tag — een gtag.js-achtige hit die rechtstreeks naar je server-container wordt gestuurd
• GA4 — een Google Analytics 4-meetrequest
• GTM preview mode — verkeer dat ontstaat terwijl je debugt in de eigen Preview-modus van GTM, geen echte bezoekersactiviteit
• Service worker — een request die van een service worker in de browser komt in plaats van van een paginalading
• Other — alles wat geen echte tag afvuurt en geen echte data verzamelt: ruis van scanners en bots, crawlerbestanden als robots.txt en favicon.ico, pogingen om kwetsbaarheden te vinden op paden als .env, en vergelijkbaar achtergrondverkeer. Requests in deze categorie worden nooit gefactureerd en nooit als echte verkeersbron geteld.

Statuslabels — en wanneer een 400 geen fout is

Elke request krijgt ook een statuslabel op basis van zijn HTTP-responscode:

• Active (groen) — elke respons onder de 300, een normale geslaagde request
• Pending (oranje) — een 429 (rate-limited), of een 400 waarvan Measurebase heeft vastgesteld dat hij onschuldig is (zie hieronder)
• Error (rood) — al het overige

Een status die geen 2xx is betekent niet altijd dat er iets misging. Measurebase herkent meerdere patronen waarbij de request zelf in orde is en er geen echte data verloren ging:

• Nieuwe pogingen van GA4/gtag — een 400 die direct wordt gevolgd door een geslaagde request voor hetzelfde measurement-ID is de browser die het opnieuw probeert met een gecorrigeerde payload, geen echte fout. Measurebase koppelt de twee en markeert de oorspronkelijke 400 als onschuldig. Draait hetzelfde measurement-ID over de hele linie op een gezond slagingspercentage, dan worden ook oudere, niet-gekoppelde 400's ervan vrijgegeven, ook buiten het korte koppelvenster.
• Redirects van de Google Ads-relay — een 3xx van de Ads-conversierelay is de redirect die verloopt zoals bedoeld.
• De service worker van Enhanced Conversions — een 304 is niet meer dan de eigen cache van de browser die bevestigt dat er niets is veranderd.
• Bekende pogingen van bots en scanners — paden als /favicon.ico, .env, of wp-login.php zijn geautomatiseerde achtergrondruis, welke status ze ook teruggeven.
• Verkeer uit GTM Preview — nooit een meting van een echte bezoeker, dus geen enkele statuscode erop staat voor verloren data.

Elk van deze krijgt een label "NO DATA LOST" naast het statuslabel, zodat het duidelijk te onderscheiden is van een request die echt misging — je hoeft er geen tooltip voor open te klappen.

Filteren op status

Het statusfilter op je requestlogs geeft je vijf weergaven: Alle statussen, 2xx geslaagd, 3xx redirect, 4xx clientfout, en 5xx serverfout. Ben je echte problemen aan het uitzoeken, begin dan bij 5xx — alles daar is een echte server-side storing, nooit een onschuldige nieuwe poging.