Gemini dropped utm_source=gemini: its iOS app traffic sits in GA4 Direct, and only a server log can count it

For about three weeks in September, links cited in Gemini answers carried utm_source=gemini. People who watch their logs saw the tag vanish around September 28, and Google has explained neither its arrival nor its removal. The coverage since then reads like Gemini traffic went dark. I pulled the numbers for three clients and my own site to see what that means in practice, and the answer is more annoying than dramatic. The tag was a short exception. Outside it, the one stable marker of the Gemini app is its user agent, and in none of the four setups I checked was that kept anywhere I could query.

What happened to utm_source=gemini in September 2026?

Gemini appended utm_source=gemini to some cited links from early September, and observers saw it stop around September 28 or 29. Natzir Turrado, who tracks this in server logs, saw tagged visits from about September 9, rising until roughly two in three Gemini-referrer visits carried the tag in the week of September 21, then dropping overnight (PPC Land, Turrado). PPC Land also notes scattered tagged visits into late October that nobody has explained. Search Engine Roundtable reported the stop on October 30; a Google employee had acknowledged seeing the tags weeks earlier, but there is no statement about why they went away.

Two things did not change. Desktop Gemini still sends a gemini.google.com referrer, and Turrado says those visits stayed flat throughout. The iOS app still opens links in its own WebView and sends no referrer.

My client data saw a narrower window. Where tagged visits showed up at all, every one fell between September 17 and 22, and nothing tagged arrived in the six days before the reported stop. The counts were small, so I read that as the tag reaching these sites rarely, and I wouldn’t argue for a different end date from it.

Where does Gemini traffic land in GA4 after the tag was removed?

For a new session with nothing else attributing it, desktop web visits land in the AI Assistant channel and iOS app visits land in Direct; Android app visits mostly land in Direct too. GA4’s default channel rules set the medium to ai-assistant when the referrer matches Google’s list of AI assistants, and the channel is defined by that medium. Direct requires the source (direct), which is what a visit with no referrer and no campaign tag gets.

The Android row is the hard one. Turrado found Android Gemini traffic in Direct “almost without exception”, and the app has no documented user agent of its own, so no log query isolates it. The iOS app does identify itself, which is why most of what follows is about iOS.

The last row is the part the headlines skipped. In GA4 a campaign tag takes precedence over the referrer, so a link carrying only utm_source=gemini gives the session the source gemini and the medium (not set). That matches none of the default rules: AI Assistant needs the medium ai-assistant, Direct needs the source (direct), Referral needs the medium referral, app or link. The session falls to Unassigned. The one tagged GA4 session I found on a client site is recorded exactly that way, as gemini / (not set). One session shows the mechanism and says nothing about volume.

So for a GA4 user, the tag could have moved Gemini web visits that would otherwise have been identified out of the AI Assistant channel for those weeks. Whether it also surfaced some app clicks that would have been Direct, I can’t tell from my data. Turrado’s logs show tagged visits without a referrer, so it may have.

What to check on your property:

1. In GA4, build a free-form exploration from 1 September to today with Session source / medium and Session default channel group, filtered to sources containing gemini.
2. Look for gemini / (not set) rows in September. If they sit in Unassigned, a channel-only comparison of AI Assistant across September and October is distorted for Gemini.
3. Trend both source variants, gemini.google.com and gemini, with their channel next to them, and keep a second counter if you have one.

What do Gemini and Direct numbers look like on real B2B sites?

Visible Gemini traffic was between 0% and 0.31% of sessions on every client property, while Direct ran from 19% to 52%. This is GA4, 1 September to early November, on seven client sites, shown as shares of sessions:

Two caveats apply. Some of these sites block GA4 until a visitor accepts the consent banner, and only a minority do, so every share there is a share of consenting traffic. And where the AI Assistant channel collected anything on the smaller sites, all of it came from chatgpt.com. Gemini is the minor assistant in this sample. That makes its app traffic harder to find: a few sessions a week disappear inside Direct’s ordinary day-to-day swing.

Web referrals did survive the tag. A server-side tracker on some of these sites kept counting gemini.google.com referrer pageviews through September and October at a similar, small level.

How do you find Gemini iOS app visits in server logs?

Search the raw access log for the app’s user agent token; this gives you request counts, and turning those into visits takes a second step. I couldn’t run any of it on the properties above, because none of them gave me a log to search, so what follows is the method and not a result.

Turrado and PPC Land describe the app’s user agent as containing a GeminiiOS token with a version number alongside a WebView marker:

GeminiiOS/<version>
GoogleWv/1.0 (WKWebView)

Versions change with every app release, so match the prefix. In the nginx or Apache combined log format the user agent is the sixth field when you split a line on double quotes, which is safer than grepping the whole line:

# 1. requests whose user agent is the Gemini iOS app
awk -F'"' '$6 ~ /GeminiiOS\//' access.log > gemini-ios.log
wc -l < gemini-ios.log
 
# 2. requested pages (assets dropped, query string removed)
awk -F'"' '{ split($2, r, " "); p = r[2]; sub(/\?.*/, "", p);
  if (p !~ /\.(css|js|png|jpe?g|gif|svg|webp|ico|woff2?)$/) print p }' gemini-ios.log \
  | sort | uniq -c | sort -rn | head -20
 
# 3. rough daily visitors: distinct IP + user agent per day
awk -F'"' '{ split($1, a, " "); print substr(a[4], 2, 11), a[1], $6 }' gemini-ios.log \
  | sort -u | cut -d' ' -f1 | uniq -c

Step 2 lists every page those visitors requested, entrances and later clicks alike. Step 3 is the closest a raw log gets to a visitor count without real sessionisation, and an IP plus user agent is not a person.

Put the daily numbers from step 3 next to GA4’s Direct users for the same days and pages. Report them side by side rather than as a share of Direct: the log counts requests from everyone, GA4 counts only what its tag saw, and the two units don’t divide cleanly. If the log shows dozens of Gemini app visitors a day and Direct moves by a handful, you have learned something either way.

For scale, Turrado’s own estimate is that Gemini makes up at least 0.05% to 0.23% of Direct in a normal week. He gets there by adding the identifiable iOS app traffic to the referrer-less visits the tag exposed while it lasted, and he doesn’t publish the sites or the calculation, so I read it as one practitioner’s floor and nothing more general.

What if you have no user agent logs for Gemini traffic?

Then the useful work is finding out where the user agent was dropped. In none of the setups I checked was it kept anywhere I could query, and the reasons are the common ones: managed hosting without server access, CDN logs in an account the site team doesn’t hold, access logs kept for days in a hosting panel, and analytics that store a parsed browser and OS instead of the user agent string. A tracker that reduces the user agent to buckets on purpose, because a full user agent is fingerprinting material, can only flag the Gemini app if that check runs at collection time. Nothing can add it to data already stored.

A parsed browser bucket gives one partial signal. Some parsers, Umami’s among them, have a bucket for iOS in-app WebViews. On my own site only a handful of Direct visitors fell into it in a month, a tiny fraction of Direct. I don’t know whether the parser puts Gemini’s WebView in that bucket, so it tells me how small the visible part is and nothing about Gemini. Web referrals still arrive without the tag.

If you have no logs either, the realistic options are short:

1. Ask your host or CDN what it keeps and for how long. Retention is often days. A one-week export of raw logs is enough to run the check above once.
2. Look at the parsed browser bucket you already have. It shows in-app browser traffic as a group, with no app named.
3. Decide what to compute at collection time. If you run your own tracker, a check for GeminiiOS/ where the user agent is parsed is cheap. It is one regular expression and a new bucket value; the work is deploying it everywhere the tracker runs.

Why the Gemini UTM change matters for ChatGPT tracking

Because ChatGPT attribution leans on its tag even harder, and that tag has already gone missing once. A first-party tracker on some of the sites above recently started labelling AI-assistant traffic. In its first days it put about 0.5% of pageviews in that label, and more than nine in ten of them arrived with no referrer and only utm_source=chatgpt.com, so under the tracker’s earlier rules they would have counted as Direct.

A few days on a few sites is an illustration, and I wouldn’t call it a statistic. It still says what would happen in that setup if ChatGPT dropped its tag the way Gemini did: more than nine in ten of the AI visits it currently identifies would land in Direct, assuming nothing else about those visits changed. Turrado saw ChatGPT links go out untagged from October 7 to 16 and lost 68% to 74% of ChatGPT visits in his logs over that window; a report of tags returning came on October 15 (Search Engine Roundtable). On my own site, ChatGPT shows up through the tag and almost never through the referrer, which I wrote up in what a ChatGPT conversion rate can and cannot tell you.

The same tracker had found the opposite problem earlier on one B2B site: about one lead in twenty came in a session with a ChatGPT or Perplexity referrer, and every one of them was filed under referral. Neither direction generalises. A channel built on one signal, a tag or a referrer, breaks the day that signal changes, and you only notice if you were also recording the other.

How much AI traffic hides in GA4 Direct? My take on Gemini and the rest

My read is that visible AI traffic is a floor and the real number is larger. I don’t trust GA4’s AI Assistant channel to measure it. Where GA4 waits for consent, it never sees the visitors who decline, and in any setup a visit with no referrer and no tag lands in Direct whatever app it came from. How much larger the real number is depends heavily on the country, the industry and the niche. I would not hand a client one figure for “AI traffic in Direct”, and I don’t think anyone without their own logging can honestly give one.

What bothers me most in that table is the column that isn’t there. With a user agent on any one of the seven rows, I could have answered the question instead of describing how you would.

So the advice is the boring one. If you need this data, run your own first-party analytics, not tied to an external vendor’s definitions, and decide at collection time what you keep. A vendor’s channel is somebody else’s rule set, and September showed the signal behind it can change without notice. The same holds for measuring AI visibility over time: evidence you didn’t record when it arrived can’t be recovered by a later analysis.