Cookieless Analytics Without a Cookie Banner

Most small products do not need a full marketing analytics suite. They need to know how many people came, where they came from, which pages they read and whether they signed up. The tools that answer those questions with cookies and cross-site identifiers also bring a consent prompt, a privacy policy section and a slower page. For an indie app, that trade is rarely worth it.

This guide explains how cookieless analytics work, what you lose compared to a cookie-based setup, and the short list of numbers worth watching.

Why cookies became the default

Classic web analytics set a cookie with a long-lived identifier the first time someone visits. On every later visit, the same identifier comes back, so the tool can say “this is the same person as last month”. Advertising platforms take it further and share identifiers across sites to follow people around the web.

That model is powerful, and it is also the reason many sites show a consent banner before anything loads. In the EU and the UK, storing or reading information on a visitor’s device generally needs consent unless it is strictly necessary for the service the visitor asked for. Analytics cookies usually do not qualify.

The result is familiar: a banner, a large share of visitors who click “reject” or ignore it, and numbers that only describe the people who said yes.

How cookieless analytics count visitors

A cookieless tool skips the long-lived tracking cookie. There are two common approaches.

Daily hashes. The server combines the visitor’s IP address, user agent, the site and a salt that changes every day, then hashes the result. The same browser produces the same hash during one day and a different one tomorrow. You can count unique visitors per day without storing anything on the device or keeping the IP address.

A random id in local storage. The script creates a random string the first time a browser visits and keeps it in localStorage. It is not linked to a name, an email or an IP address, and it never leaves your site. It lets the tool tell two visits apart and keep a support chat attached to the right browser.

Indiehacker Studio uses the second approach: one random id per browser and per site, no cookies, and no IP addresses written to the database. The IP is read once at request time to find the country and to rate limit, then dropped.

Whether a given setup needs consent depends on your jurisdiction and how you use the data, so check with your own legal advice. The practical point is that a tool that stores no personal data and follows no one across sites removes most of the reasons for a banner.

What you give up

Cookieless analytics are less precise in a few places, and it is better to know them up front:

• Long-term returning visitors. If someone clears their browser storage or switches devices, they count as new. For a small product this is noise, not signal.
• Cross-device journeys. Nobody is following a person from phone to laptop. If you need that, you need accounts, and your own database already knows who your users are.
• Ad attribution beyond the first visit. You still get the referrer and UTM parameters for the visit that came in. You do not get a history of every ad a person saw.

In exchange you get numbers for every visitor, not just the ones who accepted a banner, and a script that does far less work.

The numbers worth watching

For a product run by one person, a short list covers almost every decision:

1. Visitors and pageviews over time. Is traffic growing, flat or falling? Look at a 30-day view, not today.
2. Sources. Which referrers and UTM campaigns bring people in. Tag every link you post yourself with utm_source and utm_campaign so launches and newsletters show up by name.
3. Top pages. Which pages people actually read. Your pricing page and your docs say more about intent than your home page.
4. Countries and devices. Enough to decide whether a mobile layout or a translation is worth the time.
5. One or two custom events. A signup, a checkout started, an export. These turn traffic into a funnel.

Live visitors are a nice extra on launch day: seeing a spike while a post is on the front page tells you whether the page holds people or not.

Custom events without a tag manager

You do not need a tag manager to send an event. With Indiehacker Studio, one line in your code is enough:

window.ihs?.track("signup", { plan: "pro" })

The optional chaining means nothing breaks if the script has not loaded or was blocked. Keep event names short and few. Ten events that you look at beat a hundred that you never open.

Single-page apps

If your app is built with React, Vue, Svelte or any router that changes the URL without a full page load, make sure your analytics script listens to history changes. A script that only counts the first load will show every visit as a single pageview. The Indiehacker Studio script tracks pushState, replaceState and the back button, so route changes count as pageviews without extra code.

A setup checklist

• Pick a tool that sets no cookies and does not store IP addresses.
• Install it on every app you run, not just the main one.
• Tag the links you control with UTM parameters.
• Add one custom event for the action that matters most.
• Check the 30-day view once a week and write down what changed.

Try it on your next app

Indiehacker Studio gives you cookieless analytics, a support chat bubble, feedback, bug reports and Stripe revenue from one script tag, for every project you run. Start free with one project and see your first visitor in a couple of minutes.