Hostname allow list

The hostname list is the only allow-list among the tracking rules. Empty by default, in which case every hostname is accepted. The moment you add a single hostname, strict mode kicks in: only listed hostnames are accepted, everything else is silently dropped. This defends against tracker theft. Manage it from /<domain>/settings/tracking-rules.

Why this exists

Your tracker script is public. Anyone can view the HTML of any page that uses Clickport and copy the snippet onto their own site. When they load it from their domain, the tracker happily sends events tagged with your data-site key, and those events get attributed to your account. Three things can happen:

  • Inflated counts. Your numbers go up. Looks great until you realize half the visitors are from a domain you've never heard of.
  • Burned tier. The hijacked traffic counts against your monthly pageview limit. A high-volume attacker can push you into the next tier.
  • Polluted insights. Sources, pages, countries, devices: all skewed by the foreign traffic.

The hostname allow list is a one-line fix. List your real hostnames, and anyone trying to send events from a different domain gets silently rejected. No error to the attacker (so they can't tell if the block worked or your tracker is broken), nothing written to your data.

When to enable strict mode

Enable it once you have a reasonable estimate of which hostnames your tracker legitimately runs on. For most sites, that's:

  • The apex domain (example.com).
  • The www subdomain (www.example.com).
  • Any active subdomains running the same tracker (blog, app, docs, etc.).
  • Optionally, your staging or preview host if you want staging traffic recorded too.

If you only have one or two hostnames, list them explicitly. If you have several or might add subdomains later, use the wildcard form: *example.com covers the apex and all subdomains.

Wildcard syntax

  • example.com: exact match. Only this hostname is accepted.
  • *example.com: matches the apex and any subdomain. example.com, www.example.com, blog.example.com, a.b.example.com all match.
  • *.example.com: matches subdomains only. www.example.com matches, but example.com alone does not. Useful only if you intentionally want to exclude the apex.
  • app*: matches anything starting with app. app.example.com, apps.io, even application-server.local. Use sparingly.

The wildcard is compiled to a regex when you save the rule. * becomes .* after every other regex metacharacter is escaped. So example.com with a literal dot in your input matches only the literal dot in the hostname, not any character.

What hostname is checked

The tracker sends the page's hostname in the event payload (the value of window.location.hostname at the time the event fires). The server reads that and matches it against your rules. The HTTP Referer header is not used because it can be spoofed; the tracker-reported hostname is the authoritative signal.

If the hostname is missing from the payload (older trackers, custom events fired without a hostname context), the rule list defers and lets the event through. This prevents false positives on legitimate custom events that don't carry hostname data.

Limits

  • 50 rules per site. More than enough for any normal site. Multi-subdomain enterprises with hundreds of hosts should use the wildcard form (*example.com) rather than listing each one.
  • Lowercase, no protocol, no path. example.com is valid; https://example.com, example.com/foo, example.com:8080 are not.
Lockout risk. If you add only staging.example.com while production lives at example.com, you'll silently drop all production traffic. Test with the wildcard form (*example.com) first if you're not 100% sure which hostnames the tracker runs from. If you do lock yourself out, remove the rule from a different network (your phone on cellular, a teammate's laptop) where your dashboard still loads.

Troubleshooting

I added a hostname and now no events come in

Your tracker is probably loading from a different hostname than the one you listed. Common causes:

  • You added example.com but production loads from www.example.com. Use *example.com to cover both.
  • Your CDN or reverse proxy serves the tracker from a different host. Check what window.location.hostname returns in your browser console on a live page.
  • You have an active staging copy on a subdomain that's now silently being dropped.

How can I tell if traffic is being rejected by the hostname rule?

For privacy reasons, rejected events return a normal 200 response and aren't logged separately. The simplest way to check: temporarily delete your rule, see if traffic resumes, then re-add it with the correct hostname. The cache refreshes within seconds.

Can I see which hostname the tracker is reporting?

Open your live site in a browser, press F12, run window.location.hostname in the console. Whatever that returns is what the tracker sends. Compare against your allow list.

I want to allow my staging domain but block everything else

Add both. List example.com (or *example.com) for production and staging.example.com separately. Strict mode only kicks in once you add at least one entry, so the list either accepts everything (empty) or exactly the listed entries (one or more).