Why imported numbers differ

An imported day won't always match the number your old tool showed for it, and a range mixing imported and native days can behave differently from a range made up of only one kind. None of this is a bug in the import: it's what happens when two different instruments describe the same traffic. This page collects the reasons in one place.

Visitor counts are distinct counts summed across days

Pulse's own multi-day visitor count is a genuine deduplication: someone who visits three times in a month counts once. An import can't do that, because none of the four sources hands Pulse a durable cross-day identity for its historical rows. So visitors on imported days are the source's own daily counts, added together. Someone who came back on three separate days within your range counts three times, not once, over that range. A range made entirely of native days doesn't have this property; a range including imported days does, for the imported part of it.

Each tool counts its own way

Plausible, Umami, Simple Analytics and Matomo each define a visit, a bounce and a session boundary slightly differently from Pulse and from each other. An import carries a tool's own numbers forward as they were counted at the time, rather than recomputing them under Pulse's rules, because there's nothing left to recompute from: the source's export is aggregated or summarized, not raw enough to re-derive Pulse's own definitions from. The per-source guides list what each tool includes and what it doesn't.

A no-referrer row is recorded as Direct

For every source except Umami and Simple Analytics, an imported day arrives as one row per day, not one row per visit. Native Pulse tells a visit with no referrer that landed on your homepage (Direct) apart from one with no referrer that landed somewhere else (Shared Link) by reading the actual landing page. A day-level export has no landing page to read, so every no-referrer row from those sources shows as Direct. Umami and Simple Analytics export one row per pageview, so their imports can draw the same distinction native Pulse does.

Bounce rate and visit duration never merge

Every imported day shows an em dash for bounce rate and visit duration, and a range made up entirely of imported days shows an em dash too. This isn't a missing feature: even where a source reports something it calls a bounce rate, it's counted under that tool's own rules, not Pulse's, and averaging two different definitions together would produce a number that means nothing. Pulse shows its own bounce rate and duration, computed only from the days it measured itself.

Geo databases spell places differently

Region and city names come from whichever geo database produced them, either your old tool's own or the one Pulse resolves codes against. Two databases can spell the same place differently, most often in city names, and Pulse doesn't try to reconcile them. A city showing up as two spellings across the import boundary is a database difference, not two different places.

REST and MCP report a bounce-rate-only range differently

On a range made up entirely of imported days, Pulse's public API answers bounce_rate: 0 in /stats, while an MCP tool answers null for the same figure. Both are pointing at the same fact: there's nothing measured to report. The difference is in each surface's own type: the public API's Stats type isn't nullable, so 0 is what it answers for any range with no measured sessions in it, imported or otherwise; MCP's type is nullable, so it says so directly. Either way, meta.imported on the response tells you the range includes imported days, which is the signal to read instead of comparing the bounce rate to a native range's.