What counts as a website visitor without cookies?

Pageviews versus visitors in Clicktag

A recorded page load or tracked route change adds a pageview. If someone reads five articles, that can produce five pageviews but just one visitor for that UTC day. The distinction matters when deciding whether traffic grew because more browsing identities arrived or because existing visitors read more pages.

Clicktag derives daily identity from the incoming request rather than saving a persistent browser ID. Counts can still diverge from people: shared networks and similar browsers can combine activity, while different browsers or networks can separate one person's activity. Treat both metrics as measurements with boundaries, not a census.

How daily visitor hashes are generated

For accepted traffic to a registered site, the collector combines the UTC date, a random daily salt, the site hostname, the connection IP, and the effective user-agent into a hash.

A new UTC day uses a new salt. The previous day's salt is removed about a minute after that day ends. The stored hash is not a persistent cross-day account identifier, and the collector does not accept a user-ID or client-IP override.

The practical consequence is simple: activity on both sides of midnight UTC contributes to two daily identities. Changing a dashboard's reporting timezone does not change when that underlying identity rotates.

How the Stats API calculates visitor totals

When querying analytics metrics through the Clicktag dashboard or the Stats API, the visitor metric is not a simple count of raw rows. The system applies explicit aggregation logic to determine the headline visitor number:

Visitors = Count(Distinct Non-Empty Hashes where is_bot = 0) + Sum(is_unique on unhashed pageviews where is_bot = 0)

This formula addresses two operational scenarios:

• Native collected traffic: For standard incoming traffic processed by Clicktag, every row receives a calculated visitor hash. The query deduplicates across non-empty hashes while applying the is_bot = 0 filter to strip out automated traffic.
• Historical imported data: When teams import older analytics archives that lack cryptographic hashes, the system inspects the is_unique flag recorded on entry pageviews. These flagged rows are added to the distinct hash count to preserve reporting continuity across migration boundaries.

For custom events (tt_event), visitor metrics require a non-empty hash. If an imported dataset contains unhashed custom event rows, those rows increment total event counts, but they contribute zero toward event visitor totals.

Network boundaries, shared IPs, and calendar days

Because Clicktag relies on connection metadata and daily salts, visitor numbers represent an operational traffic measurement rather than a census of physical human beings. Several network and time boundaries shape how these numbers behave.

Calendar day transitions

Daily hashes rotate at midnight UTC. If the same person visits your site on Monday afternoon and returns on Tuesday morning, they present the same IP address and browser, but Tuesday uses a different daily salt. As a result, Monday records one distinct hash, and Tuesday records another. If you query Monday alone, you see one visitor. If you query Tuesday alone, you see one visitor. If you run a report spanning both days, the deduplication engine finds two distinct hashes, returning two visitors because the same identity contributed on both days.

Shared networks and device conflation

Visitor counting is not a demographic census. If two coworkers share an office internet gateway with a single public IP address, and both browse your site using the exact same operating system and browser version, their connection attributes match. They generate the exact same daily hash and count as one visitor.

Conversely, if a single individual visits your site from their mobile phone on a cellular connection and later from their desktop computer on home Wi-Fi, their IP addresses and User-Agent headers differ. They generate two distinct hashes and count as two visitors. In practice, shared networks tend to group different people together, while multi-device usage splits individuals into multiple hashes.

Hypothetical counting scenario

The following hypothetical scenario illustrates how raw pageviews, visitor hashes, and bot flags interact in practice. All identifiers and request counts below are purely illustrative.

In this illustrative sequence:

• Step 1 generates hash_a for a regular desktop browser. It increments pageviews by one and visitors by one.
• Step 2 represents the same browser navigating to a second page. The hash matches hash_a, incrementing pageviews but adding zero new visitors.
• Step 3 originates from the same network IP (198.51.100.10) but from a macOS Chrome browser. Because the User-Agent differs, Clicktag generates hash_b, incrementing both pageviews and distinct visitors.
• Step 4 is an automated script. Clicktag computes hash_c upon ingestion, but sets is_bot = 1. In standard reporting queries where is_bot = 0 is enforced, this hit contributes zero pageviews and zero visitors.

Handling imported historical data

When importing historical analytics archives into Clicktag, source files often lack daily cryptographic hashes because previous platforms did not compute or store them.

To maintain continuous reporting across historical migrations:

• Pageview queries combine distinct non-empty hashes with the sum of is_unique entry flags on unhashed records.
• Live real-time monitors (such as the five-minute active visitor window) rely strictly on distinct non-empty hashes, ensuring imported historical records do not alter live counters.
• Custom events without hashes contribute to overall event occurrence counts, but do not artificially inflate event visitor figures.

This structured fallback allows teams to retain historical reporting baselines without retroactively generating artificial hashes.

Frequently asked questions

If two people share the same office Wi-Fi, do they count as one visitor?

If both individuals connect from the same external IP address and use identical browser and operating system versions, their User-Agent strings and network IPs match. In that specific scenario, they produce the same daily hash and Clicktag records them as one visitor. If their browser versions or operating systems differ, they generate distinct hashes and count as two visitors.

Does summing daily visitor counts over a month equal monthly unique visitors?

No. Daily hashes rotate every midnight UTC when the daily cryptographic salt changes. An individual returning five times across five separate days receives five distinct daily hashes. In daily reporting, they count once on each day. Summing those daily numbers yields five visitor counts rather than one monthly visitor. Cookieless hashing measures daily active visitors, not persistent longitudinal individuals.

Are web crawlers and scrapers assigned visitor hashes?

Yes. The Clicktag collector generates visitor hashes for all incoming HTTP requests, including bot and crawler traffic. However, the ingestion engine identifies automated agents through User-Agent rules and crawler signatures, setting is_bot = 1. Standard reporting queries apply an is_bot = 0 filter, which excludes crawler hashes from visitor and pageview metrics.

Does cookieless visitor counting eliminate the need for cookie banners?

Cookieless hashing removes the requirement to store persistent tracking cookies or device identifiers in client browser storage. However, analytics architectures do not provide universal legal exemptions. Compliance obligations under data privacy frameworks depend on your business location, how your organization processes network metadata such as IP addresses, and whether you collect personal data across other site features. Organizations must consult qualified legal counsel to evaluate their specific compliance requirements.