Skip to content

Your analytics can't see the buyer who arrived through an agent

AI agents skip your JavaScript and call your API, so pixel analytics misses them and the funnel starts at the cart. The first step isn't building an agent. It's visibility: server-side collection, one endpoint an agent can finish a job through, and a measured share of non-human arrivals.

analytics · measurement · founders

Your analytics can't see a buyer who arrived through an agent. An agent doesn't run the JavaScript your pixel depends on. It calls your systems directly. So the brief we expect founders to get next, "make our product usable by someone else's AI," has a smaller and cheaper first step than building anything. You make agent traffic visible, and then you measure how much of it you actually have.

The short version is here: {{anchor_url}}. This is the long one.

The mechanism, in the source's words

MetaRouter's post on agentic commerce trends and statistics (metarouter.io) puts it plainly: "AI agents do not trigger client-side JavaScript. They make API calls directly to merchant systems. Merchants relying on pixel-based tracking have measurement blind spots that grow as agent traffic scales."

The second half of the problem is where the funnel starts. In agent-mediated flows, per the same post, "the behavioural data stream starts at the add-to-cart moment." Discovery, browsing and narrowing down preferences all happen inside the assistant. Your dashboard gets the last step and none of the reasoning that led to it.

The product requirement follows from that. Invisible Technologies' post on agentic commerce in 2026 (invisibletech.ai) tells product teams to map API coverage across browse, cart, checkout, refunds, subscriptions and order changes, because "any workflow that is UI-only is invisible to agentic AI."

On the B2B side the same pressure arrives as a protocol question. Forrester predicted that 30% of enterprise app vendors would launch their own MCP servers in 2026. We know that figure second-hand, from Truto's 2026 guide to MCP for SaaS product managers (truto.one). It's a forecast for a year with three months left in it, and we haven't seen a count of whether it landed.

The honest half: the numbers disagree

Our view: this is the part a founder most needs and least often gets. Here are two figures that sit on the same search page:

Kaiser & Schulze, paper on SSRN      < 0.2% of e-commerce sessions come from ChatGPT referrals;
(papers.ssrn.com, abstract 5585812)  those referrals convert 86% worse than affiliate links

McKinsey (as cited)                  4.4x higher conversion for AI-generated recommendations

Those two can't describe the same thing. Most likely they measure different traffic, different definitions of "AI," and different moments in the funnel. The first is a paper you can open and check (SSRN): the channel is tiny and converts worse than affiliate links. The second is attributed to McKinsey on the pages we read, but we couldn't trace it to a dated report with a stated sample. We treat it as a claim in circulation, not a finding.

Our read, and it is an opinion: neither number is yours. A founder who can't say what their own agent traffic is has no answer when a board member quotes one of them back. That's the case for measuring before building.

Where delegation stops

The second thing the brief usually leaves out is a human. Visa's UAE study on AI shopping and fraud (visa.com) found that 85% of users accept AI in shopping assistance and fraud protection, but only 32% trust an agent to execute the checkout itself.

So most respondents accept an assistant's help with shopping, but most don't trust it to pay. We read that as a design constraint rather than a trust problem to market away. The agent-facing endpoint should let an agent do the work up to the commitment, then hand the commitment back to the person.

What we'd put in the first brief

This section is ours: how we'd scope it. It's three pieces, and none of them is an agent.

1. Collect on the server, not the page. If the pixel can't see an agent, the request log can. Classify every request that reaches the API, not every page that renders.

# runs on every API request, server-side
event = {
  ts, path, method, status,
  user_agent,
  session_id,
  had_page_view: session has any page render before this call
}

classify(event):
  if user_agent declares an automated client   -> "agent_declared"
  elif not event.had_page_view                 -> "no_page_view"
  else                                         -> "browser"

The rules aren't exact. A declared user agent is only what the client chooses to say, and "no page view" also catches your own integrations. That's fine for a first pass. The goal is a number you can argue with, not a perfect one.

2. One endpoint that finishes a job, with the person at the commitment step. Don't expose everything at once. Pick the one workflow an agent is most likely to attempt and make it completable without the UI, up to payment.

POST /orders/draft
  body: { items, delivery }
  -> 201 { draft_id, total, expires_at }       # agent can do this alone

POST /orders/{draft_id}/confirm
  requires: confirmation from the account holder
  -> 200 { order_id }                          # the person commits

The draft is cheap and reversible. The confirm step is where the money moves, and per the Visa figure, it's where trust runs out: only 32% trust an agent with checkout.

3. Measure the share, weekly. Two numbers are enough to start.

share_non_human = arrivals where class != "browser"
                  / all arrivals                          # per week

funnel_entry    = first event per session:
                  page_view | cart_create | draft_create  # where does the funnel start?

If funnel_entry starts shifting from page_view toward cart_create, you're watching the effect MetaRouter described happen in your own data.

What would change our mind

If a company runs this for a couple of months and share_non_human stays near zero, the "make us agent-ready" project isn't theirs to fund yet. That's a useful answer. It costs a logging change and one endpoint, not a platform. We'd rather a founder learn that from their own logs than from someone else's forecast.

Sources

FAQ

Why can't my current analytics just add an "AI" segment? Because pixel-based tools only record what happens when their JavaScript runs in a browser. Per MetaRouter, agents make API calls directly and don't trigger that script. There's nothing on the page for a segment to catch.

Is agent traffic big enough to care about now? The published numbers disagree. Kaiser and Schulze, on SSRN, find under 0.2% of e-commerce sessions come from ChatGPT referrals. A 4.4x figure attributed to McKinsey points the other way. Our view is that the only figure that settles it for you is your own.

Do we need an MCP server? Not as step one, in our opinion. Forrester's forecast that 30% of enterprise app vendors would launch MCP servers in 2026 tells you where analysts expected the market to go. It doesn't tell you whether your customers arrive that way. Measure first, then pick the protocol.

Should the agent be able to pay on the user's behalf? Visa's UAE study found 85% of users accept AI help in shopping and fraud protection, but only 32% trust an agent to run checkout. We'd design the endpoint so the agent prepares the order and the person confirms it.

A related case

We build products on the same split. In Kindling, our writing tool, the system does the preparation and the author makes the call. It drafts from the author's own reaction, and there's no autopublishing. The person edits and publishes. The case is at iloblique.com/kindling.

If your product needs to be usable by someone else's AI and you'd like to start with the measurement, we'd like to hear about it.