What this design cannot do

Visitor reporting uses a daily identifier, so the limits below apply to its aggregate counts. The API responses and dashboard expose the same caveats alongside the numbers.

• Visitors is a distinct-per-day count. Someone who visits Monday and Tuesday counts twice over a 30-day window. The visitor cookie does not change this count; it is used only for returning visitors.
• Returning visitors counts browsers that kept the cookie. The tracker sets one first-party cookie on your site's own host, holding a random id, for 400 days after the last visit; Safari keeps it for 7, so a Safari browser away for longer than a week comes back as new. One person on a phone and a laptop is two browsers. A browser that blocks the cookie, a site set to cookieless, and visits from before the cookie are left out, and the figures say how many visits that was.
• A device fingerprint is a likely match. Two identical devices with the same settings share one, so a visitor recognised by device can be two people, and a browser marked Likely returning may be someone new on the same model of phone. Brave and some privacy modes change the fingerprint on every visit, which costs a match but never invents one.
• A funnel's steps must fall within 24 hours. A longer window is rejected outright instead of quietly clamped. A browser with the tracker's cookie is followed across UTC midnight; one without it is followed to the end of its visit, and a new visit on a later UTC day counts as a different visitor. For conversions that really happen days later, attribute from billing records, where the durable identifier is the order.
• Geography stops at country. A city plus a timestamp starts to identify individuals, so there is no city setting to switch on by accident.
• There is no session replay, no user profiles and no week-by-week retention grid. The browser id is random and tied to one site; it is used to say whether a browser came back within 7 or 30 days, and nothing is built on it that follows a person.