What Is Trace Analysis? A PM Guide to AI Observability

A trace is the complete, structured record of a single AI interaction, from the moment a user submits a request to the moment the system returns a response, including every step in between.

A typical trace contains:

• User input and detected intent. What the user asked and how the system classified the request.
• The model's response. The full output the system returned to the user.
• Tool calls and results. Each external API or function the agent called and what each returned.
• Retrieved context. Documents pulled from a knowledge base or prior conversation history included in the prompt.
• Latency and cost. How long each step took and what it cost to run.
• User feedback signals. A thumbs-up, a follow-up question, or an abandonment after the response.

If you've ever reviewed a session recording in Amplitude Session Replay and watched exactly what a user did on a page, a trace gives you the equivalent view into an AI conversation. Where session replay shows you a user clicking through a checkout flow, a trace shows you the model reasoning through a data query.

The key difference from a standard event: an event is flat. It records that something happened. A trace is nested. It records how the system arrived at a result, step by step.

Trace analysis means inspecting individual traces and patterns across many traces to understand AI behavior and identify what to fix.

There are two modes, and both matter.

Single-trace inspection

Single-trace inspection is the unit of debugging. A PM or engineer opens one trace and reads through it to understand a specific failure, the same way you'd review a session recording to understand why a user abandoned a checkout. If a customer files a support ticket saying your AI assistant gave them wrong information, single-trace inspection is how you find out what actually happened inside that conversation.

Aggregate trace analysis

Aggregate trace analysis looks for patterns across many traces. Which intents fail most often? Where do tool calls error out? Which query types cost the most to run? Which session shapes correlate with users coming back the next day? Aggregate analysis is how trace data feeds into product decisions rather than just bug fixes.

A concrete example

A user asks your AI feature to summarize their Q3 performance data. The model calls a data retrieval tool. The tool returns null because the user's data hasn't synced yet. The model, lacking context for why the tool returned nothing, generates a plausible-sounding summary with invented numbers. Without trace analysis, you see only that the user left the session quickly and gave a low rating. With trace analysis, you see the exact tool call, the null return, and the hallucinated output. The fix is clear: handle null returns from the data tool before passing results to the model.

Trace analysis and AI evaluations work together: trace analysis surfaces failures in production, and evals track whether your fixes hold.

An AI evaluation is a repeatable test that measures whether an AI system produces output meeting defined quality criteria for a given input. Evals are analogous to unit tests for deterministic software, except the outputs vary and correctness is sometimes subjective.

Without trace analysis, teams write evals based on assumptions about how the product will be used. You cover the failure modes you anticipated. Trace analysis replaces assumptions with evidence. When you find a real production failure in a trace, you turn it into an eval case. Now you have a test that catches that specific failure mode every time the system changes.

The loop looks like this: run the AI feature in production, collect traces, inspect traces to identify failure modes, write eval cases from those failures, run evals as you make changes, and update the evals when new failure modes appear in new traces. Teams that skip trace analysis tend to write evals that pass easily because they never saw the hard cases. Teams that invest in trace analysis build eval suites that catch the failures that actually hurt users.

The trace analysis tooling space divides into two layers: tools that capture and inspect traces at the infrastructure level, and tools that connect trace outcomes to product behavior.

Infrastructure and observability tools

Infrastructure and observability tools handle trace capture, storage, and engineering-level inspection. Datadog LLM Observability, Langfuse, and Arize Phoenix sit in this category. These tools are built primarily for ML engineers and engineering teams who need to monitor model performance, token usage, and latency at scale. They're effective at surfacing technical failures: tool call errors, latency spikes, cost anomalies.

AI analytics platforms

AI analytics platforms connect trace outcomes to user behavior. This is where Amplitude AI Agents fits. Amplitude Agent Analytics ingests AI interaction data and treats each trace as a product event in the same event stream as your funnels, retention cohorts, and user segments. That means you can answer questions that infrastructure tools can't: did users who had a successful AI interaction retain at a higher rate than users who had a failed one? Which user segments are hitting the most tool call failures? Is the cohort that uses your AI feature three or more times in the first week converting to paid at a higher rate?

Most production AI teams end up using both layers. Infrastructure tools gate releases and catch technical regressions. An AI analytics platform connects AI quality to business outcomes.

Trace analysis gives product teams visibility into the one part of an AI feature that standard dashboards can't see.

Your existing analytics setup captures what users do before and after an AI interaction: the funnel steps, the session length, the retention curves. It doesn't capture what the AI did during the interaction. Trace analysis fills that gap.

Three practical reasons it belongs in a PM's toolkit:

• It's the only way to understand why users leave AI features, not just that they leave. Drop-off on an AI feature looks identical in standard analytics whether users left because the response was wrong, because it was slow, or because the feature didn't understand their question. Traces distinguish between those failure modes.
• It surfaces failures that satisfaction scores miss. A user who gets a confident, wrong answer may not report it as a failure. They leave satisfied in the moment and churn later. Trace analysis catches factual errors, tool call failures, and context retrieval problems that never appear in ratings or thumbs-up data.
• It creates the raw material for evals. You can't build a useful eval suite from a whiteboard. The most valuable eval cases come from real production traces where the system failed in ways your team didn't anticipate. Trace analysis is how you find those cases.

If you're shipping AI features and measuring them only through downstream engagement metrics, you're operating with half the picture. Trace analysis is the other half.

Amplitude connects trace data to product metrics in the same event stream where you already track retention, conversion, and feature adoption. If you're building AI features and want to move from guessing why they fail to knowing, try Amplitude for free.