How to Set Up Analytics for AI Search Referrals

Your analytics dashboard shows a traffic spike from a chat assistant one afternoon, then nothing for two weeks, then a different assistant with a different referrer name sends a single visit that never appears in the platform at all. None of that is a data glitch. It is what AI referral traffic actually looks like, and teams that want to measure it need a different setup from the one they use for classic search.

The problem is not that the data is missing. It is that the measurement model was built for a world where every visit carried a stable, meaningful referrer and every page view executed JavaScript. Both assumptions break when the referrer is an assistant.

Why AI Referrals Break Classic Search Reporting

Classic search attribution relies on a stable chain: a query lands on a result page, the user clicks through, the referrer names the search engine, and the analytics platform files it under a known source and medium. Reporting then becomes a question of reading a well-formed table.

AI referrals break that chain at three points. First, the referrer may not be present at all. A user might follow a link from an assistant in a way that strips the referrer entirely, arriving at your page looking like direct traffic. Second, the referrer may name a shared or proxied domain rather than the assistant the reader was actually using. Third, an increasing share of automated fetches never execute your page scripts, so a client-side analytics tool sees nothing at all even though the server delivered the page.

There is a fourth, subtler problem: link decoration. Assistants frequently rewrite or strip tracking parameters when they reproduce a URL. If your tagging scheme depends on a UTM value surviving the hop, you will find that a meaningful share of assistant referrals arrive unlabelled, no matter how carefully you built the original link.

Know which layer is telling the truth

The practical consequence is that no single tool gives you a complete picture. The analytics platform sees what the browser executes. The server log sees every request the origin receives, including requests from automated agents that never run a script. You need both, and you need to know which question each one answers.

Set Up a Session Segmentation and Filter Set

Before touching reporting, decide how you will classify AI referrals. Do this as a named list, not a loose rule, because referrer values shift over time and an undocumented heuristic quietly rots.

A workable approach is a lookup table maintained in one place, mapping the referrer domains and path prefixes you observe to a canonical segment. The canonical segment should be something like "AI Assistant" for the rollup and a second field naming the specific source you observed, so you can keep both views.

1. Collect every distinct referrer value that arrives with a request and is not a known search engine, social network, or your own domain.
2. Group those values into canonical segments: chat assistants, answer engines, and coding assistants are the three that usually matter.
3. Record the date you created each mapping so you can explain later why a given session was classified the way it was.
4. Apply the mapping in your analytics platform as a session source and medium, so AI traffic appears as its own row rather than being scattered into direct or referral buckets.
5. Keep the list under version control or at least in a shared file with a changelog, because referrer domains do change.

Handle the unlabelled remainder

Some AI traffic will never produce a recognisable referrer. Do not try to force it into the assistant bucket by guesswork. Track it separately as "unattributed AI-pattern traffic" if you have a defensible way to identify it, and be honest in reporting that this bucket is an estimate. A team that reports an inflated number loses credibility the first time someone checks.

Count Referrals in Server Logs When Referrers Are Stripped

Server logs are the fallback that catches what the analytics platform cannot see. A typical web server log line already contains the request path, the referring page, the user agent, the status code, and the timestamp, which is enough to build a reliable count.

Filter your log for request paths that correspond to real content pages, then group by the referrer field. Filter out your own asset requests, your internal monitoring, and any obvious automated non-assistant traffic using a maintained user agent exclusion list. Excluding automated traffic matters more here than in classic search, because agent-driven fetches can outnumber human visits and would otherwise dominate any raw count.

Then build a second count based on user agent patterns for known assistant crawlers and agents. This count measures how often your content was retrieved for an answer rather than how often a human arrived from an answer, and both numbers are useful but they answer different questions.

Decide which number goes in the headline

Referral sessions and assistant retrievals are not the same metric and should never be added together. A single assistant retrieval can surface your page to thousands of readers, and a single human referral session can be the only person who ever sees it. Most teams should lead with referral sessions as the traffic number and report retrievals separately as a content-reach signal.

A further refinement: retrieval requests that include a full URL path for a specific article usually mean the assistant selected that article for a citation. Retrieval of your sitemap or your homepage usually means the assistant fetched it while browsing broadly. Separating those two patterns tells you which pages are actually being cited as sources, which is often the more actionable number.

Reconcile Server-Log Counts with Analytics-Platform Counts

The two sources will not match, and building a reconciliation step prevents a month of confusion when someone asks why the numbers differ.

The most common cause of a gap is automated traffic that never executes JavaScript, which the analytics platform misses entirely. The second most common is referrer stripping, where the session arrives as direct traffic in the platform but is visible in the log. A third cause is time zone and date-boundary handling: log timestamps are often in server time while the platform reports in a chosen reporting time zone, and sessions spanning midnight can land on different days in the two systems.

A workable reconciliation is simple. Pick one week. Take the log-derived AI referral session count. Take the platform-derived AI referral session count. Calculate the difference and write down which of the three causes explains most of it. Repeat for a second week. If the gap is stable, you have a reliable correction factor and can present both numbers with confidence. If the gap swings wildly, the cause is probably something else, and you should describe the discrepancy as unresolved rather than inventing an adjustment.

Build a Weekly Sheet a Marketing Lead Can Read

The deliverable that turns this into something a team acts on is a single sheet with fixed columns and one row per week. Keep it small enough that someone will actually open it.

1. Week commencing date.
2. AI referral sessions, from the analytics platform using your canonical segments.
3. AI referral sessions, from server logs, after exclusions.
4. The difference between the two, and the cause you attribute to it.
5. Assistant retrievals of your content, from server logs, split between article URLs and broad crawls.
6. Which specific pages were retrieved most often.
7. The number of tracked questions in your visibility panel that mentioned you this week.
8. Notes on any content change you published, since attribution without a change log is guesswork.

That last column is the one teams skip and then regret. If a page's retrieval count doubles the week after you rewrote it, you want that on the record rather than reconstructing it from memory three months later.

Build the sheet so each week is appended, never overwritten. The value is entirely in the trend line, and a single week tells you almost nothing about whether your strategy is working.

Summary: Where to Start

Start by pulling three weeks of server logs and listing every distinct referrer value you did not recognise. That list is the raw material for your canonical segment mapping, and it is also the fastest way to discover which assistants actually send your readers. Next, build the mapping, apply it in your analytics platform as a session source, and confirm the counts move. Then set up the log-based fallback with a maintained user agent exclusion list, so you can count what the platform misses. Once both numbers exist, run a single reconciliation week and write down what explains the gap. Finally, create the weekly sheet with the columns above and append to it every week without exception.

Give this work one owner and one recurring slot in the calendar. It is not a project that benefits from a burst of attention followed by silence; the trend is the whole point.

Frequently Asked Questions

How do I tell AI assistant traffic apart from ordinary referral traffic in my analytics? Build a documented lookup table of the referrer domains you observe, map them to canonical segments such as chat assistants or answer engines, and apply that mapping as a session source and medium in your analytics platform. Keep the table in a shared file with a changelog, because referrer domains change and an undocumented heuristic becomes unreliable without anyone noticing. Segments should be maintained deliberately rather than generated ad hoc each time a new referrer appears.

What should I do when AI referrals arrive with no referrer information at all? Accept that a portion of AI traffic is unattributable and measure it in two places instead. Use server logs as the fallback, since they capture requests the analytics platform may never see, and look for assistant user agent patterns among requests that carry no referrer. Report that bucket separately as an estimate rather than folding it into the assistant segment, because inflating the headline number undermines trust in the rest of the report.

How often should I reconcile server log counts with analytics platform counts? Run a formal reconciliation once a month over a full week, and spot-check whenever the two figures diverge sharply. The gap is usually explained by automated fetches that never execute JavaScript, stripped referrers landing as direct traffic, or time zone differences at date boundaries. If the gap is stable across two reconciliation periods, you can present both numbers with a stated correction factor; if it swings, describe it as unresolved rather than adjusting figures to fit.