# How to measure generative UI

> When the interface is composed for each visit, the page stops being a stable unit and classic analytics break down. Measuring generative UI means recording the surface shown, the components in it, and the decision that produced it.

_Last updated 2026-10-24. From The Generative UI Guide, https://generativeui.guide_

Analytics assumes a stable interface. You count views of a page, steps through a funnel,
clicks on a button that is in the same place for everyone. Generative UI removes the thing all
of that rests on. When the interface is composed for each visit, there is no shared page to
count, because two people on the same route saw different screens. This is the least settled
part of generative UI, and it is the part most teams discover last.

## The page stops being a unit

A funnel is a sequence of pages that enough people pass through to measure. It works because
the pages are fixed: the checkout step is the same checkout step for everyone, so counting
arrivals and exits tells you something. Once the checkout is assembled per visit, the step is
no longer one thing. The number of people who "saw the checkout" is still countable, but what
they saw varied, so the number no longer explains the behavior underneath it.

The same problem shows up in every classic report. Heatmaps average positions that were never
fixed. Session replay shows one assembled screen and implies it was the screen. Conversion by
page compares pages that were different for each visitor. None of these is wrong exactly. They
are answering a question, how did people respond to this interface, that no longer has a single
interface in it.

## New units: surface, component, decision

The way through is to stop measuring the page and start measuring the parts that are stable
across visits. Three units survive generation.

- **The surface.** A renderable region the system created for a visit: a screen, a panel, a
  card. It has an identifier even though its contents vary.
- **The component.** A single item from the catalog, with its own identifier, wherever it
  lands in the layout. A price comparison module is the same component whether it appears
  first or fourth.
- **The decision.** The choice that produced the surface: the specification the renderer drew,
  the state that fed it, and any model output or seed. This is the unit most teams forget, and
  it is the one that makes the other two interpretable.

Keyed this way, the questions come back. How often does this component get composed into a
surface, and what happens when it does. Which decisions lead to the outcomes you want. How a
given person's screen was assembled, and why. The interface is different every time, but the
components and the decisions are countable.

## Where to capture it

The capture point is wherever the decision and the render happen, which is usually one of two
layers. If an agent drives the interface, its event stream is the natural place: the protocols
that carry generative UI, AG-UI among them, already emit typed events for tool calls, state
changes, and the lifecycle of a turn, and those events are where a component was chosen and
shown. If a renderer draws from a catalog, the renderer is the place: it knows the
specification it received and the components it drew, and can emit an event per surface and per
interaction.

Either way, the model to aim for is a schema keyed to component and surface identifiers,
recorded as the interface is composed rather than reconstructed afterward. This needs the same
thing the interface itself needs: a store of behavioral state that is current on the request.
A pipeline built for real-time behavioral events is a natural home for it, because the events
that drive the decision and the events that record what was shown are the same kind of data.
[Snowplow Signals](https://signals.snowplow.io/learning/generative-ui) is one such pipeline: it
computes state from behavioral events as they happen and serves it back to the application,
which means the decision and the record of it can run through one place.

## Keep a record of what was shown

There is an accountability version of the measurement problem, and it is sharper than the
reporting one. If every visitor sees an interface composed for them, the question "what did
this person see?" has no answer unless something wrote it down. Support cannot reproduce a
complaint. An audit cannot check what was served. A regression cannot be confirmed, because
there is no fixed screen to compare against.

The fix is to treat every generated screen as reproducible: store the specification that drew
it and the inputs that produced the specification. This is not a reporting nicety. It is the
difference between a system you can stand behind and one that produces an unrepeatable result
and discards it. Artists who worked with generative programs learned this long ago, and kept
the seed for every output. The same discipline applies here.

## What the evidence looks like today

Public evidence that generative UI improves outcomes is thin, and honesty about that is worth
more than a confident claim. Most reported results are from the vendors selling the tools, and
most are counts of activity rather than outcomes. The clearest public figures are usage, not
conversion or retention. Independent reporting through 2026 found teams shipping generative
interfaces who could not say whether they worked, because the usage data was not there to tell
them.

That gap is not a reason to avoid generative UI. It is a reason to instrument it from the
start. The teams that will be able to show a result are the ones who decided, before shipping,
what a surface is, what a component is, and what to record about the decision that produced
each screen.