- A daily anonymous estimate, a returning browser, and a signed-in account are different units.
- Missing continuity is not permission to guess someone’s identity.
- Check the measurement definition and coverage before interpreting a return-visit count.
Start by asking what “visitor” means
A person can visit on a phone, return on a laptop, and later use a private browser window. Those visits do not automatically share a usable identifier. Conversely, several people can share one browser. A report labeled visitors needs a documented measurement unit before you can treat it as a count of people.
VisitLift’s basic tracking uses cookieless daily estimates. That is deliberately different from a persistent returning-browser history. Adding the estimates across days does not reveal a verified number of distinct people, and it does not reconstruct one person’s acquisition journey.
Check consent and storage boundaries
A returning-browser history needs a supported continuity mechanism. In VisitLift, attribution must be enabled for the website and the visitor must grant the required permission. A signup or payment is not a substitute for that grant. If the permission is absent, do not silently treat basic daily estimates as a persistent history.
Browser storage also has boundaries. MDN documents that local and session storage have different scopes and lifetimes, and that private browsing affects persistence. Clearing site data or changing browser context can remove continuity in an implementation that depends on that state. That does not mean every analytics tool uses the same storage mechanism.
Distinguish a browser from an authenticated account
An application can sometimes connect permitted browser activity to an account through an authenticated server assertion. That is stronger evidence about an application account than an arbitrary email string in a browser. It still does not establish that the account represents exactly one human.
VisitLift’s optional identity flow uses a short-lived assertion signed by the merchant’s authenticated server and requires consented attribution. It does not merge anonymous history by shared email, IP address, or device similarity. A payment only connects when the product’s verification and attribution requirements are met.
Debug one permitted return path
Use a controlled test with a known website and environment. First verify an accepted event. Then, when testing consented attribution, grant permission through the integrated consent flow, navigate, return in the same browser context, and inspect the expected continuity. Test revocation and logout separately because they intentionally change the boundaries.
Compare the same site, Test or Live mode, time window, and identity population. A different registered domain, an unavailable collector, or a new browser context can create a missing link. Check each boundary before concluding that a source report or returning-visitor count is broken.
Show the gap instead of inventing the journey
A useful report can say “unattributed” or “no connected return observed.” That is more informative than filling the missing part of the path with a guess. Missing observations can reflect coverage limitations; they do not prove the customer never returned or that a campaign had no influence.
For planning, use an explicitly illustrative diagram to show what you want to measure. For results, retain only the connected observations your configuration supports. The free visualizer does not identify visitors or repair missing attribution—it helps explain the question to your team.