AI Product Analytics: Query Your Event Data in Plain Language

For a decade, AI product analytics meant a chatbot bolted onto a dashboard that answered "show me signups" and gave up on anything harder. 2026 is the year that changed. In February, Amplitude opened an MCP server to all customers so Claude, Cursor and any MCP client can query its behavioral data, together with agents that watch dashboards and session replays. PostHog's MCP server exposes funnel, retention, paths and raw SQL tools to coding agents. And in October, Mixpanel announced Agent Intelligence, which goes the other way and measures whether your own AI agents actually help users.

The pattern is the same everywhere: analytics is moving from dashboards you read to questions you ask. This guide explains how that works, compares the options, walks through a do-it-yourself setup on raw events, and lists the habits that keep the answers honest. It builds on our earlier experiment, making analytics with Cursor and CSV files.

How AI product analytics works

Every setup, whatever the vendor, has the same four steps:

1. Question. You ask, "Why did activation drop last week?"
2. Context. The agent looks up which events, properties and metrics exist, through a schema tool (PostHog calls it read-data-schema) or a file you wrote.
3. Query. It calls a structured tool (a funnel, a retention query, a trend) or writes SQL, and runs it.
4. Explanation. It reads the result, often runs a follow-up query (split by country, plan or app version) and writes a summary.

The Model Context Protocol (MCP) is what made this practical. It is a standard way for an AI client to discover and call tools on a server, so one analytics vendor can support Claude, Cursor, VS Code and JetBrains IDEs at once. If you have not used MCP before, our LogNroll MCP server guide shows a working example end to end.

Four ways to set it up

1. Your analytics vendor's MCP server

The fastest route if your events already live in a product analytics tool. PostHog, for example, installs its server with one command (npx @posthog/wizard mcp add) and gives the agent tools such as query-funnel, query-retention, query-paths and execute-sql, plus tools to save the result as an insight or add it to a dashboard. Amplitude's server works with Claude, Cursor and other MCP clients and answers questions like "which features drove retention this month" from live data. The limit is obvious: the agent only sees what the vendor stores.

2. The agent inside the analytics tool

Amplitude's AI Agents and Mixpanel's expanded Mixpanel Agent run inside the product: they monitor KPIs, flag changes and run root-cause analysis without anyone opening a terminal. Good for product managers; less good when you need to see exactly which query produced a number.

3. Text-to-SQL on your own events

If you export events (or never bought an analytics tool), a coding agent plus DuckDB is a surprisingly complete analytics stack. You control the definitions, you can join product events with billing or CRM data, and nothing leaves your machine unless you choose a cloud model. The next section shows how.

4. An agent over raw session data

Aggregates tell you that step two of the funnel lost 40% of users. They rarely tell you why. Session-level data (errors, failed network requests, rage clicks, what was on screen) does. This is where session replay and an agent make a strong pair, and it is the gap LogNroll's MCP server fills.

Hands-on: ask your event data questions with DuckDB and a coding agent

You need three things: events as Parquet or CSV files (one row per event with event_time, user_id, event_name and a properties column), DuckDB, and a coding agent such as Claude Code, Cursor or OpenCode. If you are choosing one, see our OpenCode vs Claude Code vs Cursor comparison.

Step 1: write down what your events mean. This is the most important file in the project. Agents are good at SQL and bad at guessing that project_created fires for every project, not just the first one:

# analytics/metrics.yaml - the agent reads this before writing any query
timezone: UTC
events:
  signed_up:        fired once, server-side, when the account is created
  project_created:  fired for every project; the first one has is_first = true
  replay_viewed:    player stayed open for at least 3 seconds
exclude:
  - users whose email ends with @yourcompany.com   # internal accounts
  - projects where is_test = true
metrics:
  activation_rate:
    definition: share of signups with replay_viewed within 7 days of signed_up
    owner: product
    dashboard: https://analytics.example.com/d/activation   # the number to match

Step 2: ask a specific question and set the rules. A good prompt asks for the query, the numbers and the sample size:

Read analytics/metrics.yaml first.
Using DuckDB on events/*.parquet, build the activation funnel
(signed_up -> project_created -> replay_viewed, 7-day window) for the
last 30 days. Exclude internal and test users as described.
Show me the SQL before you run it, then the counts per step,
the conversion between steps, and how many users each number is based on.
If a step has fewer than 100 users, say so instead of drawing conclusions.

Step 3: review the query. A typical answer looks like this. Read it the way you would review a pull request: is the time window right, are steps ordered, are first occurrences used?

-- Signup -> first project -> first replay viewed, within 7 days,
-- for users active in the last 30 days.
WITH firsts AS (
  SELECT user_id,
         min(event_time) FILTER (WHERE event_name = 'signed_up')       AS t_signup,
         min(event_time) FILTER (WHERE event_name = 'project_created') AS t_project,
         min(event_time) FILTER (WHERE event_name = 'replay_viewed')   AS t_replay
  FROM read_parquet('events/*.parquet')
  WHERE event_time >= now() - INTERVAL 30 DAY
  GROUP BY user_id
)
SELECT
  count(*) FILTER (WHERE t_signup IS NOT NULL) AS signed_up,
  count(*) FILTER (WHERE t_project BETWEEN t_signup AND t_signup + INTERVAL 7 DAY) AS created_project,
  count(*) FILTER (WHERE t_replay  BETWEEN t_project AND t_signup + INTERVAL 7 DAY) AS viewed_replay
FROM firsts;

Notice the details that matter: min() takes each user's first event, the 7-day window is measured from signup, and a replay viewed before the first project does not count. These are exactly the decisions an agent makes silently if you do not ask to see the SQL. (The query is shortened for the example; in practice, also apply the exclusions from metrics.yaml.)

Step 4: ask the follow-up. This is where agents beat dashboards. "Split the drop between step 1 and 2 by signup source and browser." "Compare users who saw the new onboarding with those who did not." Each follow-up is a new query you would otherwise have filed as a ticket for the data team.

Keeping the numbers honest

The real risk of AI data analysis is not a crash. It is a well-written paragraph built on a wrong join. These habits prevent most of it:

• Definitions in writing. A metrics file, a semantic layer or saved insights in your vendor tool. If two people define "active user" differently, the agent will pick a third.
• Show the work. Always ask for the query or tool call. Vendor MCP tools that return a saved insight are easier to audit than free-form SQL.
• Calibrate once. Ask for a number you already know from a dashboard. If it does not match, fix the definitions before asking anything new.
• Sample sizes and time zones. Make the agent report how many users each figure is based on, and state the time zone. Most "sudden drops" are a partial day or a UTC boundary.
• Read-only access. Analytics agents never need write access to production data. Give them a read-only role or a copy.
• Personal data. Exclude emails, names and free-text properties from what the agent can read, or pseudonymise them. If the data is sensitive, a local model keeps it in-house; see local LLMs for private debugging.
• Cost. Large result sets eat tokens. Ask for aggregates, not raw rows, and cap result sizes in your tools. Our tips on reducing Cursor token spending apply here too.

From "what" to "why": add session data

Say the agent finds that activation fell from 31% to 24% and the drop is concentrated in Safari. A dashboard stops there. With session data connected as a second MCP server, the same conversation continues:

// .cursor/mcp.json - session data next to your analytics
{
  "mcpServers": {
    "lognroll": { "url": "https://mcp.lognroll.com/mcp" }
  }
}

• "List Safari sessions from last week that reached the project form but never created a project. Which errors and failed requests do they share?"
• "Summarise the three most typical sessions and give me the IDs so I can replay them."
• "Did these sessions have rage clicks on the Create button?"

LogNroll's MCP server exposes read-only tools such as list_sessions, search_sessions, get_session_errors and get_session_network, scoped to your team. The agent narrows thousands of sessions down to the handful worth watching, and you replay those. It is the same idea as turning rage clicks into roadmap items, with the search done for you.

The other direction: analytics for your AI features

Mixpanel's Agent Intelligence points at a second trend: if your product has an AI assistant, you need to measure it like any other feature. Did the user finish the task after the agent answered? How much did that conversation cost? Track agent turns, tool calls, errors and the outcome as regular events tied to the same user ID, and you can put them in the same funnels and retention reports. Session replay helps here too: watching what a user did right after an unhelpful answer is more instructive than any satisfaction score.

Checklist before you rely on agent answers

• Event and metric definitions are written down where the agent can read them.
• The agent has read-only access, scoped to the right projects.
• Personal data is excluded or pseudonymised; you know where the model runs.
• One answer has been checked against a known dashboard number.
• Every answer includes its query, time window, time zone and sample size.
• Session data is connected for the "why" questions.

For the bigger picture of where this is heading, read how AI is changing product analytics in 2026 and product analytics without a dashboard graveyard.

Where LogNroll fits

LogNroll records sessions together with console errors, network calls and click heatmaps, and its MCP server lets Claude, Cursor and other agents query that data directly. Use your analytics tool for the numbers and LogNroll for the sessions behind them. See pricing or start with the free plan.

Frequently asked questions