# Excluding traffic

> Keep your own visits, staging routes, and bots out of your analytics with path patterns, and keep secrets in query strings out of storage.

Section: Configure. Canonical page: https://mrkr.app/docs/configure/excluding-traffic. Last updated: 2026-09-02.

mrkr filters unwanted traffic in two independent layers: path patterns you configure, and automatic bot detection that runs on every request.

## Excluded paths

From **Settings → Tracking → Excluded paths**, add glob patterns. Any pageview whose path matches a pattern is dropped at ingest: before it touches rollups, sessions, or replay, and before it's billed.

### Pattern syntax

| Token | Matches |
| --- | --- |
| `*` | Any run of characters, including `/` |
| `?` | Exactly one character |
| anything else | Matched literally (case-insensitive) |

Patterns are anchored to the full path: there's no implicit prefix or suffix match.

| Pattern | Matches |
| --- | --- |
| `/admin` | Exactly `/admin`, nothing under it |
| `/admin/*` | `/admin/foo`, `/admin/foo/bar`, … |
| `/preview-*` | `/preview-abc`, `/preview-123`, … |

Up to 50 patterns per site, 200 characters each. The settings page includes a live tester: type a path and see immediately whether (and by which pattern) it would be excluded.

### Query strings are part of the path

mrkr stores the path with its query string attached, minus about thirty well-known campaign and click-id parameters (`utm_*`, `fbclid`, `gclid`, `msclkid`, `mc_eid`, `_ga`, `ref`, and similar) which are stripped so one page does not fragment into a row per campaign. Nothing else is removed. A URL like `/reset?token=abc123` or `/invite?email=someone@example.com` is stored as written.

> **Excluded paths are the mitigation for secrets in URLs:** If your app puts a password-reset token, an invite key, an email address, or any other sensitive value in a query string, exclude those routes. Patterns are matched against the full path including the surviving query string, so `/reset*` or `*token=*` both work. There is no automatic detection of a parameter that looks sensitive, and no way to remove a value from data already recorded.

## Excluding your own visits

There's no separate "exclude my IP" toggle. Use excluded paths for any internal route you control (a staging prefix, an admin path), or filter yourself out after the fact using [Filters and segments](https://mrkr.app/docs/analyze/filters-and-segments) on the dashboards you view. Neither approach retroactively removes data already recorded.

## Bot exclusion

Every request to `/api/collect` passes through a layered bot gate before anything is stored: this runs automatically and isn't configurable per site. Signals include:

- Client-side flags (`navigator.webdriver`, prerendering state, empty language list, zero-size viewport, missing UA-CH brands)
- Cloudflare's bot-management score, threat score, and datacenter/cloud ASN detection
- User-agent shape and known bot keyword patterns
- Origin and `Sec-Fetch-*` header consistency (catches scripted clients forging requests without a real browser)
- Referrer-spam matching
- A geo/timezone mismatch check (a browser timezone that doesn't match the visiting IP's country)
- Per-IP rate limiting

Filtered requests never reach pageviews, sessions, visitors, or billing: they're aggregated into a separate `bot_blocked` counter you can inspect under **Settings → Tracking → Bot filtering**, broken down by reason and by client type, without inflating the database with one row per bot hit.

> **Note:** Sessions that pass the bot gate but look suspicious after the fact (e.g. an unusually short lifespan) are hidden from dashboard views at read time, never deleted: deleting on a behavioral heuristic risks destroying real visits whose final beacon simply never arrived. See [Bots and spam](https://mrkr.app/docs/tracking/bots-and-spam) for the full model.