# Data controls

Tenant-level controls over what enters your analytics — a blocklist to exclude activity, and bulk import.

The **Data controls** settings govern what data lives in your tenant: which activity is kept out of your analytics, and how to bring data in in bulk.

## What it is

Data controls are two tenant-level tools that shape your dataset. The **blocklist** excludes specific activity from analytics, and **import** loads data into the tenant in bulk. Together they let you keep noise out and pull relevant data in.

## Blocklist

The blocklist keeps unwanted traffic out of your analytics — internal test accounts, bots, load-test runs, or any traffic that would otherwise skew your numbers. Editing it requires **Organization Admin** or higher.

### How a rule matches

A rule is `<property> equals | not_equals <value>`. You type the property name yourself, and Brizz matches it against the incoming signal's attributes — span attributes on a trace, log attributes on a log. It tries both the name you typed and a `brizz.`-prefixed version, which is what makes a [custom session property](/docs/instrument/sessions.md) match: send `plan`, write a rule on `plan`, and it finds `brizz.plan`.

Names and values accept only letters, digits, `_` and `-`, so a dotted key like `brizz.user.id` can't be entered. Resource attributes aren't visible to rules either — the SDK's `environment` setting is one, so send it as a session property if you need to match on it.

Each rule can hold up to ten alternative values, which match as OR — one rule covers `env` equals `staging` or `test` or `ci` without needing three rules.

### What a rule does when it matches

Each rule picks one of three actions, and the difference matters:

- **Block** — the telemetry is dropped on arrival. Nothing is stored and nothing is analyzed. Data already in your tenant is unaffected.
- **Skip Analytics** — the raw traces are still stored, but the matching telemetry is kept out of the conversation and session analytics built on top of them. Expect the trace to exist while the session view has nothing to show.
- **Skip Metrics** — sessions stay fully visible and still get analyzed; labelling and issue detection keep running. Only quality-metric extraction is skipped, so issues derived from those metrics aren't produced for matching sessions.

Reach for **Block** when you never want the data at all, and **Skip Metrics** when you still want to open the session and read it. **Skip Analytics** sits between the two: the data is retained but most of the product won't show it.

### Default vs per-service rules

Rules come in two layers. **Default rules** are evaluated for every service. **Per-service rules** are evaluated in addition to them, for the one service you attach them to — so a service ends up subject to the defaults *plus* its own, not one instead of the other.

When more than one rule matches the same traffic, **Block wins**: if any matching rule blocks, the telemetry is dropped and the Skip actions become moot.

## Import

Import bulk-loads data into your tenant. Use it to bring in data in a single operation rather than one record at a time. The in-product import flow walks through the supported input and steps for a given import.

## Availability

Requires **Organization Admin** or higher.

## See also

- [PII & privacy](/docs/instrument/pii-and-privacy.md) — control what sensitive data reaches Brizz in the first place.
- [Identify users](/docs/instrument/identify-users.md) — send a user identity so you can write a blocklist rule against it.
- [Sessions (instrumentation)](/docs/instrument/sessions.md) — attach custom properties to a session so blocklist rules can match on them.