What Our AI Referral Audit Proved Before We Published an AI Traffic Benchmark

We started our AI referral audit with the denominator

Our AI referral audit began with what looked like a large measurement estate. The Google OAuth principal available to Vix could see 95 Google Analytics 4 properties. Vix Command Center had 22 GA4 identifiers configured across 24 site rows. The obvious move was to turn one of those counts into a portfolio benchmark.

We stopped before doing that. Our search engine optimization services depend on knowing which production websites we are actually measuring, not how many records an account can see. Access inventories can contain internal sites, former clients, applications, test properties, duplicate rollups, staging environments, and properties with no useful data.

That distinction changed the assignment. Before we could ask how much traffic AI assistants sent, we had to establish which websites were eligible to be counted at all.

The first direct read proved access, not AI traffic

The read-only production route successfully queried all 22 GA4 properties already configured in Command Center for a 90-day request. It returned 66 source and medium sample rows, exactly three rows for each property, without a query failure.

We applied version 1.0.0 of our AI referral classifier to those observed source values. The classifier recognizes clearly identifiable assistant hosts such as ChatGPT, Perplexity, Claude, Gemini, Bard, and Meta AI. It does not classify every Google, Bing, or Direct session as AI traffic.

No identifiable assistant host appeared in the 66 returned rows. That result was useful, but it was not a finding of zero AI traffic.

A truncated sample cannot prove absence

The route returned sample rows rather than a complete acquisition export. A source that does not appear among three rows can still appear elsewhere in the property report. Treating non-observation in that sample as zero would turn a route limitation into a portfolio claim.

What the test actually established was narrower:

• The read-only path could query the 22 configured properties.
• The request completed without a property-level query failure.
• The returned source fields could be inspected by a versioned classifier.
• A complete source extraction was still required before calculating prevalence or volume.

That is a less dramatic conclusion than “AI sends no traffic.” It is also the only conclusion the returned data supports.

The obvious denominator was not a client cohort

The 95 visible GA4 properties are an access inventory, not 95 websites. The 22 configured identifiers are a reporting subset, not the authoritative active-client roster. The 24 Command Center site rows describe onboarding state, not analytic eligibility.

A defensible cohort starts with direct estate discovery and ends with one normalized production website per approved row. We need to identify the web stream behind each GA4 property because an account summary does not reliably tell us which production hostname the property measures.

We designed an exclusion log before the benchmark

Each candidate website must pass the same coverage rules. For this referral study, an eligible row needs:

1. A queryable GA4 web property tied to a production hostname.
2. A match to the authoritative active-client roster for the reporting period.
3. Complete data for the fixed analysis window.
4. Nonzero total sessions for a usable denominator.
5. No known tracking outage that compromises the period.
6. A recorded timezone, launch status, and exclusion decision.

We will exclude internal Vix properties, staging sites, applications, duplicate rollups, empty properties, former clients outside the approved period, and properties that cannot be queried. Every exclusion will carry a reason so a later reviewer can reconstruct the denominator instead of trusting a final count.

Identifiable AI referrals are a measured lower bound

GA4 can use a document referrer to assign traffic-source dimensions when stronger campaign information is unavailable. Google’s traffic-source documentation also explains that traffic can be processed as Direct when referral-source information is unavailable or configured to be ignored.

That behavior creates a clear measurement limit. If an assistant preserves a recognizable referrer, we may classify the session. If the referrer is stripped, unavailable, routed through another surface, or indistinguishable from a conventional search domain, source-level GA4 data may not identify the assistant.

We therefore describe identifiable AI referral sessions as a lower bound. We do not use Direct as a proxy, and we do not relabel all traffic from Google or Bing as AI-influenced demand.

Our classifier protects ambiguity instead of erasing it

A versioned classifier needs more than a familiar list of brands. Before freezing a release, we inspect the leading observed source values, verify hostname variants manually, and preserve ambiguous sources in a separate bucket.

The classifier also records its own version beside the output. If a new assistant domain appears later, we can rerun the same raw data with an updated rule set and explain why the count changed. Without that record, a benchmark can move because of an invisible taxonomy change rather than a change in customer behavior.

We keep four measurement planes separate

The easiest way to overstate AI search performance is to blend visibility, visits, conversions, and revenue into one narrative. We maintain separate ledgers because each plane answers a different question:

• Citations or impressions show that a platform surfaced or used a page.
• Visits show that analytics or a search platform observed a session or click.
• Conversions show that a defined key event, lead action, or qualified outcome occurred.
• Revenue shows verified transaction value or documented downstream value.

A citation is not a visit. A visit is not a lead. A lead is not revenue. A cited page may create awareness without a trackable referral, and an identifiable referral may never complete a configured key event. A later sale can occur through another session, device, or channel.

This separation is also why native AI visibility reports cannot supply the missing GA4 referral count. Platform visibility and web analytics measure different events.

The complete study requires a frozen property manifest

Our next step begins with all directly visible GA4 properties, not only the Command Center subset. We will list their web data streams, normalize hostnames, and reconcile the resulting websites against the approved active-client master.

We will lowercase hosts, remove protocol and `www`, strip trailing slashes, and keep subdomains distinct until manual review. Duplicate properties and overlapping implementations will be resolved before analysis, not averaged together afterward.

We will pull complete session-scoped acquisition data

For each eligible website, we will query daily session source, medium, landing page, users, sessions, engaged sessions, and consistently configured key events. Google’s GA4 Data API schema documents session-scoped traffic-source dimensions, but dimension and metric compatibility still has to be tested before batching a report.

The resulting analysis will report:

• The number of eligible production websites.
• The number and percentage with at least one identifiable AI referral session.
• The share of all sessions attributable to identifiable assistant hosts.
• Property-level medians and interquartile ranges.
• Pooled totals in a separate view so large sites do not dominate the portfolio story.
• Leading AI landing pages and their engagement behavior.

Conversion comparisons will include only sites with audited key-event definitions. Revenue comparisons will include only sites with consistent revenue or lead-value instrumentation. An unavailable field will remain unavailable rather than being estimated from another measure.

What we would do differently in the next access audit

We would separate estate discovery, cohort construction, and metric extraction at the beginning of the project. The initial reporting route was useful for confirming access, but its three-row sample encouraged a conclusion it could not support.

Our revised sequence is explicit:

1. Discover every property available to the authorized principal.
2. Resolve each property to its production hostname and client status.
3. Freeze one article-specific eligibility manifest.
4. Pull complete source reports for the fixed period.
5. Audit source values before finalizing the classifier.
6. Calculate site-level distributions before pooled totals.
7. Attach the numerator, denominator, period, source file, and code version to every published statistic.

This sequence costs more time than exporting one dashboard. It also makes the study reproducible when the portfolio, platform fields, or assistant landscape changes.

How Vix turns an AI traffic audit into operating infrastructure

An AI referral benchmark is only useful when it connects discovery to business outcomes without collapsing the steps between them. Our attribution tracking work preserves channel definitions and reporting lineage. Our CRM configuration work carries qualified records beyond the analytics session.

The wider Vix operating system connects search authority, analytics, development, customer relationship management, and lead follow-up. That coordination matters because a visibility signal can create a research question, but it cannot answer what happened after the visit by itself.

We did not publish a percentage from the 66 sampled rows. We did not call 95 visible properties an analyzed client cohort. We proved that the direct reporting path worked, identified why the first sample was incomplete, and designed the manifest needed for an honest benchmark.

That is the authority claim we can support now. We would rather delay a larger number than publish a denominator we cannot defend.