You already suspect it: people are finding you through ChatGPT, and your analytics is filing most of those visits under Direct. This is not a bug in your setup. It is what happens when a channel arrives through in-app browsers and rewritten links while your reporting model was designed for search engines and referral headers.
Below are the three methods that actually work, in ascending order of reliability, plus a measurement plan you can run over the next quarter.
Where GA4 hides ChatGPT traffic today
GA4 assigns a channel using the referrer and campaign parameters on the landing hit. When an assistant opens your page inside its own webview, or when the outbound link is proxied, the referrer either never arrives or arrives as a host GA4 has no rule for. Google’s own default channel group definitions then fall back to Direct or Unassigned. The traffic is in your property; the label is wrong. The five specific failure modes are enumerated in the GA4 hidden-buckets post.
Method 1 — utm_source (limited)
Tag every link you control that an assistant is likely to surface — documentation, changelog entries, syndicated posts — with ?utm_source=chatgpt.com. Then add a custom channel group in GA4 that matches your AI sources.
This works, and it is worth ten minutes of your time, but the ceiling is low. You can only tag links you publish. The overwhelming majority of assistant citations point at untagged pages, and any parameter you add can be stripped in the answer surface. Treat it as a floor, not a solution.
Method 2 — server-side user-agent classification (recommended)
Every request that reaches your server carries a user-agent string and, usually, a referring host. Both are available before a single line of JavaScript executes, and neither requires storage on the visitor’s device. Classify in two passes:
- Machine traffic. Match the user-agent against documented crawler tokens — OpenAI publishes GPTBot, OAI-SearchBot and ChatGPT-User at platform.openai.com/docs/bots. These are fetches, not humans, and belong in a separate report.
- Human referrals. Match the referring host against known assistant hosts, then fall back to IP-range checks for surfaces that hide the referrer.
This is what Citealytics does on every event, against the registry published on the crawlers page. Because classification happens on the server, it survives ad blockers, in-app browsers, and the absence of cookies entirely.
Method 3 — Plausible’s AI channel group
If you already run Plausible, it documents a dedicated approach to tracking AI traffic with an AI-search grouping in its referrer reporting. It is a genuinely useful default and requires no work beyond having the script installed. Its limit is depth: you get a channel, not per-page citation history or per-engine visibility scoring.
Build a 30/60/90 measurement plan
- Days 1–30. Install server-side classification, tag the links you control, and establish a baseline for AI share of visits per engine. Change nothing else — you need a clean line to compare against.
- Days 31–60. Look at which landing pages receive assistant referrals. Improve the three that get cited most: clearer definitions near the top, explicit answers to the question the page ranks for, structured data where it fits.
- Days 61–90. Compare AI-referred conversion behaviour against organic search. If it converts better — which is common for high-intent question traffic — you have your budget argument for the next quarter.
The point of the plan is not the dashboard. It is being able to say, in one sentence and with a source, what share of your pipeline started inside an assistant.