An AI referral tells you something about how a visit was attributed. An agent identity check tells you something about the software making a request. A cart or checkout event tells you what your commerce system recorded.
Those signals can overlap. They answer different questions, and combining them into one “AI traffic” number can make the report harder to use.
In Would you recognize an AI shopper?, I suggested starting with one visit your team can explain. Here is how I would structure the reporting behind that conversation.
First, separate source, identity and action
Source: where did the recorded visit come from? A referral domain, campaign parameter or analytics attribution field can associate a visit with an AI service. Google Analytics defines session source as the source that initiated a session, while page referrer records the referring URL. Neither field is an agent-authentication result. Google Analytics dimensions
Identity: what supports the request’s claimed operator? A user-agent can name a service. Verification needs the applicable network, DNS, signature or authentication evidence. Keep the claim and the verification result together. Cartograph’s agent directory links to provider-specific guidance.
Action: what did the merchant system observe? A product fetch, cart update request, confirmed cart change and completed order are different events. Use the application or commerce record to establish the result, and retain the basis for connecting it to the request.
These are questions for your report, not a replacement for your platform’s existing event or traffic labels.
A user-triggered fetch does not establish autonomous shopping
OpenAI describes ChatGPT-User as a service used for certain user-initiated actions, including retrieving a page in response to a question. Perplexity makes a similar distinction between its search crawler and its user-triggered fetcher. A verified fetch can therefore establish that the named service requested a page without establishing that it was building a cart or buying something. OpenAI crawler documentation, Perplexity crawler documentation
Likewise, an AI referral does not prove that a human operated the browser. It also does not reveal how much of the earlier task was delegated. If your evidence only supports “AI-referred,” keep that description.
Build two views before trying to join them
Your acquisition view
Use the analytics report to examine recorded AI-referred sessions, landing pages and associated commerce events. Write down the report’s scope: session source, first-user source and event attribution are not interchangeable.
Keep a reviewed list of the referral hostnames and campaign values you include. Match parsed hostnames, rather than any URL containing a provider’s name. Record manual tagging separately from observed referrer data so a copied or incorrect campaign tag does not look like identity verification.
Missing attribution deserves a visible note. Google documents several reasons a visit may appear as direct traffic when its referral information is unavailable. Do not reassign an unexplained portion of direct traffic to AI on that basis. Google Analytics guidance on direct traffic
Your request-evidence view
Use authorized CDN, server and application records to inspect candidate automated requests. Preserve the provider claim, verification result, requested surface and recorded outcome. Mark sampled or incomplete coverage.
Expect differences from your analytics view. Google Analytics automatically excludes known bots and spiders, and does not expose a count of all excluded known-bot traffic. That does not establish that every automated request is excluded, or that everything remaining is human. Google Analytics known-bot exclusion
Join records only when the evidence supports it
A nearby timestamp and the same product are not enough to connect a crawler fetch to a later order. The same product can receive many unrelated requests.
Use merchant-controlled correlation evidence where it exists, such as an application request linked to a cart identifier and a recorded cart-to-order relationship. Confirm how identifiers are created, carried across systems and expired. Keep personal and authentication data out of the reporting export.
When the connection is unavailable, report the records separately. “No linked order in the available records” is more precise than “the agent did not buy.”
An observed handoff to a person or another checkout surface also needs its own evidence. Do not infer a handoff solely because one user-agent disappears and another appears.
Keep the units visible
A useful weekly report can have four clearly named sections:
- AI-referred sessions, with the analytics property, attribution scope and included sources
- Request identity evidence, keeping verified, claimed and unknown or unresolved records distinct, with the covered hosts and verification basis
- Recorded cart and checkout milestones, with the rule used to connect related events
- Missing evidence, including unavailable logs, unmatched identifiers and sampled periods
Do not add those numbers together. Sessions, requests, carts and orders are different units; one shopping journey can contribute to more than one section. A session-based conversion rate also cannot be calculated by dividing orders by a count of HTTP requests.
Keep the observation window and counting rules stable when comparing periods. If you improve a join or change a label, call out the change. More orders attributed to AI may reflect better measurement of existing business. Establishing additional sales requires a separate causal analysis.
What to ask before using the number
Ask your team: What exactly are we counting? Which source established the referral? Which evidence established identity? Which event established the shopping action? How were the records connected? What is still missing?
Those answers make the report useful for different decisions. Marketing can examine attributed visits. Engineering can investigate failed requests. Ecommerce can inspect cart and checkout progression. None needs a guess about what an external model thought.
Cartograph is being built around that merchant-side evidence. We are preparing for pilots; contact us to register your interest if your team is trying to connect these records. An inquiry registers interest only. Product access, setup and pilot terms would be agreed separately.
Sources checked October 16, 2026.