Configure4 min read
Excluding traffic
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) |
| 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.
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 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 → Bot filtering, broken down by reason and by client type, without inflating the database with one row per bot hit.
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 for the full model.