AI referral traffic: measuring the visitor ChatGPT sends you

Thursday, 2:40 p.m. A marketing lead opens the referral report and sees 412 sessions from chatgpt.com over the past thirty days. She turns the screen toward the head of sales, who asks one question: how many of those requested a quote? There is no answer. In the CRM, the source field on the 87 opportunities opened that month either reads «direct» or sits empty. The traffic report lives on one side, the revenue table on the other, and no field connects them. The numbers here are illustrative, but the situation is familiar.

This article is about closing that gap. Making AI referrals visible inside your analytics tool is covered in seeing ChatGPT and Perplexity visits in GA4; here we take the next step. In order, we will look at: what actually proves a visit came from an AI assistant and which referrer or UTM patterns point to which engine, why the referrer disappears halfway, how to carry session-level data into a person-level record, which fields belong on a lead, where the attribution chain breaks most often, whether a «how did you hear about us» question fills the gap, how to avoid counting the same visitor twice, how to report a day you could not measure, whether this traffic pays in clicks or revenue, and which weekly checks keep the whole setup alive.

What actually proves a visit came from an AI assistant?

You have three kinds of evidence, and they are not equally strong. The first is the referrer domain the browser sends on its own: when someone clicks a link inside an assistant's answer, the browser usually reports that assistant's domain to your server. This evidence is free and needs no setup, which is exactly why it is the most fragile of the three.

The second is campaign parameters attached to the outbound link itself. Some engines append their own source tag to links they hand out, so the visit carries its identity even when no referrer arrives. The third is circumstantial: which page the visitor landed on, which question that page answers, and how the session behaves. On its own it proves nothing, but read alongside the first two it confirms a classification.

One distinction is worth making up front: an engine's crawler and an engine's visitor are not the same thing. Agents such as GPTBot, ClaudeBot, PerplexityBot or Google-Extended read your site to collect content; that is not a human visit and it does not belong on the same line as one. Rocketly's GEO side includes llms.txt, robots and schema tools that read each of those agents' access status one by one — that screen answers «are the bots getting in», not «how many people arrived». Merging the two into one chart is the quickest way to make an engine that sends no visitors look successful.

The table below summarises how to read referrer and parameter patterns in practice. Domains change over time, so treat it as a checklist rather than something to memorise.

Assistant	Typical referrer domain	Common parameter	What to watch in measurement
ChatGPT	chatgpt.com, chat.openai.com	utm_source=chatgpt.com	Clicks from the desktop and mobile apps often carry no referrer and land in direct traffic
Perplexity	perplexity.ai and its subdomains	utm_source=perplexity	Subdomains pile up as separate rows; normalise the hostname before you count
Gemini	gemini.google.com	—	Clicks from the AI summary inside search look like organic search and produce no separate referrer
Claude	claude.ai	—	Links inside answers open in a new tab, frequently without referrer information
Copilot	copilot.microsoft.com, bing.com	—	Blends into search-engine rows; do not drop the assistant and the search engine into one bucket
Grok	grok.com, x.com	—	Overlaps with social referrals; judging by domain alone is misleading

Why does the referrer disappear halfway?

The most frustrating property of this traffic is that a large share of it arrives anonymous. There are four main reasons. First, apps: someone using the assistant in a desktop or phone app rather than a browser clicks a link, and the browser that opens usually carries no record of where it came from. Second, in-app browsers: the link opens inside an embedded window and the chain breaks there.

Third, referrer policy — the sending site can instruct the browser not to share its domain. Fourth, and the most human of the four, the person never clicks at all. They read your brand name in the answer, open a new tab, type your name and arrive directly. In your report that visit is labelled direct, while its real origin was an assistant's answer.

The conclusion follows: any number measured through referrers sits below the real effect. That is not a defect, it is the limit of the method, and it belongs in the report as such. A figure read as a floor is far more useful than an estimate presented as exact. It also helps to track branded search visits as a separate signal; when mentions in assistants rise, that line usually moves first.

How do you carry session-level data into a person-level record?

An analytics tool counts sessions; a CRM holds people and deals. There is no automatic bridge between those two worlds. Seeing «412 sessions from chatgpt.com» does not tell you which of them filled in a form, because the analytics tool does not know your lead record and the CRM does not know the browser session.

The bridge is built at form submission. The moment a visitor lands, the referrer domain, campaign parameters and landing page are stored browser-side; when the form is sent, those values are written into the CRM through hidden fields, so the record carries its own origin with it. How reliably this works depends heavily on how the landing page is designed to convert: if the page holding the form is not the page the visitor first landed on, you must carry the first-touch values forward, or every record will mistake an internal referral for its source.

The second bridge is whatever turns an anonymous visitor into a known contact. Trading a guide, a calculator or a checklist for an email address makes that visit's identity permanent, and on the measurement side that is the real job of a lead magnet. Without an identity there is nothing to attribute, because there is no record to attribute to.

Which fields belong on the lead record?

A single «source» field will not carry this. In practice you need six, each answering a different question. First-touch channel: how the person found you the first time. First referrer domain: the raw hostname, normalised. First landing page: which piece of content was the answer's source. Last-touch channel: the channel immediately before submission. First-touch date: needed to reconstruct the chain later. And a classification flag: is this record confirmed, probable, or unclassified?

That last field is the most commonly skipped and the most valuable. The most dangerous move in measurement is forcing an unknown into a known box. That is why the AI referral traffic screen on Rocketly's GEO side also states the number of rows it could not classify: while it shows which assistant brought conversions rather than clicks alone, it leaves the part it cannot show plainly visible. You cannot read the meaning of the known without seeing the size of the unknown.

• Confirmed: the referrer domain or a campaign parameter names the engine outright.
• Probable: direct traffic, but the person named an assistant in their own answer, or the landing page is a deep page that only appears in that answer.
• Unclassified: no signal at all. This row is not deleted, it is counted.

Where does the attribution chain break most often?

It breaks at four points. The first is a change of device: the question is asked on a phone at lunch, the form is filled from a laptop that evening. The two sessions have no link, and the record opens under the second device's channel.

The second is the phone call. A visitor dials the number on the page and the digital trail ends there. The way to attach source information to a call is to vary the displayed number by channel and match the incoming call to a record; getting that call to the right team and opening the record is the job of smart call routing. Otherwise your best-qualified contacts never appear in the report at all.

The third is time. Weeks can pass between an assistant's answer and a signature; cookies do not live that long, the person returns three more times, and last touch takes all the credit. The fourth is chat: the visitor writes in the widget instead of filling in a form. Source data then has to ride along with the conversation record, or every lead from live chat looks like it came from a single channel.

Does a «how did you hear about us» question fill the gap?

Partly, and that part should not be dismissed. One extra line on the form, free text or a short list, recovers a share of the visits that are technically unmeasurable — especially app traffic that shows up as direct. Three rules make it work.

First, name the assistants explicitly in the option list; a broad bucket like «the internet» or «a search engine» swallows everything. Second, write that answer into its own field rather than overwriting the technical attribution field: a stated source and a measured source are two different kinds of evidence and neither replaces the other. Third, set expectations correctly — people report what they remember, not what happened. Self-reported data gives you direction, not decimal precision.

How do you avoid counting the same visitor twice?

Double counting is the most common reporting error in this area, and it usually starts from good intentions: every channel wants full credit for its contribution. The result is an assistant channel reporting 40 leads, organic search 40 leads and email 40 leads, with the total running at twice the real number.

The fix is to choose one rule and stay with it. A first-touch model shows who created the demand and is the right lens for content that opens new markets. A last-touch model shows who closed the conversion. You can place both side by side in one report, but you cannot add them into a single figure. A practical setup: keep the first-touch channel frozen on the deal record, update last touch on every interaction, and make each report state in its title which lens it uses.

The second trap is the same person becoming two records. If two submissions from one email address two weeks apart create two leads with two different channel tags, both your counts and your attribution are wrong. Deduplication comes before attribution, not after it.

How do you report a day you could not measure?

The measurement chain itself fails too: a tag drops in a release, a hidden field is wiped in a form update, an integration pulls nothing for a day. What the report shows on those days is not «zero visits» but an absence of data, and if both look identical on the chart your team will spend the morning on a crisis that never happened.

The an unmeasured day is not zero principle on Rocketly's GEO side applies exactly this: when a provider does not respond or the allowance runs out, the chart breaks at that point, the ratio shows a dash rather than zero per cent, and the number of unmeasured days is stated separately. Carry the same logic into your own CRM reporting: keep the share of records with an empty source as a fixed line at the bottom of the report. When that share climbs, the problem is in the measurement, not the traffic. Having a measurement gap as its own type among the alert rules is the product-side version of the same distinction — a drop alert and a missing-data alert should never produce the same notification.

Does this traffic pay in clicks or in revenue?

The point of separating the channel is not a chart to be proud of; it is a budget decision. That needs three measures read by channel. The first is whether the person who signed up actually started using the product — the activation rate. Someone arriving through an assistant has usually already sharpened their question, and tends to behave differently on this line.

The second is the total value of the relationship. Judging a channel cheap or expensive from a single sale is misleading; when customer lifetime value is calculated per channel, the ranking often changes.

The third is speed: how many days the same opportunity takes to close. Read by channel, sales velocity shows which source hands your sales team the easier work.

One caveat: this traffic cannot be re-targeted the way familiar channels can. There is no audience list to buy inside an assistant; your only lever is capturing the arriving visitor into your own list and continuing from there. The role of retargeting in this channel is to recapture the outcome, not the source.

Which weekly checks keep the setup alive?

This measurement is not built once and forgotten, because both the engines and your own site keep changing. Four weekly checks are enough. One: has the share of new records with an empty source risen since last week? Two: has a domain you have not seen before appeared in the referrer list — new assistants and new subdomains show up quietly. Three: are the hidden fields on your forms still filling in? A single test submission answers that in thirty seconds. Four: are visibility inside assistants and incoming traffic moving in the same direction?

That last check requires two separate measurements side by side. Being mentioned in an answer and having your domain cited as a source are different things; the first builds awareness, the second produces clicks. Reading the GEO side's mention versus citation split together with source intelligence lets you answer a traffic drop by distinguishing «we no longer appear in the answer» from «we appear, but someone else is cited». The wider frame for all of this is set out in generative engine optimisation.

If you want those four checks on one panel and the weekly report sent automatically, you can open a free Rocketly account and try the GEO screens against your own domain.

FAQ

Why does assistant traffic look like direct traffic?

Because a large share of clicks come from desktop or mobile apps, where the browser carries no referrer. Add to that the people who read your name in an answer and type it into the address bar. Reading a rise in direct traffic alongside a rise in branded search is the most practical way to estimate that invisible share.

Is a channel rule based on referrer domains enough?

Enough to start, not enough on its own. Domain lists go stale as new assistants and subdomains appear. Review the rule monthly, normalise hostnames to a single form, and collect referrers that fall outside the rule in a separate list. That list writes the next version of the rule for you.

How do I separate the engine's crawler from its visitors?

Crawler access shows up in server logs and in your robots configuration; visitors are counted by the measurement tag on the page. They come from different sources and should never be summed in one chart. Crawler access is about whether your content can enter the answer; visits are about whether the answer sends anyone to you.

How many data sources does this setup need?

Three: the measurement tag on the site, hidden fields on your forms, and attribution fields in the CRM. Add visibility measurement inside the assistants as a fourth and you can look for the cause of a traffic change on the visibility side. You can start without that fourth source, but the question of why stays unanswered.