Traffic from ChatGPT and other AI assistants arrives as an ordinary referral — chatgpt.com, perplexity.ai, claude.ai, copilot.microsoft.com and similar show up in document.referrer. It converts. But it almost never carries UTM parameters or a click ID, so most attribution tools file it under Direct, or bury it in a generic “Referral” row that nobody looks at.
The result is a channel that is quietly producing revenue and getting no credit for it. This article covers how the traffic actually arrives, why it gets mislabelled, and what it takes to hold the attribution from the answer all the way to the sale.
How does AI assistant traffic actually reach your site?
As a link click in a normal browser, with a referrer and nothing else.
When an assistant cites your page, the citation is a standard link. The user clicks it, their browser opens your site, and document.referrer contains the assistant’s domain. There is no utm_source, no click ID, no tracking parameter of any kind — because nobody ran a campaign. The assistant linked you because its answer needed a source.
That makes the referrer the only evidence the visit came from an AI assistant. It’s a single, fragile signal, and it exists for exactly one page view: the landing page. Navigate to a second page and the referrer becomes your own domain. Close the tab and come back tomorrow and it’s gone entirely.
A second, rarer arrival path is worth knowing about: users who read an answer, don’t click anything, and type your domain in later. That visit has no referrer at all and is genuinely indistinguishable from any other direct visit. It’s real demand created by the assistant, and no tracking method can see it — which is worth stating plainly rather than pretending otherwise.
Why does AI traffic end up in the Direct bucket?
Because most analytics tools decide a session’s source from parameters first and the referrer second, and then only at session start.
Three things go wrong in sequence:
1. No parameters means no campaign. A visit with no utm_source and no click ID doesn’t match any campaign definition, so it falls through to referrer classification — the weakest tier in most tools.
2. The referrer isn’t in the channel map. Analytics platforms classify referrers against a maintained list of known sources — search engines, social networks, ad platforms. AI assistants are newer than most of those lists. An unrecognised referrer lands in “Referral” or “Other” rather than a named channel, and in some configurations it’s dropped to Direct outright.
3. The referrer doesn’t survive to the conversion. This is the one that actually costs money. Someone reads an answer on Monday, clicks through, browses, and buys on Thursday. Thursday’s session has no referrer and no parameters. Unless the two sessions are stitched to the same person, Thursday reads as Direct and Monday’s AI referral is credited with nothing.
Point three is the same structural problem behind ad conversions showing as Direct: session-scoped attribution asks what signals this visit arrived with, and a returning visitor arrives with none.
Can you tag AI traffic with UTMs?
Partly, and it’s worth doing — but it covers less ground than people expect.
You can add UTM parameters to URLs you control and expect an assistant to surface: links in your documentation, in a public changelog, in content you syndicate. If the assistant reproduces the URL verbatim, the parameters come along.
What you can’t do is tag the citation. When an assistant links you because your page answered a question, it links the canonical URL. You had no opportunity to decorate it. That’s the majority of this traffic, and it’s exactly the portion that matters most, because it’s the traffic your content earned rather than bought.
So UTM tagging is a supplement, not a solution. The durable approach is to treat the referrer as a first-class attribution signal rather than a fallback — capture it at first touch, resolve it to a named channel, and carry it forward.
How do you measure whether AI traffic is any good?
By the same metrics you’d apply to any channel — and the interesting part is that the answer is usually favourable.
Four numbers to look at:
- Conversion rate versus your site average. Assistant traffic tends to arrive further down the funnel, because the user has already had their question answered and is arriving to act rather than to learn.
- Average order value. Worth separating from conversion rate; a channel can convert less often and still be worth more per conversion.
- Time to purchase. Assistant referrals often carry a longer lag than paid clicks, which is precisely why session-scoped tools lose them.
- Assist rate. AI traffic frequently appears mid-journey rather than as the closing touch — the visitor researches via an assistant, then returns through search or direct. A last-click view will show almost none of this.
If you only measure last-click, you will conclude AI traffic doesn’t convert. That conclusion is an artifact of the measurement model, not a finding about the channel.
How does PartialLeads track AI-assistant conversions?
By capturing the referrer at first touch, keeping it attached to the person rather than the session, and surfacing the assistant as a named channel with its own revenue.
Referrer capture at first touch, with fallback. The tag captures UTM parameters from the URL and falls back to document.referrer when there are none — which is the normal case for an AI citation. The landing page and referrer are recorded on the session at the moment of arrival, before any navigation can overwrite them.
A durable visitor ID so the referrer survives the gap. The visitor ID is stored in localStorage with a first-party cookie backup, and the cookie is set by the server rather than by script — so Safari’s seven-day cap on script-written cookies doesn’t apply to it. A visitor who reads an answer on Monday and buys the following week is still recognisably the same person.
Identity stitching across the sessions in between. Sessions are unioned into one person across six tiers — visitor ID, email, phone, IP and user agent, device fingerprint, and click ID. The Monday referral and the Thursday purchase land in the same cluster, so the purchase can inherit the first touch that actually caused it.
The assistant appears as a named channel. In the Attribution Report’s channels table, chatgpt.com shows up as a first-class source alongside Google, Google Ads and Meta Ads — with its own revenue, purchase count, average order value, average lag, visitors, visitor-to-lead rate and ROAS. Not folded into “Referral.”
First touch, last touch and resolved, side by side. Three attribution models are displayed simultaneously rather than one being chosen for you. This matters more for AI traffic than for any other channel, because assistant referrals skew heavily toward the assist role — a last-touch-only view is the single easiest way to conclude the channel is worthless.
Conversion paths show the assist explicitly. Full path sequences are listed with counts, alongside an assisting-channels table showing assists, assisted revenue and closes. If assistant traffic is opening journeys that close elsewhere, that’s visible as a pattern rather than inferred.
Honest boundaries. Three of them. Visitors who read an answer and never click cannot be attributed by anyone — there is no signal to capture, and that demand is genuinely invisible. Referrer-based classification depends on the assistant sending a referrer at all; if a client strips it, the visit is indistinguishable from direct. And an assistant’s referrer tells you the assistant sent them, not which answer or which prompt — there is no query-level detail in the way search once offered keywords.
| Problem | PartialLeads mechanism | Where you see it working |
|---|---|---|
| AI referral has no UTMs to classify on | UTM capture with document.referrer fallback at first touch |
Session source on the lead, set at arrival |
| Referrer is gone by the second page view | First-touch attribution row written and snapshotted per purchase | First-touch column in the channels table |
| Purchase happens days later with no referrer | Server-set, ITP-durable visitor ID plus six-tier identity cluster | Journey ribbon on the leads list |
| Assistant hidden inside “Referral” or “Other” | Assistant surfaced as its own channel row | Channels table, with revenue, AOV and lag |
| Last-click makes the channel look worthless | First / last / resolved models shown side by side | Attribution models comparison |
| Assistant opens journeys that close elsewhere | Conversion paths and assisting-channels table | Assists, assisted revenue and closes |
What should you do about it?
Three things, in order of effort.
Check whether you already have this traffic. Look for assistant domains in your referrer data over the last 90 days. Most sites that publish substantive technical content have more than they expect, and it has usually been sitting in Direct or Referral the whole time.
Stop letting the referrer die at the session boundary. Whatever tool you use, the question to ask is whether first-touch source is recorded per person or per session. If it’s per session, assistant traffic will keep disappearing on the return visit.
Judge it on assisted revenue, not last click. This is the one that changes decisions. A channel that opens journeys and rarely closes them looks like nothing in a last-click report and looks material in a path report.
Tell us what's broken. We'll fix your tracking — free.
Describe the tracking/attribution problem you're stuck on and we'll map it to a fix: server-side conversions to Meta, Google, TikTok and Pinterest, plus first-party tracking that survives Safari. No code required.
Sources
- Mozilla Developer Network — Referer header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer
- Mozilla Developer Network — Referrer-Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
- Google Analytics Help — [GA4] Understand (direct) / (none) traffic: https://support.google.com/analytics/answer/15258820
- Google Analytics Help — Campaigns and traffic sources: https://support.google.com/analytics/answer/11242841