Design a report block

A report block is one query inside a Report setup. This page explains the query editor in the same order as the UI, so you can move from top to bottom while designing a block.

Content of this page

If you are new to the concepts, start with Report setups, queries, and report blocks.

Report block

The Report block section identifies the block inside the generated report.

  • Title appears as the block title.
  • Description helps readers understand what the block is meant to show.
  • Query type decides which kind of data model the block uses.
  • Temporarily disable this query keeps the query in the setup without generating it.

Use a title that describes the question answered by the block, such as “Campaign performance by campaign” or “Top content by signups”.

[screenshot: Query editor Report block section]

Measure

The Measure section defines which tracked events should become metrics in the report block.

Use Browse to select event types. Selected events appear as an ordered list. This order is important:

  • It controls the order of metric columns in the generated report.
  • When sorting by metrics, earlier events have higher sort priority.

For example, if the selected events are page view, signup, and purchase, the generated block will use that metric order.

Tip: put the most important event first.

Include only

The Include only section restricts which data is allowed into the report block. It answers the question: Which part of my data should this block use?

Examples:

  • Include only selected content types.
  • Include only selected content structure paths.
  • Include only selected referrer source types or names.
  • Include only selected campaigns, campaign mediums, or campaign contents.
  • Include only selected devices, visitor types, languages, or tags.

Most Include only fields use Browse. Browse helps you select known values and avoid typos. Selected values appear as removable chips or rows.

If an Include only field is empty, it usually means “do not restrict by this field”.

Additional filters

Additional filters are still Include only filters, but they are less common. They include device type, visitor type, language, primary tags, and secondary tags.

The Additional filters section is collapsible. If filters are already active, the editor indicates that.

For a full filtering guide, see Narrow report data with Browse and filters.

Break down by

The Break down by section decides how report rows are grouped. It answers the question: How should the result be split into rows?

Examples:

  • Break down by time interval to see change over time.
  • Break down by content to compare pages or tiles.
  • Break down by content structure to compare site areas.
  • Break down by source type or source name for referrer analysis.
  • Break down by campaign, campaign medium, or campaign content for campaign analysis.
  • Break down by device type, visitor type, or language for audience analysis.

Breakdowns are different from filters. Filters decide what data is included. Breakdowns decide how included data is grouped.

Example: filter vs breakdown

If you include only mobile devices, the report block uses only mobile data. If you break down by device type, the report block creates separate rows for device types.

You can combine both, but be careful: very strict filters plus many breakdowns can create sparse or empty results.

Time Resolution

When you break down by time interval, the editor can use automatic Resolution or a custom period. Automatic Resolution lets Keytiles choose a suitable time period based on the report range. Custom Resolution is useful when you need a fixed period such as hours, days, or weeks.

Rows and ordering

Rows and ordering controls help keep the generated block readable.

  • Limit rows keeps only a certain number of rows when the selected breakdowns support limiting.
  • Sort by metric values orders rows by measured event values.
  • Sort by breakdown columns orders rows by the selected breakdown values.
  • Breakdown order controls how breakdown axes participate in sorting.

For most reports, start by sorting by the metric that matters most. Then add a row limit if the block becomes too long.

A practical design checklist

  1. What question should this block answer?
  2. Which event or events measure that question?
  3. Should the block include all data, or only a subset?
  4. How should the result be broken into rows?
  5. Which rows should appear first?
  6. Does the block still answer the question when you generate the report?