The value of analytics data depends on its accuracy, consistency, and governance. A structured approach to identifying AI assistant and AI search referrals can be appropriate where referral traffic is increasing, source classification is incomplete and the organisation needs a more reliable view of acquisition. It does not, however, recover sessions for which no referrer, campaign parameter or first-party signal exists.

AI assistants and search interfaces such as ChatGPT, Perplexity, Gemini and Copilot can send visitors to websites without preserving a usable source. These sessions may therefore appear as Direct in GA4 or another analytics platform. The result is a mixed channel containing genuine direct visits, privacy-limited traffic, app-originated traffic and potentially AI-influenced visits.

The framework below is intended to improve interpretation. Do not treat it as a method for proving that every unidentified session originated from an AI platform.

1. Why AI referral traffic arrives as direct

AI referral traffic can arrive as Direct when the analytics implementation receives no usable referrer and no campaign parameter.

A conventional browser link may send an HTTP Referer header containing the originating page or domain. An AI assistant may behave differently. The link may be opened from:

• A native mobile or desktop application.
• A logged-in interface with an embedded browser.
• A messaging or productivity application.
• An operating system link handler that does not preserve the originating page.
• A browser context with restrictive privacy settings.
• A page configured with a referrer policy that removes or reduces referrer information.

The W3C Referrer Policy specification describes how a document or application can control the information sent in the Referer header. A no-referrer policy omits the header. Other policies may send only the originating domain rather than the complete URL. User-agent controls may also suppress the header independently.

This creates several possible outcomes:

1. The AI domain is passed as a referrer and appears as a recognisable source.
2. Only the origin is passed, and the platform classifies the visit as a generic referral.
3. A campaign parameter is present and overrides the absence of a referrer.
4. No source signal is available, and the session becomes Direct.
5. Analytics consent is not granted, so the available attribution data is limited or absent.

The technical origin of a session and its classification are therefore separate matters. A visitor may have clicked an AI-generated recommendation, but the analytics platform may only receive a page load with no attributable source.

Recommended action:

• Document the possible navigation paths from each relevant AI assistant.
• Test links from native applications, web interfaces and embedded browsers.
• Record whether the landing request contains a referrer, campaign parameter or neither.
• Treat Direct as an unknown-source category rather than a complete representation of typed URLs and bookmarks.

2. How analytics platforms classify these sessions by default

GA4 uses rule-based channel definitions. Its documentation defines Direct as traffic with source (direct) and medium (none) or (not set). Referral is generally associated with non-ad links from other websites or applications. The relevant definitions are set out in Google’s documentation on the GA4 default channel group.

GA4 now also documents an AI Assistant channel. Its current rule requires the medium to be ai-assistant. Google indicates that the medium and campaign can be set when a referrer matches a recognised list of AI assistants. The default channel definitions also distinguish AI Assistant traffic from Google AI Overviews and AI Mode, which are classified under Organic Search.

This means that AI traffic can appear in several ways:

Domains such as chatgpt.com, perplexity.ai, gemini.google.com or copilot.microsoft.com may therefore appear in reports in some circumstances. Their absence does not demonstrate that the platforms sent no traffic. It may indicate that the link was opened through an application, a redirect, an embedded browser or a privacy-controlled environment.

The dimension’s scope also matters. Google distinguishes between first-user, session and event-scoped traffic-source dimensions in its documentation on traffic-source dimension scopes. A session-level source is more relevant when examining the origin of a particular visit. A first-user source describes the source that originally acquired the user and may not reflect the source of a later AI-influenced session.

3. Detection signals available in the data

No single signal is sufficient to identify AI-driven Direct traffic. A more useful approach combines several weak signals and assigns an appropriate confidence level.

Landing page patterns

AI assistants may link to explanatory, comparison, glossary or product-specific pages rather than the organisation’s homepage. A rise in Direct sessions to these pages may be relevant if the increase coincides with increased visibility in AI answers.

The landing page pattern should be assessed against:

• Page type and subject matter.
• New or unusually specific landing pages.
• Engagement and conversion behaviour.
• Geographic and device distribution.
• The date on which the content became visible or was updated.

A landing page is not evidence of an AI referral by itself. Search, email, social, documents and human recommendations can produce similar patterns.

Absence of UTM parameters

AI-generated links often arrive without manually assigned UTM parameters. This is also common for organic search, bookmarks, email clients, messaging platforms and copied URLs. UTM absence is therefore a supporting signal rather than an attribution method.

Referrer strings that do pass

Where a referrer is available, the raw page referrer or source dimension may contain a recognisable platform domain. The implementation should retain sufficient source information to distinguish:

• AI assistant domains.
• Search engine domains.
• Social and community platforms.
• Internal domains and payment providers.
• Unclassified external referrals.

Review the source list periodically. Platform domains and link-opening behaviour can change.

Device and browser context

Native application traffic may show a characteristic operating system, browser or in-app browser pattern. For example, a cluster of mobile sessions with no referrer and a particular browser context may be consistent with app-originated referrals.

This signal is not specific to AI. Messaging applications, social applications and email applications can create the same pattern.

Time-based and cohort analysis

A time series can identify changes in Direct traffic after:

• Publication of a new content resource.
• A change in AI assistant behaviour.
• A technical release.
• A major search or content update.
• A change in consent implementation.
• A change in referrer policy or redirects.

Cohort analysis can compare Direct sessions landing on potentially AI-visible pages with other Direct sessions. Useful measures include engagement, return rate, progression to product pages, lead submissions, downloads and purchases.

The output should be framed as an indicative association. It should not be described as proof of causation.

An organisation assessing these signals may also benefit from an independent analytics data quality review. Existing tagging gaps can otherwise be mistaken for evidence of AI attribution loss.

4. Using BigQuery export for source-level analysis

The GA4 interface is suitable for initial exploration, but BigQuery can provide greater control over session-level analysis. The GA4 BigQuery Export schema includes event tables, collected traffic-source fields and session-level last-click traffic-source records where available.

The relevant fields may include:

• collected_traffic_source.manual_source
• collected_traffic_source.manual_medium
• collected_traffic_source.manual_campaign_name
• collected_traffic_source.gclid
• session_traffic_source_last_click.manual_campaign.source
• session_traffic_source_last_click.manual_campaign.medium
• session_traffic_source_last_click.manual_campaign.campaign_name
• Event parameters such as page_location and page_referrer

Field availability depends on the export schema, property configuration, and event date. The implementation should validate the actual dataset before developing a reporting model.

A basic analysis can classify sessions into three groups:

1. Known AI referrals, where the source or referrer matches an approved AI domain list.
2. Direct sessions with characteristics associated with potentially AI-visible landing pages.
3. Other Direct sessions.

A simplified query pattern could resemble the following:

For session-level analysis, the organisation should first construct a session table. Event-level source data should not be counted as if every event represented a new visit. Session identifiers, event timestamps and traffic-source scope need to be handled consistently.

A separate classification table can hold:

• Recognised AI domains.
• Domain variants and subdomains.
• Effective dates for classification changes.
• Confidence levels.
• Notes on whether a source is known to pass a referrer or campaign parameter.

This approach lets you amend the reporting logic without rewriting historical queries. It also supports comparisons between the GA4 channel result and an organisation-defined AI referral indicator.

Recommended action:

• Confirm which traffic-source fields are populated in the property’s export.
• Build one row per session before calculating session counts.
• Maintain a version-controlled list of AI domains and source rules.
• Compare known AI referrals with Direct sessions by landing page, device and date.
• Preserve the original source and medium alongside any derived AI classification.

5. First-party methods for confirming AI-driven sessions

First-party methods can provide evidence that platform-level attribution cannot recover. They should be designed with privacy, consent and data minimisation in mind.

A voluntary survey can ask how the visitor found the organisation. Suitable options may include:

• Search engine.
• AI assistant or AI search.
• Social media.
• Email or newsletter.
• Recommendation from another person.
• Existing knowledge or bookmark.
• Other.

The question can be presented after meaningful engagement rather than immediately on the landing page. This may reduce disruption and improve response quality. The response should be stored as an aggregate or pseudonymous attribute only where the purpose, retention and access controls are defined.

Other first-party methods include:

• A source_hint parameter on links used in controlled content distribution.
• Referral codes for partner or community activity.
• Lead-form questions relating to discovery.
• CRM fields capturing the stated first-touch source.
• Post-purchase or post-enquiry surveys.
• A content feedback prompt connected to the relevant landing page.

These methods do not establish that an AI model caused a conversion. They capture a visitor’s reported discovery path. That distinction matters. A visitor may have used an AI assistant, then searched for the organisation separately, or may have encountered the organisation through multiple channels.

The ICO guidance on cookies and similar technologies states that organisations should explain the purpose of storage and access technologies and obtain consent where required. First-party attribution mechanisms should therefore be reviewed as part of the wider privacy and consent design. A privacy control should not be weakened merely to improve channel visibility.

6. Adjusting channel groupings and reports

A separate AI referral view may be preferable to changing the primary acquisition model immediately. This preserves comparability while allowing the organisation to assess the quality of the derived classification.

Possible reporting layers include:

Platform-recognised AI Assistant

This contains sessions already classified by GA4 as AI Assistant. It may be the most defensible group because the platform has applied a defined rule. It remains dependent on the availability and quality of the underlying source.

Known AI referral

This includes explicit referrers or campaign parameters matching the approved AI domain list. It may include traffic that GA4 classifies as Referral rather than AI Assistant.

Probable AI-influenced Direct

This contains Direct sessions that meet a defined combination of signals, such as:

• A landing page in an AI-visible content cohort.
• No referrer.
• No UTM parameters.
• A time-period increase aligned with other evidence.
• Behaviour consistent with the known AI referral cohort.

The label should include “probable”, “indicative” or another term that communicates uncertainty. It should not be presented as a confirmed traffic source.

GA4 supports custom channel groups that can create rule-based categories without editing the fixed default channel group. However, document and test custom rules. A channel definition can influence management reporting, comparisons and attribution interpretation.

Reports should distinguish:

• Sessions.
• Engaged sessions.
• Key events.
• Revenue or lead value.
• First-user source.
• Session source.
• Event-level attribution.
• Consent status and data availability.

A separate report can compare AI Assistant, known AI referral, probable AI-influenced Direct and unclassified Direct. This avoids presenting a modelled estimate as if it were a native analytics dimension.

Organisations reviewing the implementation may wish to align the reporting design with their wider Google Analytics consulting and tagging governance processes.

Recommended action:

• Create an AI referral reporting layer before changing executive channel definitions.
• Keep native GA4 channel data visible beside any derived classification.
• Use confidence labels for observed, probable and unclassified traffic.
• Document the domain list, rules, lookback period and validation method.
• Review the classification after changes to consent, redirects or analytics configuration.

7. The limits of measurement in this channel

The limits are structural rather than merely technical.

First, detection is probabilistic. A combination of landing pages, timing, device characteristics and Direct behaviour may indicate that AI referrals are being absorbed into Direct. It cannot identify the exact origin of each session.

Second, not all Direct traffic is AI traffic. Genuine direct visits, copied URLs, bookmarks, emails, documents, messaging platforms, privacy controls and broken campaign tagging can all produce the same (direct)/(none) classification.

Third, attribution is not causation. An AI assistant may introduce an organisation to a visitor, but subsequent activity may involve search, direct navigation, email or another source. A last-click report may assign the session to only one of these interactions.

Fourth, no framework can recover a session where no referrer, URL parameter, first-party response or other signal exists. Data modelling can estimate an unobserved category, but it cannot recreate unavailable evidence.

Fifth, consent affects the observable population. Where analytics storage is declined, event and source data may not be available in the same form. The resulting reports may therefore represent only a subset of all visits. The ICO guidance should be considered when designing any additional data capture.

The appropriate output is therefore an evidence-based range or directional assessment, not a claim of complete AI channel measurement.

8. When this framework is likely to be appropriate

This framework is likely to be appropriate where:

• Direct traffic is a material or increasing share of acquisition.
• The organisation publishes content likely to be cited by AI assistants.
• Lead generation or ecommerce reporting depends on reliable source analysis.
• Several domains, apps or platforms create complex referral paths.
• Marketing teams require a consistent view of AI Assistant and AI search activity.
• BigQuery export or another detailed event data source is available.
• First-party survey or CRM data can be collected within the relevant privacy requirements.
• There is evidence of explicit AI referrals, but their volume appears insufficient to explain business trends.

The work may be less urgent where AI-related visits are immaterial, acquisition reporting is not used for operational decisions, or the organisation has limited content exposure in AI assistants. It may also be less urgent where the available data is too sparse to support meaningful comparison.

9. A practical approach

A controlled implementation can be organised into five stages.

1. Establish the measurement design

Define the question that the reporting must answer. The objective may be to monitor explicit AI referrals, estimate the share of AI-influenced Direct sessions, or understand whether AI-visible content contributes to qualified demand.

The design should specify:

• Definitions for AI Assistant, known AI referral and probable AI-influenced Direct.
• The required level of confidence.
• Session, user and event scopes.
• Key events and commercial outcomes.
• Privacy and retention requirements.
• The owners responsible for review.

2. Map the technical architecture

Document how links travel from AI assistants to the site or app. This should include native applications, web interfaces, embedded browsers, redirects, consent banners, tag managers, analytics platforms, warehouses and reporting tools.

The map should identify where:

• Referrers may be removed.
• Campaign parameters may be lost.
• Redirects may change the landing URL.
• Consent may prevent analytics collection.
• Cross-domain configuration may alter session attribution.
• Server-side or client-side processing may change source values.

3. Implement with shared controls

Implement source preservation, event parameters, survey fields or reporting logic in a controlled manner. The solution should be aligned with the organisation’s tagging implementation services and change-management process.

Controls should cover:

• Naming conventions.
• Consent dependencies.
• Domain-list maintenance.
• Custom channel-group rules.
• Data retention.
• Access permissions.
• Documentation and ownership.

4. Validate before release

Testing should use known links and controlled navigation paths. The implementation team should confirm the expected result in the browser, analytics debugger, GA4 interface and, where applicable, BigQuery.

Validation should cover:

• Explicit AI referrers.
• No-referrer journeys.
• UTM-tagged links.
• Redirects.
• Mobile and desktop applications.
• Consent granted and consent declined.
• New and returning users.
• Multiple domains and app-to-web journeys.

5. Monitor after release

The classification should be reviewed over time. Platform behaviour, domain structures, browser controls and GA4 channel definitions may change.

Monitoring can include:

• Weekly or monthly source-volume checks.
• Changes in Direct traffic by landing page.
• New explicit AI domains.
• Data-quality alerts.
• Survey response trends.
• Differences between GA4 and BigQuery.
• Changes in consent rates.
• Conversion quality by confidence group.

A review record should state what changed, when it changed and whether historical data remains comparable.

Conclusion

AI assistant referrals may be underrepresented when links open from applications, embedded browsers, or privacy-controlled environments. A structured framework can identify explicit referrals and estimate possible AI influence within Direct traffic, provided the classification remains transparent and appropriately qualified.

The approach does not solve the underlying absence of referrer, campaign or first-party data. It does not make all Direct sessions attributable to AI, and it does not convert indicative associations into causal attribution.

Tool or platform capability does not remove the need for specification, testing, consent control, governance and operational ownership. Reliable reporting depends on preserving those controls as the channel develops.

If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant