Features
Type country==SE;device_type==mobile once, and traffic, funnels, retention, revenue and customers all follow it. The filter lives in the URL like every other filter in the product, so a segmented view is a link and the back button undoes it.
A semicolon is AND, a comma is OR, and AND binds tighter. A pipe inside a value is a list.
| == | Equals |
| != | Does not equal |
| ~= | Contains |
| !~ | Does not contain |
| ^= | Starts with |
| $= | Ends with |
| =~ | Regular expression |
| > >= < <= | Greater than, at least, less than, at most, for numeric fields |
| field== | Field is empty |
| field!= | Field is present |
Fields are checked against a closed allowlist. A field not on it cannot be filtered on, because the alternative is user input reaching the analytics database unchecked.
Page and source
path, hostname, event_name, channel, referrer_host, utm_source, utm_medium, utm_campaign
Audience
country, region, city, device_type, browser, os, language, screen_bucket
Identity and delivery
consent, user_id, account_id, sdk_version, browser_major
Numeric
duration_ms, scroll_depth, revenue_cents
Custom properties too: prefix a string property with properties. and a numeric one with num., for example properties.plan==pro or num.seats>=5. The two are kept apart because a numeric comparison on a string field is a silent wrong answer.
project_id and visitor_id are deliberately absent from the allowlist. A filterable project id is a cross-tenant read with extra steps. Filtering by a specific visitor turns an analytics tool into a surveillance tool, so it is not an option, not a permission you can be granted.
So a pasted filter cannot become an expensive query by accident.
IN list.Every value is a bound parameter.
Nothing typed into the filter bar is ever concatenated into SQL, including a property key, which is bound for a map lookup rather than interpolated. A segment is user input that reaches the analytics database directly, and that is the one path where careless handling becomes a cross-tenant read.
A filter that fails to parse says so.
You see the parse error in place, and the page falls back to unsegmented data rather than quietly showing wrong numbers under a heading that claims otherwise.
Segmented views read raw events, not rollups.
A rollup cannot answer a question about an arbitrary property, so a segmented report scans raw events instead of the pre-aggregated tables the unsegmented view uses. The product says which store answered rather than leaving you to wonder why one view is slower on a wide date range.
Included on every plan.
Segmentation is not held back for a higher tier. It is on Free the same as everywhere else.
Full operator reference and worked examples on the segments doc.