How to measure generative UI

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 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.