Check who wrote the tracking parameter

A tracking parameter is only an attribution signal if you know which party wrote it into the URL, because anything running between the search result and your server can add one.

That point got a clean demonstration this week. On October 2, 2026, Tom Pool reported seeing ?st_source=ai_overview appended to links inside Google AI Overviews, including links in the source list, and asked whether this was the start of proper attribution reporting. Search Engine Roundtable covered it as a possible Google test. The story was then updated: Pool found that a Chrome extension was rewriting the URLs, and suggested the purpose was to sell the data to brokers.

By that account, the parameter never came from Google. It still looked exactly like the thing many SEO teams have been waiting for: a clean label on AI Overview clicks. If that extension had a meaningful install base among your visitors, some of them would have arrived at your site carrying a tag that says "AI Overview", and an analytics rule written to catch it would have counted them.

#Why the parameter was believable

The demand for AI Overview attribution is real, and the official supply is thin. Google's own documentation says that sites appearing in AI features such as AI Overviews and AI Mode are included in the overall search traffic in Search Console and reported within the "Web" search type. There is no Google-issued URL parameter that marks a click as coming from an AI Overview. Referrers from Google say "google", not which part of the page was clicked.

Other platforms already tag their links, which makes a new tag feel plausible. ChatGPT appends a UTM parameter to outbound links and in 2025 extended it to links in the "More" section of a response. Google itself appends srsltid to organic results when a merchant turns on Merchant Center auto-tagging, which SISTRIX documents as an opt-in conversion tracking feature that is off by default. So a short, descriptive parameter showing up on Google links did not look strange. It looked overdue.

#Extensions sit inside the click path

A browser extension with the right permissions can read and modify every page a user visits, including Google's results page. Rewriting outbound links on that page is trivial. The motive usually comes from one of two business models.

The first is affiliate and referral revenue. In March 2025 Google tightened Chrome Web Store rules so that extensions may only add affiliate links, codes, or cookies when there is a direct and transparent user benefit tied to the extension's core function, and may not inject them in the background without a related user action. That policy followed the PayPal Honey controversy, in which the extension was accused of replacing creators' affiliate codes with its own.

The second is data collection. In December 2025 Koi Security found that Urban VPN Proxy and three related extensions, with over 8 million users across the Chrome Web Store and Microsoft Edge Add-ons, had been capturing conversations with AI assistants since July 2025 and sending them to the developer's analytics servers. Urban VPN Proxy carried a Featured badge in the Chrome Web Store at the time. A store listing, a badge, or a large user count tells you nothing about what an extension does to the URLs your visitors click.

The st_source case fits the second pattern. A parameter that labels where a click came from is useful to whoever reads it later, whether that is the extension's own backend, a data buyer, or your analytics tool by accident.

#How an unverified parameter corrupts a report

Most analytics setups treat a query parameter as a statement of fact about the visit. Channel grouping rules, landing page reports, and AI traffic dashboards all match on strings. When a new string appears, the usual reaction is to add a rule for it.

That works when the parameter has a known issuer and a documented meaning. It fails when the parameter is written by software installed on some visitors' machines and not others. The resulting segment is no longer "visits from AI Overviews". It is "visits from AI Overviews by people who run one particular extension", mixed with whatever else that extension tags. The count moves when the extension gains or loses users, ships an update, or gets removed from the store, and none of those events has anything to do with your visibility in Google.

The error is also hard to see after the fact. A dashboard line labelled "AI Overview clicks" that rises for three weeks looks like good news. It does not announce that it is measuring an extension's install curve.

#What to do instead

Keep a parameter register. For every query parameter you use in attribution, record who issues it, where that is documented, and when you confirmed it. utm_source=chatgpt.com has a documented issuer. srsltid has a documented issuer and only appears if you enabled auto-tagging. A parameter you first saw in a LinkedIn post does not belong in a channel rule until it has an issuer you can point to.

Check that the signals agree. A genuine platform tag should arrive with a consistent referrer and appear across browsers and devices. If a supposed Google parameter only shows up on desktop Chrome, or arrives with referrers that do not match the claimed source, treat it as a client-side artifact. Server logs are useful here because they record the raw request before any analytics script interprets it.

Reconcile against Search Console. Google reports AI Overview and AI Mode activity inside Search Console's Web search type. If a parameter-based segment implies far more AI Overview clicks than Search Console's Google totals could contain for those pages, the parameter is wrong, not Search Console.

Do not strip what you cannot explain, either. Some teams react to stray parameters by stripping all unknown query strings at the CDN. That also removes legitimate tags. Log unknown parameters to a separate field, review them on a schedule, and promote one to a channel rule only after it passes the checks above.

Annotate when you change a rule. If you add or remove a channel definition, write the date down next to the chart. An undocumented rule change looks identical to a real shift in traffic when someone reviews the chart later.

#The broader lesson for AI visibility measurement

AI search attribution is immature, and that makes it easy to fill gaps with signals that look right. A parameter, a user-agent string, or a referrer header can each be produced by software you do not control. The st_source episode was caught quickly because the person who spotted it went back and traced its source. An artifact that nobody checks can sit in a client report as a trend line for months.

The fix is procedural rather than technical. Treat every new attribution signal as a claim, name the party making it, and confirm it against an independent source before it drives a decision.