Getting numbers you can defend

Most "our numbers are wrong" reports trace back to one of five things. All five are covered here.

#Exclude internal traffic

The only owner-configurable exclusion mechanism is a per-site list of URL path patterns (glob-style: * and ?), checked before any event is written: an excluded pageview never reaches rollups, sessions, or the events table. There is no IP allowlist and no opt-out cookie. If your team's traffic hits every path a real visitor would (not a dedicated internal route), excluded paths can't isolate it; use filters to segment yourself out at view time instead, or route internal/QA visits behind a path you control and exclude that. See excluding traffic for the settings UI.

#Bot filtering happens before storage, not after

A request that fails the bot gate (client-side headless signals, User-Agent shape and pattern matching, missing browser fetch-metadata headers, a datacenter-hosting network, Cloudflare's bot score, a mismatched geo/timezone combination, referrer spam, or too many requests from one IP in a minute) never becomes a rollup, a session, an events row, or a realtime entry. It is filtered before storage, not hidden after the fact, so there's nowhere in the dashboard to "see" it and second-guess the call.

If a *real* visitor seems to be getting filtered, the two most common causes are a VPN or corporate proxy routed through a datacenter-hosting network, or a genuinely old browser tripping the version floor. Ordinary ad blockers don't cause this: they block the script from loading at all, which looks like no data rather than filtered data. See bots and spam.

#Avoid double-counting between outbound links and custom events

Click autocapture was removed in September 2026, so the old double-counting trap between it and mrkr.track() is gone: nothing records a click unless you asked for it. One overlap remains. A link that leaves your site, or points at a known file type, already emits outbound or download on its own. If you also call mrkr.track() from a click handler on that same link, or annotate it with data-mrkr-event, you get two rows for one click. This no longer costs you anything (neither event is billable), but it does mean any "clicks on this link" number you read is doubled, and a funnel step matching either name counts the same person twice as far as event totals go. Pick one per interaction: keep the built-in event where it says enough, or instrument it yourself where you need properties the built-in doesn't carry.

#Why cookieless and cookie-mode visitor counts diverge over long ranges

A cookieless visitor id is a hash of IP, user agent, site, and a salt that rotates once every UTC day, so the same person is one stable id *within* a day, but a different id the next day. Cookie mode uses a persistent id written to a cookie, so the same person stays one id across the whole range. Over a single day the two modes should be close. Over a multi-week range, a cookieless site's "Visitors" total legitimately runs higher than the same population would show in cookie mode, because it's counting unique (person, day) pairs, not unique people.

#Comparing against other analytics tools

A gap of 10–30% against Google Analytics or another tool is normal, not a sign either number is wrong. Bounce-rate definitions, bot lists, session-timeout windows, and visitor-identity models (persistent cookie vs. fingerprint vs. daily-rotating hash) all differ between tools, and each of those differences moves the totals independently. Before assuming a bug, check whether the two numbers move together as a stable ratio over time: that's a sign both are measuring real traffic consistently, just with different definitions, which is the expected outcome.