What Cookieless Analytics Cannot Tell You

The trade, stated plainly

Cookie-based analytics works by giving every browser a persistent identifier. Once you have one, you can say "this same person came back on Thursday" and "this person saw the ad, then bought." That identifier is also personal data under most privacy regimes, which is why such tools need consent in many places and why browsers keep restricting them.

Cookieless analytics removes the persistent identifier. GhostMetrics, for example, stores no cookies and no localStorage, writes no raw IP addresses to its database, and honors Global Privacy Control and Do Not Track by collecting nothing at all when either is set. What you get in return is a dashboard you can run without a consent banner. What you give up is anything that depends on recognizing the same person later. Everything below follows from that one design decision. Our overview of cookieless tracking covers the mechanics in more depth.

Returning visitors: the daily hash

To count visitors without a cookie, GhostMetrics computes a hash on the server for each pageview from a daily salt, the site ID, the network address and the browser's user-agent string, and keeps only a truncated result. The raw address and user-agent are used in memory and are not written to the database. Three properties follow, and each one is a limit.

• It rotates daily. The salt is keyed to the UTC date and expires after 48 hours, after which it cannot be recovered. Yesterday's hashes can never be matched to today's, even by us.
• It is scoped to the site. The same person on two sites gets two unrelated hashes, so a tool like this cannot act as a cross-site tracker.
• It is built from network and browser details. Two people in one office with the same browser build behind one address can share a hash on a given day, and one person who switches browsers or networks gets another.

So "returning visitors" as a number is not something a daily-hash tool can give you. What it can give you is whether people come back to a page or a topic: top pages, the referrers that keep bringing traffic, and the trend of daily visits. For the how-and-why of the counting itself, see unique visitors without cookies.

What "visitors" means on the dashboard

A related trap is comparing visitor totals across tools. On the GhostMetrics dashboard, a visitor is an entry pageview: the first pageview in a browser tab's session. The tracker keeps a pageview counter in that tab's sessionStorage, and a pageview with a counter of one is an entry. Open a new tab and you are a new session; close the tab and the session is over.

That is a defensible definition, and it is also different from a cookie-based "users" metric that follows a browser for months. Neither number is wrong. They answer different questions, so comparing them directly will always look like a discrepancy. When you migrate, compare pageviews first, which are plain counts, and treat visitors as a new series.

Cross-device and logged-in behavior

A cookieless tool has no account concept, so it cannot join the phone visit that read your pricing page to the laptop visit that signed up. The hash is different on each device because the network and browser details are different, and nothing is stored that could bridge them.

If cross-device journeys matter to you, the honest options are to track them where the identity already exists. Your product database knows which logged-in user signed up; your email platform knows which subscriber clicked. Use the analytics tool for the anonymous top of the funnel (pages, sources, campaigns) and the systems of record for the identified bottom.

Funnels and revenue

GhostMetrics has a Funnel tab that takes an entry page and a goal page and counts the distinct session hashes that hit both. Because the hash is per day, a funnel is a same-day measure. A reader who lands on Monday and buys on Thursday is two different hashes and will not complete the funnel. Likewise there is no multi-step builder that follows individuals through five screens, and no per-user path analysis.

Custom events are the other half. You can mark any element with data-gm-event="signup-click" or call window.ghostmetrics.track() from code. An event carries its name, the page path and any session UTM, and an optional section label is the only metadata stored. There is no numeric value or revenue field. You can count how many people clicked "Buy", and you cannot attach a price to that click.

The workable pattern: count the intent in analytics (clicks on the checkout button, grouped by campaign), and read the revenue from your payment processor. Join them by date and campaign name, not by person. See our guide to custom events without Google Analytics for the setup.

Campaign attribution has a memory of one tab

GhostMetrics reads utm_source, utm_medium and utm_campaign from the landing URL and keeps the first set it sees in that tab's sessionStorage, attaching it to later pageviews and events in the same session. utm_term and utm_content are not stored. When the tab closes, the attribution is gone.

That gives you first-touch-within-session attribution, which is enough for "which newsletter issue drove signups today". It cannot give you multi-session or multi-touch attribution ("they saw the ad on Monday and the email on Wednesday"), because no identifier survives between sessions. Name your campaigns consistently and see the UTM parameters guide for conventions.

Direct traffic and bots

Two limits are not specific to cookieless tools, but they are worth stating because people expect a cleaner answer than any tool can give.

Direct traffic is a bucket of unknowns. A visit with no referrer header is recorded as direct. GhostMetrics cannot tell a typed URL from a link in a messaging app, an email client or a privacy-stripped referrer. Tagged links shrink the bucket; nothing empties it. The full breakdown is in direct traffic explained.

Bot filtering is a filter, not a verdict. At ingest, GhostMetrics drops requests whose user-agent matches known automation, crawler and HTTP-library patterns, and answers them with an empty 204 so the sender sees no error. A sophisticated bot presenting a real-browser user-agent passes that check. The dashboard's organization view helps you spot odd spikes, and the page on bot traffic and referrer spam covers how to sanity-check them. Because the tracker is JavaScript, simple crawlers that never run scripts do not appear at all, which is also why your numbers will be lower than a raw server log.

Reading your numbers honestly

Knowing the limits changes how you read the dashboard. A few habits keep a cookieless report trustworthy.

Compare periods, not tools

The most reliable use of any analytics number is the comparison of this week to last week inside the same tool. Definitions stay constant, so the trend is real even if the absolute count would differ elsewhere. Trying to reconcile a cookieless visitor count with a cookie-based "users" count is a recipe for a week of confusion; reconcile pageviews if you must reconcile anything.

Treat visitors as a daily-scale number

Because identity resets every UTC day, a 30-day visitor total is closer to a sum of daily audiences than to a count of distinct people. It is excellent for spotting a spike after a launch and poor for claiming "we reached 40,000 unique humans this quarter". If you need to say something to sponsors, say pageviews and top sources, and say how visitors are defined.

Look for patterns, not people

Healthy cookieless analysis asks about groups: which source sends readers who scroll to the bottom, which page has an unusually short time on page, which country appeared this week. Those are answerable from aggregates. If a question starts with "which user", it belongs in a system where the user agreed to be identified.

Write the definitions down once

Put one paragraph in your team notes: visitors are tab-session entries, attribution is first touch within a tab, funnels are same-day, revenue lives elsewhere. The first time someone asks why the numbers differ from last year's tool, the answer is already written.

Question by question: can cookieless answer it?

How to fill the gaps without giving up privacy

1. Write down the three questions you need answered. Most teams discover that two are pageview and source questions, which cookieless handles, and one is a revenue or identity question.
2. Tag every link you control with UTMs. Use a fixed pattern for source, medium and campaign. It shrinks direct traffic and gives per-campaign answers.
3. Add data-gm-event to the actions that matter. Signup, pricing, checkout, download. Name them like verbs and keep the list short.
4. Export on a schedule. The raw CSV or JSON export has every stored row, so you can group events by campaign in a spreadsheet to answer questions the panels do not.
5. Keep revenue where it already lives. Read it from your payment processor and match it to analytics by date and campaign name.
6. Use server logs for crawler and bandwidth questions. Your host or CDN sees requests that never run JavaScript.
7. Revisit after a month. If a question still matters and nothing above answers it, that is the point to decide whether the extra identity is worth consent and a banner.

When cookieless is not enough

Be honest about the cases where it is not. If your business runs on paid acquisition and you need ad-platform conversion matching, a cookie-based tool or the ad platform's own pixel is the tool for that job, with the consent that comes with it. If you run a store and need cohort-level lifetime value, you need identified customers in a system built for it. Our Google Analytics alternatives comparison lists where each tool lands on these capabilities.

For content sites, documentation, SaaS marketing pages, portfolios and newsletters, the questions that drive decisions are usually which pages work and which sources send readers. Those need no identity. Start with the free tier, look at a month of data, and see which of your questions it does not answer. More related guides sit in our analytics guides.

FAQ

Disclosure: GhostMetrics is built by Null Agency and we use it on this site, so we're not a neutral party about our own product — we've kept the claims to what the free and paid plans actually do, and pointed to Umami and other open-source, self-hostable tools where they genuinely fit better. Pricing for third-party products can change; always check the vendor's current pricing page before deciding.