Data Query

A data query is the saved configuration behind what analytics data is fetched, how it's broken down and filtered, the date range, comparison, and ordering.

Find it: open any chart or table card in the editor and use the Data tab. The preview pane beside it has three tabs — Card Preview, Data Preview, and Data Query — the last of which shows the raw request.

Key terms

• Metric — A number being measured — spend, clicks, sessions.
• Dimension — A category the metric is broken down by — campaign, device, date.
• Granularity — The size of the time bucket on a time-series chart — Day, Week, Month, Quarter, Year. Controls how many points appear on the x-axis, independent of the total date range.
• Filter — A condition that limits which rows are included, e.g. Country equals Australia.
• Comparison — An overlay of the same query against a prior period, for direct before/after reading.
• Sort — The field and direction results are ordered by.
• Card — One chart or table on a report.
• Page — A tab within a report, holding multiple cards.
• Report — The overall document — one or more pages.
• Source — A connected platform (Google Ads, Meta, etc.) a card pulls from.

The six things a data query decides

Which platforms isn’t a seventh setting — it’s derived. Each field you pick carries its own source (googleAds.spend is Google Ads, facebookAds.spend is Meta), so the card’s sources are simply the set of platforms its fields belong to.

‍

Example query

{
  "total": true,
  "measures": [
    "googleAds.spend"
  ],
  "measureAggregations": {
    "googleAds.spend": "sum"
  },
  "dimensions": [
    "googleAds.campaignName"
  ],
  "timeDimensions": [
    {
      "dimension": "googleAds.date",
      "granularity": "day",
      "dateRange": [
        "last30days"
      ]
    }
  ],
  "filters": [
    {
      "member": "googleAds.campaignName",
      "operator": "contains",
      "values": [
        "Brand"
      ]
    }
  ],
  "order": {
    "googleAds.spend": "desc"
  }
}

‍

How a query actually turns into a chart

The Data tab doesn’t store numbers — it stores the description of what you want. Every time the card needs to render (first load, date range change, filter change), Jepto reads that description, sends it off to the relevant connected platforms (or a fast cache of recent results), and streams the answer back into the card. That’s why:

• Changing a filter or date range doesn’t “recalculate” a stored table — it triggers a brand-new request under the hood, which is why cards briefly show a loading state after any Data tab change.
• Two cards with an identical data query always show identical numbers, because they’re asking the exact same question. If two cards disagree, the query itself is different somewhere — that’s the first thing to check (see Troubleshooting).
• The Data Query preview tab shows you exactly what’s being asked, in the same shape sent to the underlying query system — useful for spotting a stray filter or wrong field without guessing.

‍

Building blocks

Metrics — numeric fields from the Data Model, each with an aggregation (Sum, Average, Minimum, Maximum, Count, Count distinct) controlling how rows roll up. On tables you can drag metric rows to reorder the columns.

Dimensions — the categories on your axes or table columns. Time-series charts (line, area) use a time dimension plus a granularity; bar/column charts use a regular dimension for the category axis, with an optional breakdown dimension for stacking.

Time — the date field, range, and granularity. Independent of which dimension you’re breaking down by — you can chart “spend by campaign” with no time dimension at all, or “spend by day” with a time dimension and no other breakdown.

Filters — always-on conditions that narrow rows before anything renders, e.g. Campaign name contains “Brand”. They live in the card’s filter panel, opened from the editor toolbar rather than from the Data tab itself.

Comparison — overlays the same query against the previous period or previous year, computed by shifting the same date range backward and running the identical query a second time.

Sort — Sort By picks the field, Order picks ascending or descending.

‍

Date range and granularity

Use Default Date Range

• On (recommended) — the card follows whatever date range is set on the page or report, and the card’s own Date Range control is disabled.
• Off — the card keeps its own fixed window, independent of the page picker.

Granularity — Day, Week, Month, Quarter, or Year. This is the size of each bucket on a time-series chart, not the total range. A 90-day range at Day granularity draws ~90 points; the same range at Week granularity draws ~13 points, each one summed across that week.

Date range expressions — a date range is a start and an end. Each end can be a fixed ISO date (2024-01-01) or a relative expression that re-resolves every time the card loads:

• Single days — today, yesterday
• Period-to-date — thisWeek, thisMonth, thisYear
• Completed periods — lastWeek, lastMonth, lastYear
• Rolling windows — last7days, last30days, last90days (any lastNdays works)
• Offsets — 7DaysAgo, 4WeeksAgo, 3MonthsAgo, 2QuartersAgo, 1YearAgo

Because relative expressions re-resolve on every load, “last 30 days” always means the 30 days ending today — that’s the mechanism behind Use Default Date Range staying current without anyone touching the card.

Tip: Leave Use Default Date Range on for most cards on a report. It keeps every card in sync when someone changes the date picker, and it’s usually the reason a chart looks “stuck” on the wrong dates when it’s off.

‍

Filters stack in three layers

Filters don’t live in one place — they compound from three sources, and every card’s final result is the intersection of all three that apply to it:

• Card filters (Layer 1) — built directly in the card’s filter panel, or linked from the saved Filters library. These always apply, no matter what the viewer does, and are meant to be permanent definitions (e.g. “this card only ever shows Brand campaigns”).
• Page filters (Layer 2) — interactive filter cards on the report itself: a date range filter, or dropdown filters for dimension values. A viewer can change these while looking at the report. Each one targets a specific set of cards.
• Report defaults (Layer 3) — the page’s default date range, but only for cards with Use Default Date Range on.

Worked example: a table card has a card filter Country = US (Layer 1, permanent). The page has a date range filter set to Last 30 days and a dropdown filter for Device that a viewer sets to Mobile (Layer 2). The card has Use Default Date Range on, so it also inherits the page’s date range (Layer 3). The table ends up showing: US rows, mobile only, last 30 days — the AND of everything above.

If a card “won’t listen” to a page filter, it’s almost always Layer 2 — check that the filter targets this card, that the filter’s field exists on that card’s sources, and that you haven’t left every option selected (a dropdown with everything selected is treated as no filter at all and is dropped from the query).

‍

Comparison and sort

Comparison — on the Data tab, turn on Comparison and choose Previous period or Previous year to show a direct overlay. Under the hood this runs the same query twice: once for the current range, once for the same-length range immediately before it (or twelve months back, for year-over-year).

Sort — set Sort By to a field and pick an Order. On tables, combine it with Rows per page on the Table tab for a clean “top N” view.

‍

Multi-source and unified fields

A card can pull from more than one connected platform. When it does:

• Prefer unified fields (unified.spend, unified.clicks) over platform-specific ones when comparing across sources — they map to the right equivalent per platform automatically. See Data Model.
• Check the unified field actually maps to every platform on the card. Spend, clicks and impressions cover nearly everything; conversions, conversion value and ROAS don’t map to Meta. An unmapped source contributes nothing and looks like a zero.
• Keep filters on fields that exist across all the sources in play.
• Avoid using a metric that only exists on one platform as the basis for a cross-platform breakdown — it’ll silently zero out the rest, since there’s nothing on the other platforms to sum.
• Add the Data source dimension (unified.source) when you want to see which platform each row came from.

‍

Letting AI draft the query

AI Edit and report-level AI can build a data query from a plain-language prompt. The more specific the prompt, the better the result:

“Line chart of spend and clicks by day, last 30 days, Google Ads and Meta only”

beats

“show me spend”

AI uses exact Data Model field names, sets aggregation, picks compatible sources, and defaults to a relative date range unless you ask for fixed dates. Always check the Data tab afterward — it’s the source of truth, and AI drafts are a starting point, not a guarantee.

‍

The mental model, end to end

1. Pick metrics and dimensions from the Data Model.
2. Lock in filters, sort, comparison, and granularity on the card.
3. If Use Default Date Range is on, the report’s date picker controls the window; if off, the card keeps its own dates.
4. On the live report, page-level date range and dropdown filters can narrow things further.
5. Every time any of the above changes, Jepto re-runs the underlying request and streams a fresh answer into the card — nothing is precomputed and left stale.
6. AI Edit can draft steps 1–2 from a sentence — the Data tab is still what actually gets saved.

‍

Tips for better cards

• Start from the question you’re answering (“Spend by campaign, last 30 days”), not the chart type.
• One job per card — don’t stack five unrelated metrics onto one chart.
• Leave Use Default Date Range on unless a card genuinely needs a fixed window (e.g. a launch-period comparison).
• Use card filters for permanent definitions (“this is our Brand campaign set”); use page filters for exploration.
• If the same math shows up on multiple cards, make it a custom field once instead of rebuilding it per card.
• When a chart looks wrong, check the Data Preview tab before assuming the platform data is wrong — it shows the rows behind the visual.

‍

Troubleshooting