# GA4 AI Assistant channel: 2 of 6 assistant hosts answered a scan > Google's new channel files a visit under AI Assistant when the referrer matches a list it does not publish. Lantad fetched the six assistant hosts in its own referrer list on 9 September 2026: two returned a readable page, and both declare a policy that sends the host and discards the path. - Canonical page: https://lantad.co/blog/ga4-ai-assistant-channel-two-of-six-hosts - This file: https://lantad.co/blog/ga4-ai-assistant-channel-two-of-six-hosts.md - Last substantive update: 2026-09-09 ## Key facts - **Published:** 2026-09-09 - **Category:** Findings - **Author:** Lantad - **Length:** 3192 words - **Takeaway 1:** The GA4 AI Assistant channel went live on 13 May 2026, Google's Analytics release notes state, setting the medium to ai-assistant and the campaign to (ai-assistant) when a visit's referrer matches a list of AI Assistants that Google describes but does not publish. - **Takeaway 2:** Every visit in that channel is placed there by the Referer header the assistant's own page chose to send, so a click that arrives without one is filed as Direct traffic no matter which product produced it. - **Takeaway 3:** Lantad fetched the six assistant hosts in its own referrer list on 9 September 2026 and two answered with a readable page: gemini.google.com declares a meta referrer of origin and copilot.microsoft.com declares origin-when-cross-origin, both of which keep the hostname and drop the path. - **Takeaway 4:** Four of those six hosts returned HTTP 403 to that same scan, so what chatgpt.com, chat.openai.com, perplexity.ai and claude.ai attach to an outbound click was not measured here and is not claimed. - **Takeaway 5:** Lantad's own Analytics integration requests two dimensions, date and pagePath, and no traffic source dimension at all, so it cannot read the AI Assistant channel out of a connected property and does not pretend to. ## Summary The GA4 AI Assistant channel is the row Google added to the Default Channel Group so a visit arriving from a chatbot stops being filed under Referral alongside every forum and newsletter. It needs no configuration and no tagging. For anyone who has spent a year trying to work out whether answer engines send real people to a site, it is the first measurement of that question that arrives switched on. It is also a measurement with a single input, and that input belongs to somebody else. The channel is decided by the Referer header a browser attaches when a reader clicks a link inside an assistant's page, and the assistant decides what that header holds, or whether it exists. The useful question is therefore not how to turn the channel on. It is what the products it is meant to catch actually send, and what one of its rows can support once it lands. We went and looked at the sending end on 9 September 2026, got a readable answer from two of the six hosts we asked, and this post reports both halves of that. ## What the GA4 AI Assistant channel is, in Google's own words The change is recorded in the Google Analytics release notes under the heading May 13, 2026, at support.google.com/analytics/answer/9164320. The entry states that Analytics now provides a dedicated way to measure and analyze traffic originating from popular AI assistants, and that a site owner can identify how users are discovering the site through chatbots like ChatGPT, Gemini and Claude via a new AI Assistant channel in Default Channel Group reports. Three dimensions move together. The medium takes a new value, ai-assistant, assigned automatically when the referrer matches a recognised AI Assistant. The visit is grouped under a channel called AI Assistant. The campaign is set to the literal string (ai-assistant), brackets included. Google's channel group reference at support.google.com/analytics/answer/9756891 states the matching rule in one sentence: the medium is set to ai-assistant and the campaign is set to (ai-assistant) if the referrer matches a list of AI Assistants. That same page describes the channel as the one by which users arrive at a site from sources like ChatGPT, Gemini, Deepseek, Copilot or Grok. Neither of those hosts is registered for outbound links here, so both are written as plain text rather than linked. The reporting side is documented where a developer would expect it: [sessionDefaultChannelGroup](https://developers.google.com/analytics/devguides/reporting/data/v1/api-schema) is a dimension in the Data API schema, described there as based primarily on source and medium, which means the AI Assistant grouping is queryable rather than confined to the web interface. Two things follow that are worth stating before any of the analysis. This is a first party grouping from the analytics vendor most sites already run, which puts it in a different class from any estimate a scanner can produce from outside, and that is genuinely useful. And it is a grouping of clicks, not of citations. A model can name your company in an answer that nobody clicks, and that answer leaves no row in any Analytics property at all. Counting the visits an assistant sends and counting the answers that mention you are two different measurements of [AI visibility](https://lantad.co/glossary/ai-visibility), which is why our [what an AI says about you](https://lantad.co/what-ai-says) surface and a channel report are not substitutes for each other. ## One header the assistant chooses to send decides the whole channel A referrer is not a fact about a visit. It is a string the previous page asked the browser to attach, and the previous page controls how much of it survives. The rules are set out in the W3C [Referrer Policy](https://www.w3.org/TR/referrer-policy/) specification, which defines the values a document may declare and what each one leaves behind. Under origin, only the serialisation of the origin is sent, for same origin and cross origin requests alike. Under origin-when-cross-origin, a same site request carries the full stripped URL and a cross site request carries the origin only. Under same-origin, a cross origin request carries no referrer information at all. A document declares its policy in one of two places, and both matter to this question. The [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy) response header sets it for the resource, and a meta element with the name referrer sets it in the markup. MDN records that when no policy is specified, or the value given is invalid, browsers apply strict-origin-when-cross-origin as the default, which sends the origin on a cross site request between two secure origins. That default is the reason the channel works at all for most products: an assistant that has never thought about referrer policy still leaks its own hostname to every site it links. The consequence for measurement runs in one direction only. Google's rule matches on the referrer, so anything that removes the referrer removes the visit from the channel and files it under Direct, whose definition on the same reference page is a source of (direct) with a medium of (none) or (not set). Nothing about that row says an assistant was involved. It is not mislabelled, it is unlabelled, and no amount of configuration at the receiving end recovers it, because the information never left the sending browser. This is the same problem in a different costume from the one we keep running into on the crawl side, where [a user agent is a claim rather than an identity](https://lantad.co/blog/a-user-agent-is-a-claim-not-an-identity). There the string can be forged; here it can be withheld. In both cases the site owner is reading a self report from a client they do not control, and in both cases the honest thing is to name the sender of the signal in the column heading rather than in a footnote. Our [scan methodology](https://lantad.co/methodology) says the same about every figure it produces. ## Six assistant hosts, fetched on 9 September 2026 The sample is not a view about which assistants matter. It is ASSISTANT_REFERRER_HOSTS in core/src/requestclass.ts, the list our own edge classifier uses to decide that a human arrived from an assistant, and it holds six hostnames covering five products: chatgpt.com and chat.openai.com for OpenAI, then perplexity.ai, gemini.google.com, copilot.microsoft.com and claude.ai. On 9 September 2026 each was fetched once over HTTPS with a desktop Chrome user agent, redirects followed, and the response recorded: the status, any Referrer-Policy header, and any meta element declaring a referrer policy in the returned HTML. Two of the six answered with a readable page. gemini.google.com returned HTTP 200 and 837,169 bytes carrying a meta referrer of origin. copilot.microsoft.com returned HTTP 200 and 38,594 bytes carrying a meta referrer of origin-when-cross-origin. Both of those values keep the hostname on a cross site click and discard the path, which is exactly what Google's matching rule needs and no more than that. Four returned HTTP 403. chatgpt.com refused directly; chat.openai.com redirected to chatgpt.com and then refused; perplexity.ai redirected to www.perplexity.ai and returned a 5,578 byte interstitial titled Just a moment; claude.ai returned a 5,549 byte page with the same title. Each of those four responses carried a Referrer-Policy header of same-origin, and that header belongs to the refusal, not to the product. Reporting it as the policy of ChatGPT or Claude would be exactly the error this blog exists to avoid, so the finding for those four hosts is that nothing was measured. What that limit is worth stating plainly. This scan reads the document served to an unauthenticated client at the site root. The page a reader actually clicks from is the signed in conversation view, rendered after authentication, and a single page application can attach rel="noreferrer" to an individual anchor and override the document policy for that link alone. So even the two readable results describe the shell rather than the answer surface. They are evidence about what those origins declare, not proof of what any particular citation link sends, and the same caution applies here as to any figure produced by fetching a page from outside, which is why our [crawler directory](https://lantad.co/tools/ai-crawlers) records the source of every string it lists and our [published research](https://lantad.co/research) prints its method next to its numbers. ## Two Google pages name two different sets of assistants The matching list is the part of this feature nobody outside Google can audit. The channel reference states that the medium is set when the referrer matches a list of AI Assistants and does not publish that list. What the two Google pages do offer is examples, and the examples disagree. The release note of 13 May 2026 names ChatGPT, Gemini and Claude. The Default Channel Group reference names ChatGPT, Gemini, Deepseek, Copilot and Grok. Two products appear on both, three appear only on the reference page, and one appears only in the release note. Neither page claims to be exhaustive, so this is not a contradiction, but it does mean a reader cannot learn from Google's documentation whether a given assistant is recognised today. Our own list has the same weakness and we should say so in the same breath. ASSISTANT_REFERRER_HOSTS is a hand maintained constant, six hostnames chosen by us, and it is a decision rather than a finding. It names Perplexity and Claude, which the reference page's examples do not, and it omits DeepSeek and Grok, which they include. That omission is not theoretical: when we counted where news citations came from we found [23 percent of them arriving from Grok while our registry read none of them](https://lantad.co/blog/geo-engine-grok-23-percent-of-news-citations), and a referrer list with the same gap will under count the same product in exactly the same way. The wider registry shows how differently the two sides of this problem have been treated. Our crawler registry in core/src/bots.ts holds 15 robots.txt tokens across 9 vendors, the same data behind the public [AI crawler directory](https://lantad.co/tools/ai-crawlers) and the [robots.txt tester](https://lantad.co/tools/robots-txt-tester). The referral side gets 6 hostnames covering 5 products. Fifteen tokens and nine vendors against six hostnames and five products is not a close call about which half of the problem has had the attention, at our end and, on the evidence of two example lists that do not match, arguably at Google's too. That asymmetry has a cause worth naming. A token belonging to an [AI crawler](https://lantad.co/glossary/ai-crawler) is published by the vendor because the vendor wants site owners to write rules for it, so the list is documentable and we have written a [directory of it](https://lantad.co/blog/ai-crawler-detection-is-an-ordering-problem). A referrer hostname is published by nobody. It is discovered by watching traffic, which means the only people who can maintain such a list accurately are the ones sitting in the request path, and a site owner with one property sees only the assistants that already send them somebody. ## What the channel cannot tell you, and what our own integration misses Start with the limit built into the good case. Both readable policies send the origin and nothing else on a cross site click, which means a perfectly working AI Assistant row tells you the product and never the prompt. You learn that somebody arrived from Gemini. You do not learn what they asked, which answer named you, or which of your pages the model had actually read. Anyone selling a report that maps assistant visits back to the questions behind them is doing something other than reading this channel, and that gap is the reason we treat [generative engine optimization](https://lantad.co/glossary/geo) as a measurement problem rather than a reporting one. Then the case that is invisible rather than partial. An assistant used inside a native mobile application is not a web document and need not attach any referrer at all, so those visits land in Direct with everything else. That is the same structural blind spot we wrote about when Cloudflare's own [crawl to refer ratio excluded native app referrals](https://lantad.co/blog/crawl-to-refer-ratio-excludes-native-app-referrals), and it cuts in the direction that flatters nobody: the channel can only ever be a floor on assistant traffic, never a count of it. Read a small number there as a lower bound and not as an absence. Now the part that is inconvenient for us. Lantad has an Analytics integration, and it cannot see any of this. The report request built in core/src/ga4.ts asks for two dimensions, date and pagePath, and three metrics, screenPageViews, sessions and totalUsers. There is no source dimension, no medium dimension and no channel group dimension in it, which means a property connected to Lantad today returns page level traffic with no idea where any of it came from. The AI Assistant channel could be full and our integration would report the same numbers it reports now. Adding a dimension is a small change and it is not the point; the point is that the gap exists today and a reader deciding what this product measures should hear it from us rather than discover it later. What that leaves a site owner to do is short and does not need a tool. Open the Default Channel Group report and confirm whether an AI Assistant row exists in your property yet. Compare it against Direct over the same window, because that is where the missing half is hiding. Check the pages those visits land on against the pages you would want an assistant to send someone to, which is a different question from whether the assistant can read them and is answered by [what GPTBot sees](https://lantad.co/tools/what-gptbot-sees) on your own URL, with the reading side covered per product in our [ChatGPT citation guide](https://lantad.co/how-to-get-cited/chatgpt). Do not expect AI Overviews in this channel: an AI Overview click and an ordinary search click both arrive from google.com, so nothing at the receiving end separates them, which is our reading of the rule rather than a statement Google makes, and it is why that surface has [a guide of its own](https://lantad.co/how-to-get-cited/google-ai-overviews). And treat the number as a floor throughout. When we measured the receiving end ourselves we found [ChatGPT citations landing overwhelmingly on the homepage](https://lantad.co/blog/chatgpt-citations-are-rare-and-land-on-the-homepage), and the referral share between vendors moves quickly enough that [ChatGPT held 80 to 88 percent of AI referrals while Meta took the crawl volume](https://lantad.co/blog/meta-took-the-crawl-volume-chatgpt-kept-the-referrals). Both of those are worth reading before drawing a trend line through four weeks of a channel that is under four months old. ## Questions and answers **What is the GA4 AI Assistant channel?** It is a Default Channel Group row that Google added on 13 May 2026, according to the Analytics release notes. When a visit's referrer matches a list of AI Assistants that Google holds and does not publish, Analytics sets the medium to ai-assistant and the campaign to (ai-assistant), and the visit is grouped under AI Assistant instead of Referral. No configuration or tagging is needed at the site's end. **Why would traffic from ChatGPT still show as Direct?** Because the channel is matched on the Referer header, and a click that arrives without one cannot be matched. A referrer policy of same-origin on the referring document removes it, and an assistant used inside a native mobile application is not a web document and need not send one at all. Those visits land in Direct, whose definition is a source of (direct) with a medium of (none) or (not set), and nothing in that row records which product the reader came from. **Can the channel tell me which prompt produced the visit?** No. The two assistant hosts that returned a readable page to our scan on 9 September 2026 both declare origin only referrer policies, and the browser default for a document that declares nothing sends the origin on a cross site request as well. An origin carries the scheme and hostname with no path and no query, so the conversation, the prompt and the answer text are all absent from the header by design. **Does Lantad read this channel from a connected Analytics property?** No, and that is a real gap rather than a policy. The Analytics report request in core/src/ga4.ts asks for the dimensions date and pagePath and the metrics screenPageViews, sessions and totalUsers, with no traffic source or channel group dimension among them, so a connected property returns page level traffic and no origin for it. Anything this site publishes about assistant referrals comes from our own edge classifier on our own requests, not from a customer's property. --- Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup. Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot