Set Up Website Analytics Without Tracking Cookies

The cookie is the problem, not the counting

The rule that produces cookie banners in the UK is about storage, not measurement. Under the Privacy and Electronic Communications Regulations, storing information on someone’s device, or reading information already there, needs their consent unless it is strictly necessary to provide the service they asked for. Counting how many people read your pricing page is useful to you. It is not strictly necessary to serve the page, which is why analytics cookies have never qualified for the exemption and why the ICO’s guidance keeps saying so.

That framing is helpful, because it tells you exactly what to change. You do not need to stop measuring. You need to stop storing. If nothing is written to the device and nothing is read back from it, the storage rule has nothing to bite on, and the consent prompt it forces goes away. You still have data protection obligations for any personal data you process, including IP addresses, so the second half of the job is choosing a tool that aggregates rather than retains, and saying honestly what it does on your cookies page and your privacy notice.

None of this is legal advice. It is the shape of the problem, and it is worth understanding before you compare products, because most vendors describe themselves as privacy-friendly and only some of them are actually cookieless.

Write down the five questions you need answered

Most analytics setups collect two hundred metrics to answer four questions badly. Before you install anything, write the questions down. For a small business site they are usually close to these: how many people came, where did they come from, which pages did they read, which pages did they leave from, and how many of them contacted you.

Every one of those can be answered without an identifier on the device. Pageviews are counted per request. Referrers arrive in the request headers. Country and device type can be derived at the edge from the connection itself. Landing and exit pages are per-request facts. Enquiries are counted by your form, not by your analytics.

The questions that genuinely need cookies are the ones about a specific person over time: is this the same visitor who came last Tuesday, how many sessions did they take before enquiring, what is the exact sequence of touchpoints in their journey. Decide now whether you care. A firm taking twenty enquiries a month can ring the customer and ask how they found you, and get a better answer than any attribution model would produce.

Choose a tool that writes nothing to the device

There are three approaches worth considering, and they differ in where the counting happens.

Edge or server counting. The request already reaches your host, so the host can count it. Cloudflare Web Analytics is the common example on a static site: you add a small beacon, or enable it for a proxied domain, and it reports pageviews, referrers, countries, browsers and Core Web Vitals without setting a cookie or building a profile. Server log analysis is the older version of the same idea and needs no client-side script at all, though logs include IP addresses and need a retention policy. This site uses Cloudflare’s version, with the token injected at deploy time rather than pasted into a page.

Cookieless script-based tools. Products like Plausible and Fathom send one beacon per pageview and derive a rough visitor count from a rotating, salted hash rather than a stored identifier. You get a dashboard that looks like Google Analytics without the storage, usually for a monthly fee, and usually with goal tracking and campaign parameters included. If you want more than counts, this is the tier to look at.

Google Analytics with Consent Mode defaulted to denied. This is the awkward middle. A tag container can load with Consent Mode v2 set to denied for analytics and advertising storage, in which case GA4 sends cookieless pings and writes nothing to the device. You get modelled, coarse data rather than real session data, and you keep the option of switching consent on later if you add a proper consent mechanism. It is a reasonable choice if you already live in Google’s reporting, and a strange one if you do not, because you are accepting the complexity of a tag manager to receive the least detailed version of the output.

A useful test when reading any vendor’s page: search it for the word “cookieless” and then check whether they mean no cookies at all, or no third-party cookies. Those are very different promises.

Install it, then prove it stores nothing

Installation is usually one line in the head of your pages or one toggle in your host’s dashboard. If your site is a static build, put the script or token behind an environment variable rather than hard-coding it, so a staging preview is not polluting your production numbers. That is the same discipline as keeping hosting decisions boring and reversible.

Verification is the step people skip, and it takes two minutes.

1. Open your live site in a private window.
2. Open developer tools, go to the Application or Storage panel, and look at Cookies, Local Storage, Session Storage and IndexedDB for your domain and for every third-party domain listed. All four should be empty.
3. Switch to the Network panel, reload, and filter by the analytics domain. You should see one small request per pageview. Check the response headers for Set-Cookie. There should not be one.
4. Click through three or four pages and repeat. Some scripts only write storage after a second pageview, which is exactly the kind of thing a single-page check misses.

If you prefer the command line, curl -sI https://yourdomain.co.uk | grep -i set-cookie on your key pages will tell you quickly whether the server itself is setting anything. Do this again after any change to your site’s third-party scripts, because storage tends to reappear when someone adds a widget.

Replace cookie attribution with tagged links

The real cost of dropping cookies is not the visitor count. It is that a visit-counting tool cannot tell you which channel produced an enquiry. Cloudflare Web Analytics will happily tell you a thousand people arrived and forty read your contact page; it cannot tell you that the enquiry in your inbox came from the newsletter.

You close most of that gap with two habits.

First, tag every link you control. Add UTM parameters to links in email footers, newsletter buttons, directory listings, social profiles and paid ads, and keep the naming boring and consistent: utm_source=newsletter&utm_medium=email&utm_campaign=september. A cookieless tool records the landing URL, so the tag survives even though the visitor does not carry an identifier onward.

Second, capture the source at the point of enquiry. A hidden field on your form that records the landing page and any campaign parameters from that visit gives you the one join you actually needed, from enquiry back to channel, without tracking anyone between visits. Add a plain optional question as a backstop. “How did you hear about us?” answered in free text by half your enquirers beats a modelled attribution report for a business at this scale.

Count enquiries, not sessions

Once you accept that sessions are approximate, the honest measure of a small business site becomes the number of completed enquiries and what they were worth. That number lives in your inbox and your CRM, not in an analytics dashboard, and it is not affected by cookie policy at all.

So build the reporting around it. Each month, record how many messages arrived through the contact form, how many were genuine, how many turned into work, and roughly what that work was worth. Then look at pageviews and referrers as context for those figures rather than as the figures themselves. This is a more useful monthly review than any funnel report, and it survives browser changes, ad blockers and the next round of privacy legislation, because it is made of facts you own.

Audit the rest of the page for stray storage

A cookieless analytics tool does not give you a cookieless site. Storage arrives through the components nobody thinks of as tracking:

• Embedded video. A standard YouTube embed sets cookies before playback. youtube-nocookie.com reduces that, and a static thumbnail that loads the player only on click removes it until the visitor asks for the video.
• Maps. An embedded map iframe is a third-party script with its own storage. A static image of the location plus a link to directions usually serves the visitor better and loads faster, which also helps the specific things that make a site slow.
• Fonts and CDNs. Hosting fonts yourself removes a third-party request entirely.
• Chat widgets, review sliders and social buttons. These are the most common source of surprise cookies on an otherwise clean site, and the least likely to earn their keep.

Work through your templates once and note what each third-party request is for. Anything that cannot justify itself in a sentence can go, and the site gets faster as a side effect.

Say plainly what you do

The last step is writing it down. A cookies page that says “we use cookies to improve your experience” is worse than nothing when you have gone to the trouble of not using them. State the position directly: which tool counts your visitors, that it stores nothing on the device, whether IP addresses are processed and for how long, and what happens to the details someone types into your form.

Two sentences of specifics do more for a cautious visitor than a paragraph of boilerplate, and they keep you honest if you later add something that does need consent. If that day comes, you will need a real consent mechanism rather than a banner that assumes agreement, and you will need to change the page. Keeping the page truthful is the same principle as only moving your lastmod date when something actually changed: the value of a claim on your site is that it can be checked.