Skip to main content
Every query you build in the Explorer is an AftersellQL (AQL) statement. Most of the time you build queries visually and never write AQL by hand; this page is the reference for the metrics and dimensions you can pick, the AQL text form, and the timezone rules.

Available metrics

These are the metrics you can pick, grouped the same way the metric picker groups them.

Revenue & profit

Conversions

Engagement

Store performance

Rokt network

Dimensions

Dimensions break a metric down by an attribute. Not all dimensions are compatible with every metric; the Explorer automatically prevents incompatible combinations (for example, Decline rate and Show rate cannot be broken down by Currency).

Available dimensions

Unavailable dimensions

The following are a work in progress. They appear in the picker but show as ‘Not compatible’ for every metric until implemented.

AQL statement syntax

An AQL statement is a single question made of clauses. Only SELECT and a time range (SINCE) are required; everything else is optional. When you include optional clauses, they must appear in this order:
A minimal example, daily upsell revenue and accept rate for the last 30 days:
Keywords are not case-sensitive (SELECT and select both work) and statements do not end with a semicolon. String values are wrapped in double quotes; numbers and lists are not.

SELECT and GROUP BY

  • SELECT lists the metrics to measure, separated by commas, for example SELECT revenue, impressions, accept_rate.
  • GROUP BY breaks those metrics down by one or more dimensions, such as date, device, surface, or funnel. Without GROUP BY, you get a single total for the whole period.

Filtering with WHERE

WHERE narrows the data before it is measured. Combine conditions with AND.
impressions, accept_rate, and rpv cannot be filtered or grouped by device, funnel, placement, or product; their source rollup has no such column. Adding WHERE device = "mobile" to a query selecting any of them is rejected with metric "impressions" cannot be filtered by "device".
Supported comparisons are =, !=, IN, NOT IN, >, <, >=, and <=. Use a list with IN to match several values:
experiment is not a filterable field; it has no rollup source, so WHERE experiment IN [...] is rejected with filters on "experiment" are not supported. The funnel filter supports multi-select: is one of (IN) includes only the selected funnels, is not one of (NOT IN) excludes them. When you group by Funnel and apply an is one of filter, the chart shows one line per selected funnel, with no “Other” collapsing.

Time ranges and comparisons

Every query needs a time range, set with SINCE: Available presets: last_1d, last_7d, last_30d, last_90d, this_month, last_month, and this_year.
  • GRAIN sets the bucket size for time series: day, week, or month. (hour parses but no rollup serves hourly data, so such a query is rejected with group_by / time_grain combination is not supported.)
  • COMPARE overlays a second period. Use previous_period, the equal-length window immediately before. previous_year is hidden from the Compare picker because the warehouse holds no data before February 2026; it remains typeable in AQL only so previously saved queries keep parsing.
Reporting data starts in February 2026, so a window earlier than that returns empty for both periods.

Choosing a chart

  • CHART sets how the result is displayed: scorecard, line_chart, bar_chart, area_chart, funnel_chart, or table.
  • TIMEZONE sets the timezone used to bucket dates, as a quoted IANA name, for example TIMEZONE "America/New_York". Defaults to UTC (see Timezones).
The funnel_chart type has specific requirements:
  • Placement mode. Group by placement and select one metric. Stages are ordered by the canonical placement sequence (upsell default, then downsell, then additional upsells). Only the first metric is plotted; additional metrics are noted in a footnote.
  • Metric mode. Select two or more metrics with no GROUP BY. Each metric becomes a funnel stage in query order (for example, SELECT impressions, conversions shows an impressions to conversions drop-off). All metrics must share the same unit.
Placement mode needs a metric that can be broken down by placement. impressions, accept_rate, and rpv cannot; the funnel chart shows “These metrics can’t be grouped by placement” for those.

Sorting and limiting

  • ORDER BY sorts results by a metric or dimension, with ASC or DESC.
  • LIMIT caps the number of rows returned, useful for “top N” questions.

More examples

impressions, accept_rate, and rpv can’t be broken down by device; their rollup is shop × surface × day, with no device column. Use revenue (or another conversion-sourced metric) for device comparisons.

Timezones

By default, queries run in UTC. You can override the timezone so that date-bucketed results reflect local time (see Setting a timezone for the toolbar steps).
Queries that include Impressions, Accept Rate, or Revenue Per Visit always bucket dates in UTC, regardless of the timezone you select, because they’re sourced from a daily rollup reported in UTC days. If a query mixes one of these with other metrics, the whole result set falls back to UTC so date buckets stay aligned.

The TIMEZONE clause

Specify a timezone directly in AQL with the TIMEZONE clause, which appears between CHART and ORDER BY:
When present, the clause overrides the toolbar selection for that query, and is preserved when you save and reload.

Available timezones

The picker (and the TIMEZONE clause) accepts a closed set of ten zones. Any other IANA timezone is rejected as unsupported.

Account default and how timezone affects results

If Lock reporting timezone is enabled in your analytics settings, selecting Account default uses that locked timezone (the toolbar shows the resolved zone, for example Timezone: Account default (Paris (CET))). The analytics settings page accepts the full IANA list, but Reports honours only the ten zones above; if your locked zone isn’t one of them, Account default silently resolves to UTC. If Lock reporting timezone is not enabled, Account default falls back to UTC. When a timezone is set, date-bucketing uses local time instead of UTC. For example, an event at 2026-03-29T01:30:00Z falls on March 28 in New York (ET) but March 29 in Paris (CET). Queries without a timezone, including previously saved ones, continue to run in UTC.