Analytics Filters

Filters narrow every report in TinyAnalytics to a subset of your traffic — one country, one page, one campaign, or any combination. A filter applies across the whole dashboard at once and stays active as you move between reports, so you can ask a focused question and get a consistent answer everywhere.

​

How do I apply a filter?

• Click a row. In a breakdown, the map, or the Performance table, click a value — a referrer, a country — to filter the dashboard by it. Click again to remove it. This is the fastest way to drill in.
• Click a page. In the Pages and Landing pages tables, a row click instead opens the main dashboard already filtered to that page, carrying your date range and other active filters with it. There’s no click-again-to-clear on these two tables — remove the filter on the dashboard, or use your browser’s Back button.
• Add a filter manually. Use the filter control to build a filter from a dimension, an operator, and one or more values.
• Describe a filter. On a supported top-level report, open Add filter, enter a request such as “Visitors from Türkiye using Chrome” under Describe your filter, and submit it. Ask AI converts the request into the same typed filters and applies them to the open report.

​

How do natural-language filters work?

Describe your filter starts one ordinary Ask AI turn. The assistant receives the current report, date range, timezone, and complete active filter list, then returns a validated replacement list. The resulting chips use the existing URL-synced dashboard state, so you can inspect, remove, reload, and share them exactly like manual filters. This action changes only your browser view, not a saved segment or server configuration, so it does not show an approval card. It uses one plan AI credit or your personal Anthropic key. If you leave the site or report before the result arrives, TinyAnalytics ignores the stale result. The field appears only on top-level reports that use the shared filter controls. Saved-segment editors remain manual because they edit a separate draft rather than the open report.

​

What is a filter made of?

A filter has three parts: a dimension (what to filter on), an operator (how to compare), and one or more values. Common dimensions include page path, page title, hostname, referrer, channel, country, region, city, browser, operating system, device type, screen size, UTM parameters, event name, and tag. Four dimensions are session-scoped rather than pageview-scoped: Entry Page and Entry Hostname match the first page of a session (“entered on”), and Exit Page and Exit Hostname match its last (“ended on”) — neither means “visited anywhere”. Use them to isolate the sessions that started or ended somewhere, and page path or hostname to catch every session that reached a page at any point. Note that an exit filter changes which sessions you see, not how often a page was viewed — the Exit pages report’s exit rate is computed the same way. User trait sits in the People group of the filter control, beside User ID. It filters reports by the traits you attached with identify() — “plan is pro”, “country is not set”. It is different from every other dimension in four ways:

• Identified users only. A trait filter matches people your app has named — never anonymous traffic. Excluding works the same way: “plan is not pro” matches identified users whose plan isn’t pro, including identified users with no plan key at all, but still no anonymous visitors. An active trait filter shows a banner stating the identified population it’s filtering.
• Current value, not historical. The filter reads the value the profile holds at query time, not the value during the reported period. A Q1 report filtered to “plan is pro” includes January activity of users who upgraded in March, and drops users who have since churned. For funnels this is a survivorship caveat — the cohort is defined by who matches today. To pin a value to the moment it happened, send it as an event property instead, which filters per-period.
• No regex, with caps. Trait filters support is / is not, contains / does not contain, starts with / ends with, and is set / is not set — the regex operators are not available. You can apply at most 4 trait filters per query, a key is at most 200 characters, and a single filter matching more than 10,000 identified users is refused with a TRAIT_FILTER_TOO_BROAD error. To recover from that error, compose presence with exclusion — “plan is set” AND “plan is not free” — which narrows below the cap without changing the population the way a bare exclusion would.
• Members only. Trait data can hold names and emails, so trait filters require a signed-in member or an API key with Users: Read. On public dashboards, share links, and embeds the picker is hidden and a request carrying a trait filter returns 400 rather than silently unfiltered results. Saved definitions — segments, cohorts, and alerts — reject trait filters with a named error; trait filtering is for the live report in front of you.

The same vocabulary appears under four names depending on where you look: The Traits explorer in the Users report links straight into this: a key or value row’s View filtered dashboard action opens the overview with the matching trait chip applied, and the explorer header shows how many identified profiles the site holds. The operators are:

​

How do I combine filters?

• Several values on one filter are combined with OR — country is US or GB matches visitors from either.
• Several filters are combined with AND — country is US plus page is /pricing matches US visitors who saw the pricing page.

​

Filters follow you across reports

An active filter stays applied as you switch between Overview, Pages, Sessions, and the rest. Set up a view once — say, mobile visitors from a campaign — and every report reflects it until you clear it. Filtering the Sessions list keeps whole sessions rather than trimming them to matching events, so “sessions that reached this page” answers correctly. See Sessions.

​

Frequently asked questions

​

Related