Waarom je beste verkoopkanaal "direct verkeer" heet

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

Bij een parkeeraanbieder aan de kust kwamen in een bepaalde periode 6.602 bezoekers via Google Ads binnen. Op het boekingsdomein werd daarvan niemand herkend als Google-bezoek. Niet weinig dus, maar nul.

Elke boeking leek daar uit het niets te komen en kwam in de rapportage terecht als "direct". En op die cijfers werden de campagnes wel elke maand beoordeeld.

Wat betekent "direct" eigenlijk?

Officieel betekent het: deze bezoeker is uit het niets verschenen, 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 en dat gebeurt ook echt.

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

Wat gaat er onderweg mis?

De meeste sites die dit 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 je bezoeker als één geheel. Ze moeten dat ook wel zijn, want een browser laat de ene site niet zomaar in de gegevens van de andere kijken en daar zijn de privacyregels van moderne browsers nu juist voor bedoeld.

Daarom is er een 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 het, dan houd je één verhaal. Werkt het niet, dan begint je bezoeker op dat tweede domein aan een nieuw leven zonder verleden, en dat nieuwe leven heet "direct".

Eén underscore

Bij die parkeeraanbieder heette het pakketje in de doorstuur gl waar het _gl moest heten. Eén liggend streepje. Er ging geen foutmelding af, geen pagina bleef leeg en alles zag er gewoon werkend uit, en toch viel bij elke overstap de herkomst op de grond.

Wat het lastig maakt is dat dit soort dingen zelden bij het bouwen ontstaat. 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.

Hoe test je dit zelf?

Hier heb je alleen je eigen website voor nodig en je ogen. Kost je vijf minuten.

1. Open je site in een incognitovenster en 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 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 heb je je bevestiging.

Er is nog een aanwijzing waar weinig mensen op letten. Kijk of je eigen betaalpagina of boekingsdomein voorkomt in je lijst met verwijzende websites. Verschijnt je eigen keten in je eigen rapport als "iemand anders", dan is dat het bewijs dat de twee helften elkaar niet kennen.

Wat kost dit?

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

Bij deze parkeeraanbieder kwam er 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 en met waarde nul. Het algoritme kreeg dus maandenlang een signaal zonder waarde en zonder verband met de werkelijkheid, en optimaliseerde daar met echt budget vrolijk op door.

Wanneer haal je er iemand bij?

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 zonder overleg kan uitvoeren.

En dan is er nog een stap die vaak wordt overgeslagen. Een koppeling die afhangt van een parameter in een URL kan bij de volgende update van dat platform zo weer 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 echt hebben plaatsgevonden in plaats van van wat er toevallig overleefde in de adresbalk.

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