Clickport
Start free trial
Intuitive Dashboard Engagement Tracking Session Tracking Goal Conversions Filtering & Segments Privacy First Real-Time Analytics Ask your analytics Bot Protection
For agencies For SaaS For e-commerce For affiliates For bloggers For publishers Google Search Console Bing Webmaster Tools WordPress Shopify Tracker install SPA tracking Custom Events API reference vs Google Analytics vs Matomo vs Cloudflare All comparisons
How It Works Blog Updates Documentation UTM Builder GDPR Checker GA4 Data Loss Estimator GA Legal Status GA Problems WordPress Analytics Bot Traffic AI Traffic Ecommerce Analytics About Contact Status Security

Tracking rules

Tracking rules are per-site filters that decide which traffic Clickport records. There are five levers, all under one tab: a personal "exclude this device" toggle and four site-wide lists for blocking IPs, countries, and pages, or restricting tracking to specific hostnames. Site-wide rules run at ingestion time. Matching events are silently dropped and never written to ClickHouse.

Open /<domain>/settings/tracking-rules to manage them. Each rule type is its own card on the page.

Exclude this device

The banner card at the top of the tab hides your current browser from your analytics. It is per-device and per-browser, stored in localStorage, and survives IP changes (mobile networks, Wi-Fi switching, VPN). Flip it once on every laptop, phone, or browser profile you want to skip.

See Exclude your visits for the full walkthrough including team exclusion and troubleshooting.

Block IP addresses

Reject events from specific IPs or CIDR ranges. Useful for blocking corporate office IPs, known abuse ranges, or your own static home IP.

  • IPv4 only. Single IPs are stored as /32. CIDR ranges are supported.
  • Breadth cap. The narrowest prefix accepted is /8. Anything wider (more than 16M addresses) is rejected to prevent block-the-internet mistakes.
  • Limit. 100 rules per site.

Examples: 91.249.178.98, 10.0.0.0/24, 185.220.100.0/22. IPv6 is not supported in v1.

Block countries

Reject events when the visitor's geolocated country matches a listed code. Country lookup uses MaxMind GeoLite2, same as the rest of the dashboard. Country resolution runs once per event, so blocking by country is the most expensive of the four list types (it happens after geoIP). Hostname, page, and IP checks run before geoIP.

  • ISO-3166-1 alpha-2 codes. Two letters: DE, US, RU, CN.
  • Anonymous proxies and VPNs can be blocked with the special code A1. This matches traffic that came in through MaxMind-classified anonymous proxy ranges.
  • Limit. 250 rules per site.

Block pages

Reject events for specific URL paths. Useful for excluding internal admin pages, staging routes, password-reset flows, and anything else that should not show up in analytics.

  • Paths start with /. Match is against the normalized pathname after tracking-param strip.
  • Wildcards. Use * to match anything: /blog/* matches /blog/post-1, /blog/2026/05/title, and /blog/.
  • Limit. 100 rules per site.

Examples: /admin, /wp-admin/*, /staging/*, /preview/*/draft.

Hostname allow list

The hostname list is the odd one out: it is an allow list, not a block list. When the list is empty, every hostname is accepted (the default). The moment you add a single hostname, strict mode kicks in: only listed hostnames are accepted. Everything else is silently dropped.

This is the defense against tracker theft. If someone copies your snippet onto a different domain to inflate your counts or stress your tier, an allow list shuts them out without you needing to notice the abuse first.

  • Wildcards. Use *example.com to allow the domain and all subdomains. Use example.com to allow only the exact hostname.
  • Limit. 50 rules per site.
Lockout risk. If you add a hostname like staging.example.com but the tracker runs on example.com, all production traffic drops. Test with the wildcard form (*example.com) first if you are unsure which hostnames the tracker actually loads from.

How rules are applied

Every event from the tracker passes through tracking rules before bot detection. Checks run in this order:

  1. Hostname allow list. If the list is empty, pass. If the event hostname matches any listed rule, pass. Otherwise drop.
  2. Page block list. If the normalized pathname matches any rule, drop. Otherwise pass.
  3. IP block list. If the visitor IP falls within any blocked CIDR, drop. Otherwise pass.
  4. GeoIP resolution. Country code is resolved here.
  5. Country block list. If the resolved country is in the blocked set, drop. Otherwise pass.

A drop returns HTTP 200 with no event written. Bot operators and scrapers can not distinguish "your rule blocked me" from "your tracker accepted but did nothing" because the response shape is identical to a normal accepted event. The tracker silently moves on.

Rules apply within a few seconds of being added or removed. Existing pageviews already in ClickHouse are not retroactively removed; only future events are affected.

What happens to blocked traffic

Blocked events disappear entirely. They are not stored in ClickHouse, not counted in the bot stats buffer, not counted against your pageview tier. The blocked-event drop happens before the daily event cap, so blocked traffic does not push you closer to your tier limit.

Sessions are not retroactively cancelled. If a visitor arrived through an accepted pageview and then started matching a new rule mid-session, only the new events drop. The earlier pageviews stay.

Troubleshooting

I added a rule but events are still arriving

  • Wait a few seconds. The cache refreshes on every rule mutation, but in-flight events may have read the old cache. Within a few seconds, new events go through the new rule set.
  • Check the rule. Open the page card and confirm the rule shows up. If it failed validation, it never persisted.
  • Match the hostname carefully. Hostnames are case-insensitive but exact otherwise. example.com does not match www.example.com. Use *example.com to match both.
  • Match the path carefully. Paths must start with / and match the normalized pathname. Trailing slashes are normalized; query parameters are stripped before matching.

My production traffic disappeared after adding a hostname rule

You probably added the wrong hostname. Open /<domain>/settings/tracking-rules on a device where the dashboard is still loading (your phone, another network) and delete the rule. The list goes back to empty, and the allow-list returns to accepting all hostnames. Then add the correct rule.

How do I block my own IP?

For a single device, use the "Exclude this device" toggle at the top of the tab. It is faster and survives IP changes. For an office or VPN exit, find the static IP and add it to the IP block list.

Does GA4 have something like this?

GA4 has IP filters and bot filtering, but no native country, page, or hostname block list. The hostname allow list in particular is unique here. GA4's domain configuration controls cross-domain tracking, not which hostnames are accepted into the pipeline.

Previous Share Links