Blocking unwanted traffic

Overview

Two kinds of traffic distort analytics without telling you: automated crawlers, and your own team testing in production. The first is filtered for you. The second is yours to exclude, and this page covers both.

How it works

Bot filtering is automatic

The JavaScript SDK checks the user agent before it collects anything, and drops traffic that isn't a real browser. Known crawlers are matched by name:

Beyond that list, the SDK looks for generic automation markers (bot, crawler, spider, scraper) inside user agent strings, so a crawler that isn't named above is usually still caught. Nothing is collected for traffic that fails the check, so filtered bots don't reach your project and don't count toward usage.

You can extend the list with crawlers of your own when you spot something the defaults miss.

📘 Good to know

No user-agent filter catches everything. A crawler that presents itself as Chrome is indistinguishable from Chrome at the point of collection. If you see traffic patterns that look automated, the techniques below apply to bots as well as to internal users.

Dropping an event at ingestion

Set ignore on an event and Intempt drops it before it reaches your project. Nothing is stored, and it doesn't count toward your plan's usage.

intempt.track({
  eventTitle: 'Page view',
  data: { ignore: true, path: window.location.pathname },
});

Only the boolean true drops an event. Any other value, including the string "true", an empty string, or false, lets it through.

📘 Good to know

That strictness is deliberate. Some analytics tools treat any non-empty string as a drop signal, which means a typo in a variable name silently discards traffic. Here, if the value isn't true, the event is kept.

Seeing what was dropped

Every project reports how many events were dropped and why, so filtering never silently eats data you wanted. Check it after changing a rule, and check it when a number looks lower than expected.

Drops are attributed to their cause: bot filtering, an ignore flag, or a project-level rule.

Excluding your own team

Use optOut() for traffic you don't want collected. It's the same control users get, applied on your side, and it stops collection rather than filtering after the fact.

// internal users are not tracked
if (currentUser.email.endsWith('@yourcompany.com')) {
  intempt.optOut();
}

This works anywhere you can identify the request as internal: an email domain, an internal role flag, a staging hostname, or an office network check your own backend performs.

See Protecting user data for the full opt-out reference.

Excluding server-side traffic

An opt-out set in a browser doesn't affect events your backend sends. Server SDKs accept the same ignore flag per event, so check whether the request is internal before sending and set it accordingly.

if is_internal(request_ip):
    intempt.track("Page view", user_id=user_id, ignore=True)

Separate projects beat filtering

The cleanest exclusion is not sharing a project in the first place. A project is a data silo, so testing against a separate project keeps development traffic out of production analytics entirely, with nothing to filter and nothing to clean up afterwards.

See Organizations & projects.

Cleaning up traffic already collected

Events in Intempt are immutable. You can't delete an event that's already been recorded, but you can exclude it from analysis.

Create a Created event that applies a condition excluding the unwanted traffic, then use that event in reports instead of the original. Once it exists, every report built on it filters automatically.

1. Open Events and select Create event.
2. Pick the ingested event you want a clean version of.
3. Add a condition that excludes the unwanted traffic, for example an attribute that identifies internal users.
4. Use the new event in your reports.

See Creating an event and How to create an event tracking plan.

📘 Good to know

Set the original event's Status to Hidden once the filtered version exists, so nobody builds a new report on the unfiltered one by accident. See Managing attributes.

Use cases

1. Your team tests a checkout flow in production and the conversion rate drops. Call optOut() for internal email domains.
2. A crawler that identifies as a browser inflates pageviews. Identify a shared attribute and exclude it with a Created event.
3. QA runs an automated suite against production nightly. Point it at a separate project instead.
4. A support agent reproduces a customer issue while impersonating them. Opt out during impersonation so their session doesn't land on the customer's profile.
5. Historical data includes a month of internal traffic before anyone noticed. Create a filtered event and rebuild the affected reports on it.
6. Your backend sends events from an internal service account. Check for it before sending, since a browser opt-out won't cover it.

Where to go next

• Protecting user data
• Creating an event
• Organizations & projects
• Live data feed