MCP Analytics Query Tool

The query_replo_analytics tool lets you run read-only ClickHouse SQL queries against this project's Replo analytics data. Pass a query string containing a SELECT statement (or a WITH CTE that resolves to a SELECT).

Resolve metric meaning before choosing SQL

A familiar metric name is not a complete definition. Use the request, prior conversation, existing report definitions and available data to determine what the number should represent. Before choosing columns, check the choices that could materially change the result:

• What is counted: events, sessions, distinct people, orders or another entity; which event or condition qualifies; which identity supports deduplication.
• Who is included: the population, domains/pages, exclusions, and whether filters select matching events or sessions/entities that touched the selection.
• How it is calculated: numerator and denominator for rates/averages, grouping and time buckets, whether groups overlap, and whether a total can be summed or must be recomputed.
• When and from where: reporting/comparison dates, timezone, event date versus cohort date, source and freshness, and units or currency where relevant.

Treat these as reasoning checks, not a questionnaire. If two plausible interpretations would materially change the answer and context does not resolve them, ask a concise question in business language and explain the difference. Ask 1–3 short questions at a time, each resolving one main choice; do not hide a long questionnaire in compound questions. Prioritize choices that change the business conclusion. Reuse established reporting defaults for incidental settings and state them instead of asking about every possible option. Continue independent data discovery while waiting, but do not silently choose an unresolved definition. If the request is clear, use it; if the user delegates choices, state a suitable default and proceed. Never promise a definition the available tracking cannot support.

Examples of ambiguity include "traffic" (pageviews, sessions or identifiable visitors), "conversion rate" (sessions with at least one purchase / sessions versus purchase events / sessions), and "average engagement" (which event or duration, averaged over which population). Revenue attribution is another instance of the same problem; follow the reference below for its specific rules. Do not introduce ambiguity the user has already resolved: "daily distinct sessions for the last 30 UTC days on this domain" needs no metric-definition question.

Confirm source field paths, types and units against the schema or representative events before relying on them. Keep the chosen definition consistent across SQL, labels, filters and totals. Name the counted entity or ratio clearly; disclose material scope, window, overlap and data limitations alongside the result. Validate using the same population and definition: deduplicate distinct counts across overlapping groups, recompute overall rates from the underlying population rather than averaging row percentages or summing overlapping groups, and distinguish missing data from a measured zero.