Rule sets
A rule set is the actual definition of access. Groups point at one; this is where the decisions live.

Settings → Rule sets lists them with the groups they're assigned to and the datasets they cover.
Anatomy
Opening a rule set shows:
- Name and an optional description — worth filling in, because the next person to inherit this account will thank you
- Default dataset — which dataset members land in
- Assigned to — the user groups using it
- Datasets — the datasets it covers
Then, per dataset, a separate configuration. That's the important structure: one rule set can behave differently on each dataset, so a group can have broad access to one and narrow access to another.
Per-dataset settings
Select a dataset within the rule set to configure it.
| Panel | Controls |
|---|---|
| General | Dataset-level basics |
| Views | Which pages and reports appear, and where |
| Metrics | Which metrics are available |
| Intervals | Which time intervals can be chosen |
| Dimensions | Which dimensions can be filtered and broken down by |
| Dayparts | Daypart definitions |
| Filter rules | Which data is visible at all — see below |
| Modules | Whether Audience, Campaigns and Inventory check are switched on |
Turning a dimension or metric off here removes it everywhere for that group — filter pickers, breakdowns and tables alike. It's the tidiest way to keep an interface focused on what a team actually uses.
Views
Views decides which pages a group gets and how its menus are arranged.

Each view has a tick to include it, a Category setting which menu it appears under, and a Type — a standalone page, a single report, or a report group. Views can be dragged into the order you want them to appear.
Default view sets where members land after signing in. Point it at whatever the group opens first — a monitoring team probably wants their report, an analytics team probably wants Research.
Filter rules
The most consequential panel, and the one behind most "why don't our numbers match?" questions. There are two kinds, and the difference matters.

Permission filters
Permission filters are a hard boundary. Users cannot override them. They apply in two places at once:
- Filter pickers — only permitted values can even be selected
- Results — data is limited to those values and their related entities
Set a permission filter to one agency and that group sees only that agency's data, including related values elsewhere such as campaigns. Nothing in the interface offers a way around it.
This is the tool for genuine access boundaries — an agency, a partner or a region that must not see anyone else's data.
Global filters
Global filters are defaults, and users can override them through the ordinary filter picker. Set country to GB and results load as GB, but a user can change it.
This is for convenience, not security: it saves a team setting the same filter every morning.
Don't use a global filter for a security boundary
A global filter looks like it restricts data, but any user can lift it in the filter picker. If a group must never see data, it needs a permission filter. Getting this wrong is the most serious mistake available on this screen, and nothing in the interface will flag it.
| Permission filter | Global filter | |
|---|---|---|
| User can override | No | Yes |
| Affects filter pickers | Yes — values are hidden | No |
| Purpose | Access boundary | Convenient default |
Changing a live rule set
Rule sets apply to everyone in the attached groups, immediately. Before changing one:
- Check Assigned to — know who you're about to affect
- Prefer a new rule set over widening an existing one, when only some people need more
- After changing a permission filter, have someone in the group confirm they still see what they should — and no longer see what they shouldn't