Waarom je beste verkoopkanaal "direct verkeer" heet

31 augustus 2026 · 5 minuten lezen · door Koen van der Poel

Er is één regel in Google Analytics waar je altijd even bij stil moet staan, en dat is de regel "direct". Officieel betekent die: deze bezoeker is uit het niets verschenen. Hij heeft je webadres uit zijn hoofd ingetypt, of uit een bladwijzer geklikt, en er is geen verwijzing waar we hem aan kunnen ophangen.

Dat bestaat, dat gebeurt echt. Maar als "direct" jouw grootste converterende kanaal is, en zeker als het groter is dan de kanalen waar je geld in stopt, dan klopt het bijna nooit. Dan kijk je niet naar mensen die je webadres uit hun hoofd kennen. Dan kijk je naar bezoekers van wie de herkomst onderweg is kwijtgeraakt, en "direct" is gewoon de bak waar Analytics alles in gooit wat het niet thuis kan brengen.

Wat er onderweg gebeurt

De meeste sites die dit probleem hebben, hebben het omdat er twee domeinen in het spel zijn. Je informeert mensen op je eigen site, maar de bestelling, de boeking of de aanvraag gebeurt ergens anders: een boekingsplatform, een reserveringssysteem, een aparte webshop, een afsprakenmodule.

Voor Google Analytics zijn dat twee verschillende websites, ook al voelt het voor de bezoeker als één. Sterker nog, ze moeten wel twee verschillende websites zijn, want een browser laat de ene site niet zomaar in de gegevens van de andere kijken. Dat is precies waar de privacyregels van moderne browsers voor bedoeld zijn.

Er is daarom een expliciete oplossing voor: bij elke doorklik naar dat tweede domein plakt Analytics een pakketje informatie aan de URL, zodat de tweede site weet dat het om dezelfde bezoeker gaat en waar die vandaan kwam. Dat pakketje heet _gl. Werkt dat, dan houd je één verhaal. Werkt het niet, dan begint de bezoeker op het tweede domein aan een nieuw leven, zonder verleden, en dat nieuwe leven heet "direct".

Eén underscore

Bij een parkeeraanbieder aan de kust liep dit precies zo mis. De boekingen gaan daar via een platform op een ander domein. In een periode kwamen 6.602 bezoekers via Google Ads binnen, en op het boekingsdomein werd daarvan er nul herkend als Google-bezoek. Niet weinig. Nul.

Elke boeking leek uit het niets te komen. En op die cijfers werden de campagnes wél elke maand beoordeeld.

De oorzaak was dat het pakketje in de doorstuur gl heette waar het _gl moest heten. Eén liggend streepje. Er ging geen foutmelding af, geen pagina bleef leeg, alles zag er functionerend uit, en toch viel bij elke overstap de herkomst op de grond.

Wat het extra verraderlijk maakt: dit soort dingen ontstaat zelden bij het bouwen. Het ontstaat bij een update van het platform aan de andere kant, waar jij niet bij bent en waar niemand bedenkt dat er een parameter meeging.

De test die vijf minuten kost

Hiervoor heb je alleen je eigen website nodig en je ogen.

1. Open je site in een incognitovenster. Accepteer de cookies, want zonder toestemming gebeurt dit hele mechanisme sowieso niet.
2. Klik door naar het punt waar je bezoeker naar dat andere domein gaat: de boekingsknop, de bestelknop, de aanvraagmodule.
3. Kijk in de adresbalk zodra je op het tweede domein bent aangekomen.
4. Staat er ergens in die URL _gl= met een lange reeks tekens erachter? Dan werkt de koppeling.
5. Staat het er niet, of staat er iets dat er bijna zo uitziet, dan heb je hem gevonden.

Doe daarna nog de controle vanaf de andere kant. Kijk in Analytics naar je transacties of je aanvragen, uitgesplitst naar kanaal, over de afgelopen drie maanden. Staat "direct" daar bovenaan, en gaat het om meer dan pakweg twintig procent van je conversies, dan is dat je bevestiging.

Nog een aanwijzing waar weinig mensen op letten: kijk of je eigen betaalpagina of boekingsdomein voorkomt in je lijst met verwijzende websites. Als je eigen keten in je eigen rapport als "iemand anders" verschijnt, is dat het bewijs dat de twee helften elkaar niet kennen.

Waarom dit meer kost dan een verkeerd rapport

Een verkeerd toegewezen boeking is niet alleen een schoonheidsfoutje in je maandoverzicht. Google Ads optimaliseert op wat jij terugmeldt. Meld je niets terug over waar je boekingen vandaan komen, dan gaat het algoritme sturen op wat het wél ziet, en dat is meestal iets goedkoops en nutteloos.

Bij deze parkeeraanbieder kwam daar nog bij dat de omzet per boeking vijftig procent te laag werd doorgegeven, en dat het account stuurde op een teller die feitelijk paginaweergaven telde: bijna het dubbele van het aantal echte boekingen, met waarde nul. Het algoritme kreeg dus maandenlang een signaal zonder waarde en zonder verband met de werkelijkheid, en optimaliseerde daar met volle overtuiging op door, met echt budget.

Wanneer je hier iemand bij haalt

De test hierboven doe je zelf, en het antwoord is binnen vijf minuten hard. Het repareren is een ander verhaal, want dat gebeurt meestal aan de kant van het platform waar jij niet bij kunt. Dan heb je iemand nodig die precies kan opschrijven wat er moet gebeuren, in taal die een ontwikkelaar aan de andere kant kan uitvoeren zonder overleg.

En dan is er nog een stap die de meeste bureaus overslaan. Een koppeling die van een parameter in een URL afhangt, kan bij de volgende update van dat platform opnieuw omvallen. Duurzamer is om de echte boekingen rechtstreeks vanuit het systeem terug te melden aan Google Ads, buiten de browser om. Vanaf dat moment leert het algoritme van boekingen die daadwerkelijk hebben plaatsgevonden, en niet van wat er toevallig overleefde in de adresbalk.

Meer over hoe wij een meetketen nalopen staat op de pagina over meten en data. De volledige case staat bij de cases.