No Visitor Profiles

No profile is built for anyone who visits your site. Each page-view event is counted and discarded. There is no record connecting one visit to another.

What a visitor profile is

A visitor profile is a stored record that connects multiple visits to the same individual. It typically contains a visitor identifier — a cookie value, a device fingerprint, or a hashed IP — alongside a list of pages viewed, timestamps, referrers, and sometimes inferred characteristics like location or device type. The profile grows as the visitor returns to the site. Each new visit appends more data to the existing record.

Visitor profiles are powerful for certain applications. A returning-visitor count depends on them. A cohort analysis depends on them. A map of which users went from the landing page to the signup form and then to the confirmation page depends on them. All of these require a persistent record of who did what and in what order.

They also carry costs. The profile is personal data under most privacy regulations. It must be disclosed in a privacy notice. Depending on jurisdiction and use, it may require consent before collection. It must be protected against unauthorized access. If the protection fails, the exposed data describes real people's browsing behavior. That exposure is a harm even if the profile was never used for anything objectionable.

Why no profile is built here

The analytics design starts from a decision not to collect the raw material that profiles are made from. No visitor identifier is assigned. No cross-request link is established. Because the inputs for building a profile never arrive, no profile is ever constructed — not even temporarily, not even in a form that is later anonymized.

When the tracking script fires, it sends the page path, the referrer domain, and the resolution class. That is the entire payload. There is no user ID field in the event. There is no session token. There is no IP address captured in the long-term record. Without an identifier, there is nothing to attach subsequent visits to. The data store holds counters, not records of individual behavior.

This is not a matter of deleting profiles after collection. They are simply never formed. An event arrives, three or four counters increment, and the event disappears. The counters do not remember which requests incremented them. A request that arrived at 9:14 a.m. and a request that arrived at 9:47 a.m. both increment the same daily page-view counter for the same path, but they are otherwise indistinguishable and unlinked.

What this means for your data and your visitors

For your visitors, it means no one is watching their individual path through your site. Someone who reads five articles in a sitting does not accumulate a record that shows those five articles were read in sequence. A visitor who returns a week later is not recognized as returning. Each page view is a fresh, independent tally mark.

For you as a site owner, it means the analytics data you hold is counts and dates, not a database of individual behavioral histories. If you receive a data subject access request under a privacy regulation, the honest answer is that no record exists for that individual — because it was never created. That answer is the cleanest possible response, and it is fully accurate.

It also means that a breach of the analytics data store does not expose any individual's browsing history. The exposed data would be counts: 400 page views for /about on a given date, 60 referrals from a search engine. That is useful information for an attacker trying to understand a site's traffic patterns, but it is not a list of people and what they did.

The profile gap and what fills it

The absence of visitor profiles does leave a gap for operators who need to answer questions about individual behavior. If you want to know whether people who read the blog convert to paying customers, you need a way to connect the blog visit to the conversion event. This system does not provide that connection because making it would require either a shared identifier or a fingerprinting approach, both of which would constitute profile building.

For content-oriented sites — blogs, documentation, portfolios, informational pages, community hubs — the profile gap rarely matters in practice. The decisions those sites need analytics to support are about content and traffic, not individual user behavior. Which articles are getting read? Where is the traffic growing? Are mobile readers being well served? These questions are fully answered by aggregate counts.

If your site is a conversion funnel where the path from first visit to purchase is the central measurement, you will need a tool that builds profiles. That is a legitimate need. This system is not the right choice for it, and the help article on who this is not for explains the tradeoffs honestly.

Troubleshooting

If a visitor contacts you saying they appeared in your analytics and asks to be removed, you can respond honestly that no individual record was created. The analytics data contains counts by page and date, not records identifying individual visitors. There is nothing to delete that corresponds to a specific person.

If you are reviewing the dashboard and believe you can identify individual behavior from the page-view data — for example, because you have a very low-traffic site and can infer who visited from context clues you hold outside this system — the analytics itself has not created a profile. Any inference you draw comes from information you hold separately, not from data this system collected.

If a privacy audit asks whether visitor profiles are created by your analytics, you can point to the technical design: no identifier is assigned, no cross-request link is established, and the data store holds only aggregate counters. The privacy section of the help center covers this in more detail if you need supporting documentation for the audit.