LLM-verkeer is een blinde vlek in je analytics. Zo zit het.

Je AI-kanaal groeit. Je analytics houden het tempo niet bij.

ChatGPT, Gemini, Claude, Perplexity en andere LLM’s genereren meer verkeer dan je denkt. Het volume komt niet druppelsgewijs binnen, het versnelt in een tempo dat gevestigde kanalen begint te evenaren. Sommige analisten schatten dat AI-referralverkeer tegen 2028 traditioneel zoekverkeer kan voorbijstreven. Wij denken dat dit op sommige sites al gebeurt.

Dit artikel legt uit waarom, aan de hand van praktijktests op mobiele en desktopapparaten, debugmodi van browsers, server-side request logging en andere technieken op drie toonaangevende LLM-platforms: ChatGPT, Gemini en Claude.

Begrijp eerst waar je gebruikers zich bevinden

Voordat we ingaan op wat er breekt en wanneer, is het nuttig om de schaal van het probleem per apparaattype te begrijpen.

Mobiel is het dominante platform voor webverkeer. Volgens Cloudflare Radar, dat HTTP-verzoeken volgt over een netwerk dat meer dan 20% van al het wereldwijde webverkeer verwerkt, zijn mobiele apparaten goed voor ongeveer 50% van alle webverzoeken. Dat cijfer kun je het beste als ondergrens beschouwen: het netwerk van Cloudflare draagt een aanzienlijk volume aan API-verkeer, B2B-diensten en developer tooling, wat allemaal zwaar leunt op desktop. Consumentgericht webverkeer is aanzienlijk hoger op mobiel. In de GA4-accounts waarmee we dagelijks werken, is mobiel doorgaans goed voor tussen de 70% en 90% van de totale sessies. Desktopverkeer is reëel, maar secundair.

Mobiel is waar LLM-attributie het meest compleet faalt. Het apparaat dat het grootste deel van je publiek gebruikt, is het apparaat waar de meting het meest gebroken is.

Wat we hebben getest

Om precies te begrijpen waar tracking breekt, hebben we praktijktests uitgevoerd op mobiele en desktopapparaten met de native apps en webbrowsers voor ChatGPT, Gemini en Claude. De tests werden uitgevoerd op een iPhone met de nieuwste versie van iOS, een Androidapparaat met de nieuwste versie van Android, een Mac met de nieuwste versie van macOS en een Windows-pc met de nieuwste versie van Windows.

Voor elk scenario hebben we gekeken of UTM-parameters aanwezig waren, of er een referrer werd doorgegeven aan de bestemmingssite, en of de sessie-identiteit behouden bleef wanneer een gebruiker vanuit de LLM-interface naar een standaardbrowser ging.

Dit is wat we hebben gevonden.

De resultaten in één oogopslag

Mobiel: waar het meeste verkeer zit en waar tracking breekt

De tabel hierboven vertelt het verhaal vrij duidelijk. Voor mobiele apps is er weinig tot geen traceerbaar signaal. Maar waarom?

Het antwoord is de webview, en het is de moeite waard om te begrijpen wat dat eigenlijk betekent voordat we ingaan op de platformspecifieke details.

Wanneer een gebruiker op een link tikt binnen een mobiele LLM-app, of dat nu ChatGPT, Gemini of Claude is, opent de link meestal in een geïsoleerde in-app browser genaamd een webview. Deze webview deelt geen cookies, sessiegegevens of identiteit met de native browser van het apparaat. Welke trackingstatus ook binnen die webview wordt ingesteld, blijft daar opgesloten.

Het praktische gevolg: wanneer een gebruiker klaar is met browsen in de LLM-app en later zijn gewone apparaatbrowser opent om verder te onderzoeken of te converteren, is er geen continuïteit. Geen gedeelde identiteit. Geen overdracht. Dat bezoek wordt niet-geattribueerd direct verkeer.

ChatGPT op mobiel is het best traceerbare van de geteste opties. De app geeft utm_source=chatgpt.com door op uitgaande links, en technisch is er een pad naar attributie, maar dat hangt af van een reeks gebeurtenissen die niet erg waarschijnlijk is. Om die UTM helemaal tot aan een conversie te laten overleven, zou de gebruiker op de link in ChatGPT moeten tikken, in de in-app webview terechtkomen, en vervolgens expliciet op “Open in Browser” moeten tikken om de sessie over te dragen aan zijn native browser voordat hij verder gaat. Merk op dat deze reis alleen op Androidapparaten de sessie behoudt. Op iOS breekt zelfs deze workaround de sessiecontinuïteit.

In de praktijk ontdekt iemand je in ChatGPT. Ze lezen over je, tikken misschien kort door naar je site en gaan verder. Later, misschien een uur later, misschien twee dagen later, zoeken ze naar je op Google, of typen ze gewoon je URL direct in, en dan kunnen ze beginnen met converteren. Die sessie draagt geen spoor van de ChatGPT-interactie die het geheel startte. De UTM is weg. De referrer is weg. GA4 registreert het als direct of organic search, en ChatGPT krijgt geen krediet. En ja, dit is ook waar als je trackingfuncties zoals Google Signals hebt ingeschakeld in je GA4-property.

Gemini en Claude op mobiel geven in geen enkel getest scenario UTM-parameters of een referrer door. Sessies van deze platforms landen als puur direct verkeer. Er is geen signaal dat ze terugkoppelt aan de LLM die ze heeft aangedreven.

Een nuance die het vermelden waard is: als een gebruiker een site ontdekt en binnen de webview converteert, is er interne sessiecontinuïteit binnen die geïsoleerde context. De webview behoudt wel zijn eigen cookies tussen sessies, dus een reis die volledig binnen de app wordt voltooid, is in theorie meetbaar. Standaardbeperkingen van cookietracking blijven van toepassing, en hoe vaak gebruikers een volledige conversielus binnen een app-webview voltooien, is op zich een open vraag die het verkennen waard is.

Desktop: beter, maar nog steeds inconsistent

Desktop biedt gunstigere trackingvoorwaarden dan mobiel, maar het beeld is nog steeds gefragmenteerd, afhankelijk van welk platform en welke interface je gebruikt.

In tegenstelling tot mobiel vangen desktop LLM-apps links niet in geïsoleerde webviews. Ze overhandigen uitgaande links direct aan de standaardbrowser van de gebruiker. Het isolatieprobleem van de webview geldt dus niet op desktop. Wat wel geldt, is of het platform de moeite neemt om UTM’s of een referrer door te geven, en op dat vlak zijn de resultaten gemengd.

ChatGPT op desktop (native app) geeft utm_source=chatgpt.com door op uitgaande links, het meest betrouwbare desktopscenario van alle geteste platforms. ChatGPT in de browser geeft een referrer door, maar geen UTM’s.

Gemini heeft geen desktop-app op Mac of Windows. Al het desktopgebruik van Gemini verloopt via de browser. Gemini in de browser geeft een referrer door, maar geen UTM’s, hetzelfde verhaal als browsergebaseerde ChatGPT.

Claude is de zwakste presteerder in alle desktopscenario’s. De native desktop-app geeft geen UTM’s en geen referrer door. Claude in de browser geeft beide ook niet door. Elke sessie van Claude op desktop landt als volledig niet-geattribueerd direct verkeer, ongeacht hoe de gebruiker er is gekomen.

Het stapeleffect: zelfs goede attributie haalt niet altijd de conversie

Stel even voor dat de tracking werkt. De UTM is ingevuld, de referrer is aanwezig, de sessie is toe te schrijven. Je zou kunnen denken dat je gedekt bent.

Dat ben je niet.

Het pad van een LLM-interactie naar een voltooide conversie is zelden een enkele sessie. Een gebruiker ontdekt iets via ChatGPT op zijn telefoon overdag. Ze klikken op de link, landen op de pagina, browsen een paar minuten. Ze vertrekken zonder te converteren. Twee dagen later komen ze terug op hun laptop om de zaak af te ronden. Op dat moment is de oorspronkelijke UTM misschien verlopen, is het apparaat misschien anders, en zijn de cookies misschien verdwenen.

Cookievervaldatum, cross-device reizen en multi-sessie-paden breken elk onafhankelijk de attributie. Samen zorgen ze ervoor dat zelfs de fractie van LLM-verwezen sessies die correct worden getagd op het eerste contactpunt, zelden krediet zal krijgen voor de uiteindelijke conversie.

Dit is geen probleem dat uniek is voor LLM-verkeer. Maar het slaat hier harder toe omdat door LLM ondersteunde ontdekking doorgaans vroeger in de overwegingsreis plaatsvindt, mensen zijn aan het onderzoeken en verkennen, nog niet klaar om te kopen. De kloof tussen dat eerste door AI beïnvloede bezoek en de uiteindelijke conversie is langer dan een typisch click-to-conversion-venster bij betaalde kanalen, wat het cross-device-probleem verergert.

Wat dit betekent voor je data

Laten we er wat ruwe cijfers op zetten. Het doel is geen valse precisie: het is een redelijke range die je helpt de omvang te begrijpen van wat je waarschijnlijk mist.

Begin met de apparaatverdeling. Cloudflare Radar stelt het wereldwijde mobiele webverkeer op ongeveer 50% van alle HTTP-verzoeken, en dat cijfer is aan de lage kant voor consumentgerichte doelgroepen omdat het netwerk van Cloudflare een zware mix van API- en developerverkeer draagt. In de GA4-accounts waarmee we werken, ligt mobiel doorgaans tussen de 70% en 90% van de sessies. We gebruiken hier 70% om conservatief te blijven.

Dan is er de vraag hoe mensen LLM’s daadwerkelijk gebruiken op hun telefoon. Niet iedereen gebruikt de native app. Sommigen openen ChatGPT, Gemini of Claude via hun mobiele browser, en browsergebruik is betekenisvol beter traceerbaar. Twee aannames omsluiten de range.

Basisaannames die in beide cases worden gebruikt:

• Verdeling mobiel/desktop: 70% mobiel, 30% desktop
• Overlevingspercentage app-signaal: 20% van de klikken in mobiele apps geeft met succes een bruikbaar signaal door (bijv. een Androidgebruiker die op “Open in Browser” tikt, of een conversie die binnen de webview plaatsvindt)
• Verlies op conversiepad: 25% boete toegepast voor signaalverlies door cross-device sprongen en verlopen cookies
• Google AIO-factor: Een deel van de door AI beïnvloede ontdekking vindt nu plaats via Google AI Overviews en AI Mode, die GA4 registreert als standaard organische zoekresultaten zonder manier om dit te scheiden

De range

De bovenstaande aannames zijn schattingen, voel je vrij om getallen in te voeren die je eigen publiek of aannames beter weerspiegelen. Gebruik een andere mobiele verdeling, een andere app-naar-browser-verhouding, een ander verliespercentage. Het model is niet bedoeld om precies te zijn. Het is bedoeld om te laten zien dat, ongeacht welke redelijke getallen je kiest, de conclusie dezelfde is: er is sprake van aanzienlijke onderrapportage, en de kloof is groot genoeg om ertoe te doen.

Met onze aannames loopt de range van ongeveer 2,5x aan de optimistische kant tot 5x aan de meer pessimistische kant, en potentieel hoger als je door LLM beïnvloede Google organic-sessies meerekent die met standaardanalytics onmogelijk te scheiden zijn.

Als je dashboard laat zien dat 1,5% van je sessies afkomstig is van LLM’s, is het waarschijnlijk dat ergens tussen de 4% en 8% van die sessies daadwerkelijk van LLM’s kwam, en dat aantal groeit snel. Dat is een volledig kanaal dat zich verschuilt in je rapporten Direct en Organic.

Kun je het oplossen?

Gedeeltelijk. Er is geen volledige oplossing, maar er zijn betekenisvolle verbeteringen beschikbaar voor teams die bereid zijn te investeren in geavanceerdere analytics en tracking.

Server-side tracking en request logging kunnen signalen vastleggen die client-side JavaScript volledig mist. Apparaat-fingerprinting-tools kunnen probabilistische identiteit handhaven tussen webview- en browsercontexten op hetzelfde apparaat, waardoor ze de isolatiekloof gedeeltelijk overbruggen die standaard cookiegebaseerde tracking niet kan overbruggen. Geen van beide benaderingen brengt je tot volledige meting, en geen van beide lost het cross-device-probleem op zonder een ingelogde gebruikersstatus om beide sessies aan elkaar te verankeren.

Het eerlijke antwoord: je zult nooit volledige meting bereiken. De architectuur van mobiele besturingssystemen, het referrerbeleid van LLM-platforms en de aard van multi-sessie cross-device reizen werken er allemaal tegen. Maar dat is niet het belangrijkste om over dit kanaal te begrijpen.

Het doel van meten is geen perfecte telling van elke conversie: het is een richtinggevend begrip dat goed genoeg is om beslissingen te nemen. Je hoeft niet elke door LLM ondersteunde conversie toe te schrijven om te weten dat dit kanaal groeit, dat je aandeel erin iets is dat je kunt beïnvloeden, en dat de relatieve veranderingen die je aanbrengt in je AI-zichtbaarheidsstrategie zich zullen vertalen in je cijfers. Als je door LLM verwezen verkeer verdubbelt nadat je je content hebt geherstructureerd voor betere AI-citaties, is die beweging betekenisvol, ongeacht of je elke verkoop kunt terugleiden naar een specifieke chatsessie.

Dit artikel is geen pleidooi om meten op te geven. Het is een pleidooi om niet toe te laten dat imperfecte meting een excuus wordt voor inactiviteit. De teams die AI-zichtbaarheid nu als een serieus groeikanaal behandelen, niet wanneer de attributie schoner is, niet wanneer GA4 bijtrekt, maar nu, zijn degenen die een voorsprong opbouwen die moeilijk in te halen zal zijn.

Methodologie

De tests werden uitgevoerd op een iPhone met de nieuwste versie van iOS, een Androidapparaat met de nieuwste versie van Android, een Mac met de nieuwste versie van macOS en een Windows-pc met de nieuwste versie van Windows. Linux is niet direct getest, maar er wordt verwacht dat het vergelijkbare patronen volgt. Elk LLM-platform, ChatGPT, Gemini en Claude, is getest via zijn native app (waar beschikbaar) en via de apparaatbrowser. Voor elk scenario hebben we gekeken of UTM-parameters werden ingevuld, of er een referrer werd doorgegeven aan de bestemmingssite, en of de sessie-identiteit behouden bleef wanneer de navigatie verschoof van de LLM-interface naar de standaardbrowser van het apparaat. Server-side logging werd gebruikt om client-side waarnemingen aan te vullen.

Dit onderzoek weerspiegelt het platformgedrag op het moment van testen (12 april 2026). LLM-platforms updaten hun apps en webinterfaces regelmatig, en trackinggedrag kan veranderen.

De kern

AI-kanalen zijn geen toekomstige overweging. Ze zijn nu actief, groeien en vormen op grote schaal beslissingen. Het probleem is dat de infrastructuur die de meeste teams gebruiken om deze kanalen te meten, is gebouwd voor een wereld waarin een klik een betrouwbare referrer opleverde en een cookie die lang genoeg meeging om een conversie te zien.

Zo werkt LLM-verkeer niet.

Behandel je AI-kanaalcijfers als een aanzienlijke onderrapportage. De sessies die je kunt zien, zijn degene die toevallig elke laag van trackingverlies hebben overleefd. De sessies die dat niet deden, zijn veel talrijker, en omvatten mensen die je hebben gevonden, zijn beïnvloed door wat een AI over je zei en hebben geconverteerd zonder enig spoor achter te laten dat je zou kunnen volgen.

Veelgestelde vragen

Waarom laat mijn GA4 bijna geen verkeer zien van Claude of Gemini?

Omdat beide platforms in de overgrote meerderheid van de door ons geteste scenario’s geen UTM-parameters en geen referrer doorgeven. Op mobiel openen links in geïsoleerde in-app webviews die nooit verbinding maken met je standaard analytics-omgeving. Op desktop geeft Claude niets door, noch in de app noch in de browser. Gemini geeft in de browser een referrer door, maar geen UTM’s. Zonder een van beide belandt het meeste van dit verkeer in GA4 als direct of wordt het simpelweg niet meegeteld.

ChatGPT laat wat verkeer zien in mijn rapporten. Betekent dat dat het nauwkeurig wordt getrackt?

Niet helemaal. ChatGPT is het best traceerbare van de drie platforms die we hebben getest. In verschillende scenario’s voegt het utm_source=chatgpt.com toe, en zijn desktop-app doet dit betrouwbaar. Maar op mobiel is het pad naar attributie smal en platformafhankelijk. De UTM kan overleven als de gebruiker binnen de webview op “Open in Browser” tikt, maar dit werkt alleen op Android. Op iOS behoudt die overdracht de sessie helemaal niet. De identiteit gaat verloren wanneer de gebruiker de webview verlaat, ongeacht hoe hij vertrekt. Dus zelfs in het beste geval heb je een gebruiker nodig die op Android is, de app gebruikt en expliciet op “Open in Browser” tikt voordat hij verder navigeert. Dat is een klein segment van je daadwerkelijke ChatGPT mobiele verkeer. De cijfers die je in GA4 ziet zijn reëel, maar ze vertegenwoordigen een fractie van wat ChatGPT daadwerkelijk aanstuurt.

Geldt dit probleem alleen voor mobiele gebruikers?

Op mobiel is het het ernstigst, maar desktop is ook niet schoon. Claude op desktop geeft in alle geteste scenario’s, app of browser, niets door. Gemini op desktop geeft een referrer door maar geen UTM’s, die al dan niet correct worden geclassificeerd, afhankelijk van je GA4-opstelling. De desktop-app van ChatGPT is het ene betrouwbare lichtpuntje. Dus zelfs als je publiek volledig op desktop zou zijn, zou je nog steeds een aanzienlijk deel van het door LLM’s beïnvloede verkeer missen.

Wat is een webview en waarom veroorzaakt het trackingproblemen?

Een webview is een in-app browser die wordt geopend wanneer je op een link tikt binnen een mobiele app. Het ziet eruit als een browser, maar is geïsoleerd van de werkelijke browser van je apparaat. Hij deelt geen cookies, sessiegegevens of identiteit met Safari of Chrome. Dus alle tracking die binnen een webview afgaat, blijft daar opgesloten. Wanneer de gebruiker later zijn echte browser opent om verder te gaan, ziet hij eruit als een gloednieuwe bezoeker zonder geschiedenis.

Als de uiteindelijke conversie plaatsvindt binnen de webview van de app, wordt dat dan getrackt?

Het kan, maar het is niet zuiver. De conversie moet binnen de webview plaatsvinden om de attributieketen intact te houden. De gebruiker hoeft niet zijn hele reis daar te hebben doorgebracht, maar die laatste stap wel. De valkuil is dat iOS voor de meeste doelgroepen de meerderheid van het mobiele verkeer vormt, en op iOS is de webview onderworpen aan de cookiebeperkingen van WebKit, waaronder Intelligent Tracking Prevention. Die beperkingen kunnen de continuïteit waarop je vertrouwt beperken of verbreken. Dus hoewel dit scenario in theorie traceerbaar is, is het in de praktijk de minst gebroken optie in plaats van een betrouwbaar pad.

Kan ik dit oplossen met server-side tracking?

Server-side tracking helpt, maar lost niet alles op. Het kan signalen vastleggen die client-side JavaScript mist, waaronder referrer-gegevens die het nooit tot GA4 halen. Apparaat-fingerprinting-tools kunnen ook helpen door probabilistische identiteit te handhaven tussen webview- en browsercontexten op hetzelfde apparaat. Maar geen van beide benaderingen lost het cross-device-probleem op, en geen van beide biedt je volledige meting. Je komt zinvol dichter bij de waarheid, maar je komt niet helemaal.

Hoeveel wordt door LLM’s ondersteund conversieverkeer daadwerkelijk onderrapporteerd?

Op basis van onze analyse ergens in de range van 2,5x tot 5x, afhankelijk van je publiek en hoe zij LLM-platforms gebruiken. De conservatieve schatting (Case A) gaat ervan uit dat de helft van de mobiele gebruikers LLM’s benadert via de browser, waar tracking grotendeels werkt, wat ongeveer een 2,5x onderrapportage oplevert na verliezen op het conversiepad. De meer realistische schatting (Case B) gaat ervan uit dat 80% van de mobiele gebruikers op de native app zit, waar tracking in essentie faalt, wat een 4 tot 5x onderrapportage oplevert. Beide schattingen zijn waarschijnlijk nog conservatief, omdat een groeiend deel van wat GA4 classificeert als Google organic in werkelijkheid door LLM’s beïnvloed verkeer is dat binnenkomt via AI Overviews en AI Mode, verkeer dat met standaardanalytics onmogelijk te scheiden is.

Moet ik meer investeren in AI-zichtbaarheid als ik de resultaten niet kan meten?

Ja, aantoonbaar juist meer, niet minder. Het feit dat je de volledige impact van dit kanaal niet kunt meten, betekent niet dat die impact er niet is. Het betekent dat je huidige tools onvoldoende geschikt zijn om dit te zien. De sessies die wel tot je rapporten doordringen, laten al betekenisvolle betrokkenheid zien. De sessies die dat niet doen, zijn ordes van grootte talrijker. Dit kanaal als onbelangrijk beschouwen omdat de cijfers klein lijken, is precies de verkeerde conclusie om te trekken.