Filters
Add a WHERE clause in the usual way. Every query must hold a project_id filter.
PickedQL reads that filter and checks that you have permission for the project.
PickedQL rejects a query with no project_id filter.
-- A range of dates.
SELECT control_users() FROM metrics
WHERE project_id = 'your-project-id'
AND project_local_date BETWEEN '2026-03-01' AND '2026-03-31'
-- By experience.
SELECT step_enter_users() FROM events
WHERE project_id = 'your-project-id'
AND experience_id = 'my-experience'
GROUP BY step_id
-- Combined filters
SELECT control_users(), variant_users() FROM metrics
WHERE project_id = 'your-project-id'
AND project_local_date >= '2026-03-01'
AND experience_id = 'my-experience'
AND device_category = 'Mobile'Reference tables, each with its own tenant filter
A query against a reference table needs its own tenant filter. The reference tables
are steps, experiences, and projects. The filter makes sure that you see only
the rows of a project that you can reach:
| Source | Tenant filter |
|---|---|
steps, experiences | WHERE project_id = '<project_id>' |
projects | WHERE id = '<project_id>' (the row's id IS the project id) |
-- All experiences for one project
SELECT id, title FROM experiences WHERE project_id = 'your-project-id'
-- All steps for one project
SELECT id, title FROM steps WHERE project_id = 'your-project-id'
-- Metadata for one project
SELECT id, name, timezone FROM projects WHERE id = 'your-project-id'The small lookup tables (dim_variant, dim_device, dim_geo, dim_utm, dim_product) are still exempt — they contain no tenant data.
Related
- Virtual functions — the functions that take a filter.
- Analytics queries
