Your cookie banner is optional

A cookie banner is not a legal requirement. It is a symptom. Sites show one because something on the page stores an identifier on the visitor’s device and turns their behaviour into personal data. Remove both of those things and the banner has nothing left to ask for.

That distinction matters, because most teams treat the banner as an obligation to satisfy rather than a consequence to remove. It is the second one.

What the law actually requires

Two separate rules get collapsed into “the cookie law”, and they do different jobs.

Storage on the device. In the EU this is the ePrivacy Directive 2002/58/EC, Article 5(3), as amended in 2009. It requires informed consent before storing information on, or gaining access to information already stored on, a user’s terminal equipment. In the UK the equivalent is Regulation 6 of the Privacy and Electronic Communications Regulations (PECR), which the ICO enforces alongside the UK GDPR.

Note what that rule is written about: storage and access, not cookies. Using localStorage, sessionStorage, IndexedDB, or a device fingerprint instead of a cookie does not route around it. This is the single most common mistake in “cookieless” marketing claims.

Processing personal data. Separately, the GDPR governs what happens to any personal data produced. This is where IP addresses come in: in Breyer (C-582/14) the Court of Justice held that a dynamic IP address can be personal data in the hands of a website operator where means reasonably likely to be used exist to identify the person behind it. An analytics tool that retains raw IPs is processing personal data even if it never sets a cookie.

You need to clear both rules. Clearing one is not enough.

Why analytics does not get the “strictly necessary” exemption

Article 5(3) has two narrow exemptions: storage carried out solely to transmit a communication, and storage that is strictly necessary for a service the subscriber has explicitly requested.

Teams reach for the second one for analytics, and regulators have consistently declined it. The reasoning is simple and hard to argue with: your website works perfectly well for the visitor whether or not you count them. The measurement serves the operator, not the person who asked for the page. The ICO’s guidance under PECR takes this line, and it is why the “analytics is essential to our business” argument does not survive contact with a regulator — essential to the business is not the same as strictly necessary to the requested service.

Some national regulators have carved out a narrow path for genuinely anonymous audience measurement under strict conditions — France’s CNIL is the best-known example, with an exemption scheme for audience-measurement tools that meet a specific set of limits. Those schemes are conditional, jurisdiction-specific, and worth reading in full before relying on one.

Where the line actually sits

The banner becomes unnecessary when both of these are true at once:

1. Nothing is stored on or read from the visitor’s device. No cookie, no localStorage, no fingerprint, no device-level identifier of any kind.
2. No personal data is processed. No retained IP address, no stable cross-visit identifier, nothing that could single out a person.

Miss either one and you are back inside the rules. A tool that sets no cookies but stores raw IP addresses has solved the ePrivacy problem and kept the GDPR one. A tool that hashes an identifier and keeps it for thirty days has not really removed the identifier — it has obscured it, and a stable pseudonymous ID is still personal data under the GDPR.

This is also why “GDPR-compliant analytics” is a weaker claim than it sounds. Google Analytics can be operated in a GDPR-compliant way, with consent and the right contracts. That compliance is what the banner buys you. Removing the banner is a different and stronger claim: there is nothing here that consent would be about.

What sonex does instead

sonex counts a visit without ever identifying the visitor. No cookie is set and nothing is written to the device. Requests are aggregated on arrival — no raw IP is retained, and there is no stable identifier that survives to link one visit to the next.

Because nothing is stored on the device, Article 5(3) and PECR Regulation 6 have nothing to attach to. Because no personal data is processed, there is no GDPR lawful basis to establish. The consent question does not get answered; it stops being asked.

Not sure whether that applies to your site? Run the do I need a cookie banner check — it walks the same two tests above against whatever you currently have installed.

What you still get

Dropping the banner does not mean dropping the numbers. You keep:

• Visitors, views, bounce rate and visit duration
• Referrers, top pages, campaigns and outbound links
• Country, region and city from coarse geography
• Realtime, funnels and session flows

You lose the things that genuinely require identifying people: cross-site retargeting audiences, individual user profiles, and advertising integrations built on them. If those are load-bearing for your business, you need consent and you need the banner — and that is a legitimate choice, not a failure.

For everyone else, the trade-off people assume exists between insight and privacy mostly is not real.

The one script

Add the tracker to your <head> and delete the consent modal:

<script defer
  src="https://api.trysonex.com/sonex.js"
  data-website-id="YOUR_WEBSITE_ID"></script>

That is the whole migration.