Showing the Exact Query

Most testing tools ask you to trust a number. A vs B shows you the query that produced it.

On any Results page, click Show the exact queries in the action bar at the top, alongside Export CSV. You get every ClickHouse query that ran to build the page you are looking at: the real SQL, the real parameters, grouped by which number on screen each one feeds.

Each query is grouped under a plain-English headline naming the number it feeds, with Copy SQL next to its SQL text, and a parameters table underneath showing the exact values bound to that query.

One query in the panel: the headline it feeds, its SQL, and the parameters bound to it.
  1. Copy SQL puts that one query on your clipboard, exactly as it ran.
  2. The parameters table lists the values sent alongside the SQL, which is why the query text shows placeholders rather than literals.

Why this exists

If a result surprises you, "the platform says so" is not an answer. Being able to read the query is the difference between trusting a number and being able to check one. It means you can:

  • Verify the maths yourself: read exactly how visitors, conversions, and revenue are counted.
  • Reproduce a number in your own warehouse, if you have a copy of the same event data.
  • Explain a result to someone else: a colleague, an analyst, or a sceptical stakeholder.
  • Spot a definition mismatch: for example an attribution window or a metric filter that is not what you assumed.

What you see

Each query in the list shows:

FieldWhat it is
HeadlineThe number on the page this query feeds, in plain English: "Visitors per variation", "Revenue per visitor".
SQLThe query text exactly as it was executed.
ParametersThe values bound to that query: project id, experiment id, date range, segment filters.

Use Copy SQL on any single query, or Download .sql to get the whole set as one file with each query labelled and its parameters recorded above it.

It matches what you are looking at

The export respects the filters currently applied to the page. If you have a date range set, a segment filter on, or you are exploring under a different stats engine, the exported queries are the queries for that view, not for some default.

Change a filter, reopen the panel, and you get the queries for the new view.

This is captured, not reconstructed

The SQL you see is not a hand-written approximation of what we think runs. It is recorded as the query executes, by the same database client that runs it. What you export is byte-for-byte what ClickHouse received.

That distinction matters: a hand-maintained "example query" in a docs page drifts away from the real thing the moment someone changes the code. This cannot drift: if the query changes, the export changes with it, automatically.

Info

Every query that runs is listed, including ones we have not given a friendly name yet; those appear under Supporting data. The only exception is the connectivity check (SELECT 1), which reads no data and exists purely to confirm the database is reachable. Nothing that produces a number is ever hidden from this list.

About the parameters

You will notice the SQL contains placeholders like {projectId:String} rather than literal values, with the actual values listed separately in the parameters table.

That is not a redaction: it is how the query genuinely runs. Values are sent to ClickHouse as bound parameters, never pasted into the SQL text. This is what makes the query safe from injection: a segment value containing SQL syntax is treated as data, never as code. The export shows you the two halves exactly as the database receives them.

Who can see it

Anyone with permission to view reports for the experiment. The panel is read-only: it shows queries, it never re-runs them, and there is no way to edit or execute SQL from it.

You only ever see queries for experiments in your own organization.

Was this helpful?