The consent banner on a form page is a small tragedy. Someone clicked a link to answer three questions, and the first thing they are asked is to make a decision about data processing. A measurable number of them leave at that point, having told you nothing at all.
The banner is usually there because the analytics need a cookie to know that two page views are the same person. But for a form — as opposed to a whole website — you can get almost everything you would actually act on without one.
What the cookie is really for
Strip away the tooling and an analytics cookie does exactly one job: it makes two requests recognisably the same visitor. Everything else — the page, the referrer, the device, the timings — arrives in the request anyway.
So the question is not "can we do analytics without cookies", it is "how much identity do we actually need, and for how long". For a form the honest answer is: enough to link a view to a start to a completion, within one visit. That is a window of minutes, not months.
The question isn't whether you can do analytics without cookies. It's how much identity you actually need, and for how long.
How it works without them
Instead of storing an identifier in the browser, derive one. Hash together the visitor's IP address, their user agent, the form id, and a salt that changes every day. The same person, on the same day, on the same form, produces the same hash. A different person produces a different one.
Then discard the raw IP at the handler — never write it to a row — and never store the salt alongside the events. When the salt rotates at midnight, yesterday's hashes become permanently unlinkable to today's. Not by policy, not because a retention job will get round to it, but because the information required to link them no longer exists anywhere in the system.
That last property is the one worth caring about. A retention policy is a promise. This is a fact about what you are capable of.
What you can still measure
Views, starts and completions, and therefore the funnel. Per-question drop-off. Time spent on each question. Device type, browser, operating system. Country, from the edge, without geolocating an address yourself. Referrer, and every UTM parameter on the link.
That is essentially the complete list of things anyone acts on when improving a form. Nothing in that list needed a cookie.
What you genuinely lose
Cross-day identity. Someone who opens your form on Monday and finishes it on Tuesday counts as two people. For a form this matters less than it sounds, but it is a real limitation and it should be labelled honestly rather than quietly reported as "unique visitors".
Cross-device identity, which in fairness you never really had.
Returning-visitor metrics, which for a single form are close to meaningless anyway.
Long-window attribution. If someone clicks an ad in March and fills in the form in May, a cookieless setup cannot connect those. If that specific chain is central to how you spend money, you need something else — and you need the banner that comes with it.
Say what you mean in the interface
The failure mode here is not technical, it is labelling. "Unique visitors" that quietly means "unique visitors per day" is the kind of thing that ends up in a board deck as a number nobody can reconcile.
Write the caveat into the interface next to the number. It costs one line, it stops one meeting, and it is the difference between a limitation and a misrepresentation.
The part that isn't about compliance
It is worth being clear that this is not purely a legal calculation, and treating it as one leads to the wrong design. Plenty of jurisdictions would let you set a first-party analytics cookie with a lighter-touch notice than the full banner. The reason not to is different.
There is a version of analytics that treats the person filling in your form as a subject to be tracked across the internet, and a version that treats them as somebody answering some questions. The second one is achievable, costs you almost nothing that matters, and does not require a modal apologising for the first.
The banner is not the problem. The banner is a symptom of having built the first kind.
Where it still needs care
A hashed identifier is not anonymous data by default, and it is worth being precise about why this particular construction is defensible rather than hand-waving at the word "hashed".
A hash of an IP address alone is trivially reversible: there are only about four billion IPv4 addresses, and you can compute every hash in minutes. What makes the daily salt matter is that it moves the attack from "enumerate the inputs" to "enumerate the inputs and also know a secret you did not store". Drop the salt and the whole argument collapses, which is why it must never be written next to the events.
Country from the edge is fine; latitude and longitude are not, and the temptation to add them because the header is there should be resisted. A precise location attached to a survey response is personal data by any reading, and you almost certainly do not need it.
Free-text answers are the other place this goes wrong. Somebody will type their name into a comment box, and no amount of clever identifier design changes what is now sitting in your database. That is a retention and access question, not an analytics one, and it needs answering separately.
What to do if you already have a banner
Most form pages that show one are showing it because a site-wide script was included on every page, not because the form needs it. Check what is actually loading on the form route before assuming the banner is load-bearing.
It is entirely reasonable to run heavier analytics on your marketing site and cookieless analytics on the form itself. The form is the page where a banner costs you the most and buys you the least — the visitor arrived from somewhere you already know about, and they are there to do one thing.
If you take one thing from this: the page where somebody is about to give you information is the worst possible page on which to ask them for permission to watch them.