Stop Deleting utm_source=chatgpt.com. It's a Channel Now, Sort Of.

That chatgpt.com row in your acquisition report is a person.

Somebody asked an assistant a question, it cited your page, and they clicked through. ChatGPT wrote that utm_source onto the link before it ever reached you, which is why there’s nothing on your side to remove. It isn’t spam and it isn’t a tracking bug.

Google shipped a channel for exactly this traffic on 13 May 2026.^[2] But it’s a newer and narrower thing than it looks, and Google’s own pages don’t agree on what belongs in it.

So we checked all of them. Google publishes the list of sources it sorts into search, social, shopping and video, and we counted every row. 819 sources, and not one AI assistant in it.

But the fix isn’t hard. You write one channel rule of your own that matches on the source, and this traffic files where you meant it to go -- including the visits you already collected.^[4] The rest of this page is why it has to be that small, and Google’s own documentation is what makes the case.

Why chatgpt.com shows up in a tag you never wrote

Because ChatGPT puts it there. When the assistant searches the live web and cites a page, the link it hands the reader already carries utm_source=chatgpt.com on the end of it.

FIG 01

ChatGPT tags the link before it reaches you

Source: OpenAI’s FAQ for publishers.^[1]

OpenAI says so itself, in one line of its FAQ for publishers:

“ChatGPT automatically includes the UTM parameter utm_source=chatgpt.com in referral URLs, enabling clear tracking and analysis of inbound traffic from ChatGPT search results.”^[1]

Read the end of that sentence again. OpenAI put the tag there so you could count these visits.

So, the removal question, answered flatly. You can’t, and you wouldn’t want to.

Blocking or rewriting the parameter doesn’t stop the visit. It only deletes the one clue telling you an assistant sent it.

What GA4’s AI Assistant channel catches today

When somebody clicks a citation inside ChatGPT, the click arrives carrying the name of the page it came from. That name is the referrer, and it’s one of two things GA4 looks at to decide an assistant sent the visit.

Google’s definition of the AI Assistant channel is one sentence:

“AI Assistant is the channel by which users arrive at your site from sources like ChatGPT, Gemini, Deepseek, Copilot, or Grok.”^[3]

Two different things can put a visit in that channel, and Google lists them one after the other. The first is a rule about a tag you wrote:

“The medium exactly matches ‘ai-assistant’.”^[3]

The second isn’t a rule about your tag at all. It’s Google writing the tag for you, off the return address:

“The medium is set to ‘ai-assistant’ and the campaign is set to ‘(ai-assistant)’ if the referrer matches a list of AI Assistants.”^[3]

FIG 02

Two ways in, one unpublished list

Source: Google’s channel definitions.^[3]

Now notice what that second sentence doesn’t do. It doesn’t publish the list.

Google names five assistants on that page. It names three in the release note announcing the feature, where the examples are ChatGPT, Gemini and Claude.^[2] And it names a different five again in its own guide to building a custom channel group, where Perplexity appears and Grok doesn’t.^[4]

Three Google pages, three lists, and not one of them presented as complete.

For a channel that didn’t exist in April, this is still a real gain. But it means the documentation can’t tell you whether the assistant sending you traffic is in it.

So the list worth trusting is the one already in your reports. Whatever names are sitting in your source rows right now, those are the ones your own rule has to name.

The two documented rules that fight over the same click

Here’s the part that gets left out, and it’s a little absurd. The tag OpenAI adds to help you may be the thing that knocks the visit out of Google’s new channel.

Two documented behaviours land on this traffic at once. You’ve just read the AI Assistant rule, where Google reads the referrer and writes the medium itself. The other one, the derivation rule, says your parameters take over completely:

“In instances where the GCLID or DCLID cannot be used as intended, if any UTM parameter is present on the URL, Google Analytics will derive all cross-channel traffic source dimension values from UTM parameters, exclusively.”^[5]

A citation click from ChatGPT fits both descriptions at the same time. It arrives with a chatgpt.com return address, which is what the first rule reads, and it arrives carrying a UTM parameter, which is what the second rule reads.

FIG 03

Same visitor, two destinations

Sources: the AI Assistant conditions,^[3] the UTM derivation rule^[5] and Google’s note on missing parameters.^[6]

But look at how that quote opens. It describes what happens when a Google Ads click ID can’t be used as intended, and a cited link from an assistant never carries a click ID in the first place. So whether that rule governs this case at all is genuinely unclear, and Google doesn’t say.

We’re not going to pretend to settle it. Nobody has published a test, the two rules point opposite ways on the same visit, and Google hasn’t said which one goes first.

Two outcomes, and both are easy to state. If the derivation rule wins, utm_source=chatgpt.com with no medium beside it derives a medium of (not set),^[6] and no default channel matches that pair. That lands the visit in Unassigned, “the value Analytics uses when there are no other channel rules that match the event data”.^[3]

If the AI Assistant rule wins, the same click files cleanly. Same visitor, two destinations -- and nothing in the documentation to tell you which one you’re looking at.

The question mark in the drawing above is the part Google hasn’t published. It’s also the first reason the rule from the top matches on the source and nothing else.

Only the medium is in dispute here. Match on the source alone and chatgpt.com lands in your AI channel either way, whichever rule Google runs first.^[4]

Which means you stop waiting on Google to settle something it may never settle.

What the AI Assistant channel misses, and why it isn’t your AI number

Two things are missing from this channel, and the bigger one isn’t the gap people worry about. Google names it in the channel definition itself, in one flat sentence:

“It excludes Google’s AI Overviews and AI Mode.”^[3]

So the AI surface that sits inside Google Search is, by design, not in your AI channel. Google files those arrivals under Organic Search instead, and says so on the same page:

“Organic Search is the channel by which users arrive at your site/app via non-ad links in organic-search results, including Google’s AI Overviews and AI Mode.”^[3]

That’s a defensible call, because the click did leave a Google results page. But it means AI Assistant in your report covers chat assistants and nothing else.

Put a number next to the words “AI referral traffic” after that, and it’s missing everything that arrived through Google’s own results.

You can’t recover that piece downstream either. Search Console reports pages appearing in AI features under the ordinary “Web” search type, rather than breaking them out.^[7]

There is now a dedicated generative AI report in Search Console. But it counts impressions, not clicks.^[8]

The second gap is the clicks that arrive with no return address at all. This one gets overstated, so here’s the actual line.

So ordinary browsing is fine. What does lose the referrer is a link opened inside an app’s own browser, copied into a document, or pasted into a message. A site can also drop it on purpose, with a rule called no-referrer that sends no return address at all.^[9]

When that happens, nothing errors and nothing warns you. If the tag made it through, the visit still says chatgpt.com, and a rule that matches on the source still catches it. If the tag got lost too, the visit lands in Direct with nothing left to match.^[3]

FIG 04

The AI Assistant channel isn’t your AI number

Source: Google’s channel definitions.^[3]

None of these pieces has been measured. The drawing shows where each kind of visit is filed, not how big it is.

Neither gap is yours to fix. Google files the AI Overviews arrivals under Organic Search on purpose, and a click that lost both its tag and its return address looks exactly like somebody typing your address.

What you can fix is the label. Name the channel for what it actually holds -- chat assistants -- and the number stops claiming more than it counts.

Reading chatgpt.com / referral against chatgpt.com / organic

Almost all the confusion here is one question. People see chatgpt.com / referral in one report and chatgpt.com / ai-assistant in another, and assume one of them is broken.

Neither is. They’re different arrival paths for the same kind of visitor, and the medium is the tell.

A visit collected before 13 May 2026 says chatgpt.com / referral. It arrived before the AI Assistant channel existed.^[2]

But chatgpt.com / organic is a different story, and it’s the row worth chasing down. Two conditions send a visit to Organic Search: the source is on Google’s list of search sites, or the medium is exactly organic.^[3]

That list is the one we counted at the top, and it’s what settles this row. It’s a file linked straight off the channel definitions page, under the heading for manually tagged traffic.^[10]

Its 129 search sites run from Google, Bing and Yandex through a long tail of Yahoo country domains, and there’s no AI category in the file at all.^[10]

So a chatgpt.com / organic row can’t have come from the source list, because chatgpt.com isn’t on it. Which leaves the second condition -- and only the second condition.

FIG 05

Only a hand-typed tag makes it organic

Sources: Google’s channel definitions^[3] and its source categories file.^[10]

Somebody typed utm_medium=organic onto that link by hand. Somebody on your team built it, and they overwrote a real source to do it.

Why the copy-paste regex fails, starting with Google’s own

Search this problem and you’ll have a ready-made pattern inside thirty seconds. A dozen publishers have one, and so does Google, in its own guide to building a custom channel group.^[4] Google’s is the clearest illustration of the problem we’ve seen anywhere.

The full pattern is eleven alternatives long, and we won’t reprint all of it. Five are enough, and you can check every line of this by eye.

From Google’s pattern	What it matches	Does it change anything?
.*gpt.*	any source with “gpt” in it	Yes. This is the one doing the work
.*chatgpt.*	any source with “chatgpt” in it	No. Anything with “chatgpt” in it already has “gpt”
.*bard.*	any source with “bard” in it	Yes
.*google.*bard.*	”google” somewhere before “bard”	No. The bard row above already caught it
.*bard.*google.*	”bard” somewhere before “google”	No. Same again

Three of those five are dead weight, and the table shows you why: another alternative in the same pattern already catches everything they match. A fourth does the identical thing with gemini further along. So four of Google’s eleven alternatives can never change where a single visit lands.

Then look at what’s still in there. bard is what Gemini was called before Google renamed it, and the pattern reaches for it in three separate places.

Google adds its own note underneath:

“You should update your regex expression if URLs or the list of assistants you wish to measure change.”^[4]

That’s the whole problem in one sentence, published by the vendor. A pattern is a snapshot of which assistants existed the week somebody wrote it.

And it decays quietly from there. When the next assistant launches, nothing errors and no warning appears. The row simply doesn’t show up.

That’s a maintenance problem wearing a configuration problem’s clothes. So the useful version of this isn’t a better pattern, it’s giving AI sources the same governance you’d give any other channel: a closed list, an owner, and a date.

How to build an AI channel rule that survives the next launch

Now the rule itself. It lives in a thing Google calls a custom channel group, which is a bigger name than the idea deserves.

One correction first, because the opposite gets repeated a lot. A custom channel group is not future-only. Google’s note is plain:

“Custom channel groups can be applied to your reports retroactively.”^[4]

So building the rule today also re-labels the traffic you already collected. There’s one catch, and it’s specific.

If you promote your custom group to be the property’s primary channel group, Google says that definition populates the primary dimension “on future reporting”.^[4] Use it as a dimension and you keep your history. Promote it and the clock starts today.

Six lines total. The first two do the matching, and the other four keep it from rotting.

None of that is new thinking. It’s the same discipline as the rest of UTM best practices, pointed at a set of sources that didn’t exist when most teams wrote their conventions.

One last thing, because it’s the part worth keeping after you close this tab. This channel isn’t hard to see because it’s small, or because your tracking is broken.

It’s hard to see because the rules that file it are split between two companies. OpenAI writes the tag, and Google decides what it means, from a list it doesn’t publish. You can’t fix either of those.

You can write the rule yourself, and you can put your name on it. That’s the only part of this that was ever in your hands.

Frequently asked questions

What does utm_source=chatgpt.com mean?

It means a visitor arrived from a link ChatGPT cited. When the assistant searches the live web and references a page, the link it hands the reader already carries utm_source=chatgpt.com, so the visit arrives pre-labelled. You didn't add the tag and you can't change it. It's an ordinary referral wearing a parameter you didn't write, not spam and not a tracking error.

How do I get rid of utm_source=chatgpt.com?

You don't, and you wouldn't want to. The parameter is applied before the click ever reaches your site, so there's nothing on your end to switch off. Blocking or rewriting it doesn't prevent the visit. It only deletes the one signal telling you that visit came from an AI assistant. File it into a channel instead of filtering it out.

Does GA4 have a channel for AI traffic?

Yes, since 13 May 2026. Google added an AI Assistant channel to the default channel group, described as covering arrivals from sources like ChatGPT, Gemini, Deepseek, Copilot or Grok. Two things put a visit there: a medium that exactly matches ai-assistant, or a referrer Google recognizes, in which case Analytics writes that medium itself. Google doesn't publish the list of referrers it recognizes.

Does GA4's AI Assistant channel include AI Overviews?

No, and Google says so directly in the channel definition: it excludes Google's AI Overviews and AI Mode. Those arrivals are filed under Organic Search instead, which Google's own definition of that channel now states outright. So the AI Assistant number in your report covers chat assistants only, and any figure you label AI traffic is missing the search side of it.

Why does ChatGPT traffic show as referral instead of organic?

Because it arrived through a link on another site, which is what Google's Referral channel describes. Organic needs one of two things: a source on Google's published list of search sites, or a medium of exactly organic. We downloaded that published list and counted 819 sources across search, social, shopping and video. No AI assistant appears anywhere in it.

Is utm_source=chatgpt.com traffic real, or is it bots?

Real people, in the ordinary case. The parameter rides on links shown to a human inside a chat, and a click has to happen for the visit to exist at all. Crawlers that fetch your pages to build answers are a separate thing, since nobody clicked a cited link. If a chatgpt.com row shows sessions with normal engagement, treat it as human traffic.