Skip to content
DataVisitors Docs
Join the waitlist

Shields

The ingest rules that refuse an event before it is stored, and the three rules every project gets.

3 min read Updated Suggest an edit

Shields apply project ingest rules before DataVisitors stores an event. Configure them on the project's Settings page, under Shields.

An administrator edits the rules. Other project members can view the current values.

Blocked countries

Enter comma-separated two-letter country codes. DataVisitors normalizes each code to uppercase.

You can configure at most 30 country codes. A matching event gets the blocked_country rejection code.

Country handling uses a coarse country value. DataVisitors never stores a raw IP address.

Blocked paths

Enter comma-separated page paths. You can configure at most 30 paths.

An exact path blocks only that path. * matches inside one segment, while ** matches across segments.

Plain text 
/admin/**/internal/*

A matching event gets the blocked_path rejection code.

Allowed hostnames

Enter comma-separated hostnames to create an allowlist. You can configure at most 10 hostnames.

An empty list permits every hostname. A non-empty list permits browser requests from the named hostnames only.

This rule protects a public browser key when someone copies the tracker snippet. An unlisted browser host gets hostname_not_allowed.

Server senders without an Origin header are not browser snippet copies. The hostname rule does not block those requests.

Hosting networks

A visit from a compute cloud or a hosting provider — AWS, Azure, Google Cloud, Hetzner, OVH and others — is, with rare exceptions, a scraper or a monitor with a real browser's user agent. The Refuse hosting networks switch refuses them with the code hosting_network. It is on by default.

Two facts about the switch:

  • It applies to browser requests only. A server-side SDK runs in a datacenter by definition, and its events pass.
  • Relay networks are never refused. iCloud Private Relay and similar services leave the internet from content-delivery networks, and those networks are not on the list.

The known cost: a visitor on a company VPN that leaves the internet from a cloud provider is refused too. Turn the switch off if your audience works that way.

Rejection behavior

DataVisitors reports Shield rejections in the normal 202 response. Each rejected event has its input index and a stable code.

The response also contains the accepted count. DataVisitors never drops a Shield rejection without a result.

The same counts are kept per project, per day and per reason for 90 days. Tracking → Ignored traffic shows the last seven of them in plain words, so you do not need the response to find out what was refused.

DataVisitors does not provide IP rules. The product does not retain an IP address.

Built-in rules

Three rules apply to every project and need no setting:

  • Bots. A user agent on the bot list — crawlers, scripts, headless browsers, HTTP libraries — is refused with the code bot. For a request from a page in a browser, the browser's own User-Agent header is judged too, so a script that fakes the field in the event still fails on the header. A server-side SDK request is judged by the event's field only. The list is isbot's, the same public-domain list Umami uses, checked against 626 known crawlers and 555 real browsers.
  • Spam referrers. A referrer on Matomo's referrer-spam list, or under a listed host, is refused with the code spam_referrer. The list holds about 2,300 hosts. sub.semalt.com is refused because semalt.com is listed; notsemalt.com is not.
  • Prefetches. A request a browser makes for a page it is prerendering or prefetching is refused with the code prefetch. Nobody is reading that page.