Cookie banners and consent
Usually no banner.But not because of cookies.
Plenty of vendors write: cookie-free, so no banner. The conclusion is often right, the reasoning almost never. What matters is not the cookie but whether anything already stored in the terminal device is accessed. In Minimal and Standard we store nothing on the device, and what we read was not there beforehand. In Full mode we write an identifier, and there you do need consent. Here is the whole derivation, including the opposing reading.
The claim
No cookie, no banner. Right answer, wrong reasoning.
Cookie-free, therefore consent-free, therefore no banner. That chain appears on nearly every privacy-friendly analytics site. The conclusion holds in many cases, the route to it does not, and anyone relying on the wrong reasoning finds out only when someone asks.
§ 25(1) TDDDG, the German provision implementing Art. 5(3) ePrivacy, does not attach to cookies. It attaches to two acts: storing information in the terminal device, and accessing information already stored there. A cookie is only the best-known instance of the first. Setting no cookie therefore settles one half of the question, not both.
The second half decides the banner: is anything accessed that is stored in the device? For Minimal and Standard our answer is no, because what gets read are status values the browser itself produces at the moment of the page view. For Full mode the answer is yes, because an identifier gets written.
We set out both, including the stricter view that reaches a different conclusion. The controller for the integration is you, not us. A claim in a feature list will not help you in proceedings; a derivation you can follow will.
What it turns on
Four questions, not one.
Whether you need a banner turns on four points. Cookies are only one of them, and the least important.
Cookie or not is secondary
§ 25 speaks of information, not of cookies. What matters is whether anything is stored in the device or read from it, whatever the carrier.
Stored, or produced at runtime
A cookie is already there. A measurement comes into being during page load. Only the first is, on the wording, access to stored information.
Fingerprinting or not
Status queries tip into requiring consent as soon as they become a recognition signal. That is why we transmit classes rather than raw values.
Which preset
Minimal and Standard write nothing to the device. Full writes an identifier into sessionStorage, and there consent is required.
Layer 1: § 25 TDDDG
Storing or accessing, and which of them we do.
Die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf Informationen, die bereits in der Endeinrichtung gespeichert sind, sind nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat.
German Telecommunications Digital Services Data Protection Act. In English: storing information in the end user's terminal equipment, or accessing information already stored in it, is permitted only where the end user has consented on the basis of clear and comprehensive information.
Two triggers, one word between them: or. Storing is enough, accessing is enough, they need not coincide. Whether the information is personal data is irrelevant for § 25. The provision protects the device, not the data.
Storing: in Minimal and Standard we do not. No cookie, no localStorage, no sessionStorage. The write path is removed from the shipped bundle at build time, so it is not present in the browser rather than merely switched off.
Accessing: here the decisive word sits in the statute, namely information that is „already stored in the terminal equipment“. What our script reads was nowhere beforehand. The timings come into being during page load, window.innerWidth is the current window state, navigator.connection a running estimate by the browser. These are queries to the runtime environment, not to a store.
It gets borderline where such queries turn into a recognition signal, that is, fingerprinting. Which is why we transmit one of six viewport classes rather than the pixel value. That lowers the entropy far enough that recognition from this combination is practically ruled out. Full mode is a different matter: there an identifier is written into sessionStorage, and a write is uncontroversially covered. The exemptions in § 25(2) do not carry it: no. 1 covers only the mere transmission of a communication, and no. 2 requires the access to be strictly necessary for the provider to supply a service the user explicitly requested. A performance measurement is not that service.
The opposing reading, in full
Our classification is not the only defensible one. There is a stricter reading, and it is well sourced. Here it is, with what would follow from it, so you can weigh both instead of taking our word.
DSK, guidance for providers of digital services
Unlike data protection law, § 25(1) TDDDG establishes a consent requirement for the storing and/or reading of information on or from a terminal device irrespective of whether that information is personal data.
This applies to us too. § 25 does not turn on personal data, so „we process no personal data“ is not an argument here. The only question is whether there is storing, or access to something stored.
DSK, on reading via JavaScript
It also counts as accessing information on end users' terminal equipment where, for example, properties of a device are actively read out by means of JavaScript code and transmitted to a server in order to create a fingerprint.
The stricter reading extends this sentence to any reading via JavaScript. It sits in a fingerprinting context, though, and that is exactly where our line runs: classes rather than raw values, no recognition, no fingerprint.
EDPB, Guidelines 2/2023, local processing
This may be the case, for example, with an API provided by the web browser whose locally generated results can be retrieved remotely.
This is the strongest point against us. The EDPB includes locally generated results of a browser API. Follow it and our performance measurement is covered too, and consent would be required.
EDPB, Guidelines 2/2023, gaining access
Such access clearly falls within the scope of Article 5(3) ePrivacy Directive, since the accessing entity explicitly instructs the terminal equipment to transmit the information.
This sentence also supports the strict reading. Against it we hold the German statutory text, which requires information that is already stored. Which interpretation prevails has not been settled by a court.
EDPB, Guidelines 2/2023, storage and access
The storage of information and the access to information already stored need not both be present for Article 5(3) ePrivacy Directive to apply.
Which is why „we set no cookies“ is not sufficient as reasoning. The second trigger has to be assessed on its own, and that is exactly the section above.
Read the originals
Our conclusion
In Minimal and Standard mode, in our assessment no consent is required under § 25(1) TDDDG: nothing is stored in the device, and the status values that get read were not there beforehand. In Full mode it is required, because an identifier gets written. This assessment has been reviewed with our external data protection officer. A residual risk remains, because no court has ruled on this constellation.
What happens on the device
Line by line, nothing smoothed over.
Three collection presets, and what each of them actually does on the visitor's device. The second-to-last row is the dividing line.
| Minimal | Standard | Full | |
|---|---|---|---|
| Beacon script delivered to the browsersits in the browser cache, like any script on a page | |||
| Performance API readLCP, INP, CLS, TTFB, navigation and resource timing, produced during page load | |||
| Viewport class and connection class read | |||
| Error objects readtype and count, stack frames from Standard up | |||
| Anything written to the deviceFull only, one tab-bound session ID in sessionStorage._fms | |||
| Cookie set | |||
| Long-lived or cross-site identifier | |||
| Consent under § 25 TDDDG requiredbecause of the write in Full, not because of cookies |
The dividing line is the row „Anything written to the device“. Above it sit values that come into being during page load and were not in the device before. Below it sits a write, and a write uncontroversially requires consent.
Layer 2: GDPR
Applicable, and because of the IP.
§ 25 TDDDG governs access to the device, the GDPR the processing that follows. The two are assessed separately, and the answers are allowed to diverge: no access under the TDDDG but the GDPR applicable is precisely our case.
The payload values themselves we consider not relatable to a person: country instead of IP, classes instead of raw values, path without query string, no user ID, no long-lived recognition. The GDPR applies regardless, because of one item we never query. The IP address travels in the HTTP header of every request, and under the CJEU's Breyer ruling it is personal data.
The legal basis is the legitimate-interest balancing test in Art. 6(1)(f) GDPR, not consent. On one side sit stability, performance measurement, basic statistics and debugging; on the other the visitor's protected interest. The risk to them is low: no cross-site tracking, no profiling, no fingerprinting. That balance would tip the moment it became an analysis of user behaviour in the sense of profiling. For that, the case law consistently requires consent, from Planet49 through the German Federal Court's cookie-consent ruling to the CJEU's Meta judgment. It carries here precisely because fastmon builds no profile.
That balance only holds under conditions, and we meet them: IP and user agent are processed solely to receive the request and discarded in under a second, no reconstructible IP sits in the stored analytics data, and we pass the data to no one.
Two deployments, two outcomes
Large, generic sites
A shop with six-figure visitor numbers, generic paths such as /category/shoes, many visitors per path and country. A single record fits thousands of people.
Usually not relatable to a person
Small or highly specific sites
A B2B portal with a handful of visitors a day, speaking paths such as /customers/northwind-ltd/contract or /application/status. Country, device and path together can converge on one person.
Possibly relatable, assess it yourself
This classification is a case-by-case assessment and the controller's job, which means yours. We supply the factual basis and the documentation for it; we cannot make the call for you. In practice it decides your legal basis, your information duties and your retention. In both scenarios fastmon belongs in your privacy policy.
IP address and edge
The place where it stays borderline for us too.
Under the case law of the Court of Justice of the European Union, an IP address is personal data. It is transmitted on every page view, which is technically unavoidable and unproblematic for delivering the page. It gets interesting once you use it to derive something.
Which is exactly what our edge does, in more than one place: From the IP it resolves the country code and checks whether it belongs to a datacenter or a verified crawler. From the user agent it derives coarse classes: browser, major version, operating system, device type, plus a bot classification. It checks the browser's client hints for contradictions to spot spoofed requests. It condenses the referrer to medium and source, without search terms. And it computes the stitch. It then discards the IP, the raw user agent, the client hints and the referrer URL in under a second, without storing or logging them. Only the results reach the fastmon application. That is the point of the architecture: the application is never to see the raw data, and automated tests verify that it stays that way.
And here is the honest caveat. Each of these derivations is an analysis, and it happens before the application sees anything. Passing on only the extract moves the personal reference out of the application. It does not undo the derivation itself: for a fraction of a second, personal data was processed.
We rest that step on the same legitimate-interest balance: brief processing, immediate discarding, no reconstructible remainder in the stored data. Whether that survives a future court assessment is open. We think it more likely that requirements tighten over the medium term than loosen. Anyone selling you certainty here is selling you an opinion.
One page view, step by step
- 01
Browser requests the script
The request carries the IP address, like every HTTP request. Technically inherent transmission, unproblematic for delivery.
- 02
Beacon reads in the browser
Performance API, viewport class, connection class, error objects. Status values of the runtime environment that were not in the device beforehand.
- 03
Edge derives and discards
Country code and datacenter check from the IP, device classes and bot classification from the user agent, medium and source from the referrer, stitch. After that the IP, user agent, client hints and referrer URL are gone, in under a second, with no log. This is the borderline step.
- 04
Application sees only the extract
Country, classes, metrics, path without query string. No raw IP, no user agent string, no persistent identifier.
The stitch stays borderline
To count unique visitors, the edge computes a short pseudonymous signal: HMAC-SHA256 over IP, user agent, the hash of your embed and the domain, under a salt that is regenerated every 24 hours and never leaves the edge's memory, no log, no disk, no API. Different per domain. What protects the signal is not the mathematics but the salt: the stored value alone yields no IP, but anyone holding the salt could try candidates and confirm a suspicion. Nobody holds that salt: it exists only inside the running edge process, the same process that sees and discards the IP on every request anyway. After rotation it is irretrievably gone, and from that point on nobody can make the link, us included.
The stitch comes into being at the edge, not in the browser, so it is not a § 25 question but a GDPR one. We treat it as personal data, pseudonymisation rather than anonymisation, and rest it on the legitimate-interest basis. That reduces the risk, it does not remove it: a signal that joins page views across 24 hours is a form of recognition, and with highly specific paths a personal reference can arise. store_stitch=false switches the signal off, and the Minimal preset does not include it in the first place.
The stitch is also why fastmon gets by without sessions. A real session ID would be more precise: it knows about inactivity, survives an IP change and separates visitors behind the same office IP. But it has to be stored on the device, and that is where the consent requirement begins. Percentiles need no identity at all, and for visitor counting the stitch is precise enough: shared IPs merge into one visitor, a changing IP counts twice, the absolute number carries a small blur while the trends stay stable. So we advise against sessions unless you genuinely need them. Only the Full preset writes a session ID, and there consent is part of the deal.
What we do not claim
That the question is settled for you. Our assessment covers our architecture, not your deployment. Which preset you run, how specific your paths are and how many visitors you have all feed into it. That assessment stays with you, and the legal position can change.
If you gate it anyway
What an opt-out costs you.
Some operators put fastmon behind consent regardless, out of caution or because they run Full mode. Even then you are better off than with cookie-based tools: there every opt-out additionally costs the recognition, with us only sample size.
With fastmon
- If a visitor declines, nothing is measured for that visit, exactly as it should be
- The sample gets smaller, the distribution stays intact. For percentiles such as the p75 that is the decisive point
- No double-counted users, no orphaned sessions, because there is no long-lived recognition that could break in the first place
- So your numbers get smaller, not skewed, whatever your opt-out rate happens to be
With cookie-based tools
- Every opt-out additionally costs the recognition the user counts are built on
- Returning visitors turn into new visitors and unique counts drift upwards
- Sessions break mid-funnel and reappear as new ones
- The distortion grows with the opt-out rate and cannot be corrected after the fact
Residual risk
A game of cat and mouse, said out loud.
The history of web tracking is a chain of technique and ruling. First people simply measured. Then courts required an opt-out in the privacy policy. Then a notice banner. Then „by continuing to browse you agree“ was struck down. Then came the consent banner we know today.
We assume requirements will keep tightening. So we build such that a tightening does not catch us out: the beacon can be pushed entirely behind a consent gate, the presets turned down, and the data basis is narrow enough to still carry after a tightening.
Residual risk remains regardless, with any tool. Anyone running modern IT accepts it in several places at once, usually without discussing it: standard contractual clauses for US services, transfer impact assessments whose basis can change, office suites no company is switching off tomorrow. The honest question is not whether you carry residual risk, but which, how large, and whether you carried it knowingly.
Our contribution to that is traceability. No provider under US jurisdiction in the data path, so the transfer question never arises with us. Raw data that never reaches the application. And a page like this one, which prints the opposing reading in full.
How the standard has shifted
- Stage 1
Measurement simply happened, with no notice to the visitor
- Stage 2
Opt-out in the privacy policy, required by court ruling
- Stage 3
Notice banner along the lines of „by continuing you agree“
- Stage 4
That construction struck down, a real consent banner required
- Stage 5
Dispute over what counts as access to the device. This is where we are
- Stage 6
Open. Our assessment is one reading; the stricter one exists alongside it
What you should do
Six steps and it is documented.
Not rocket science, but it has to be done and evidenced. Preferably in this order.
- 01
Choose the preset deliberately
Minimal and Standard stay write-free. Full writes an identifier and then needs consent. That is the real lever; everything else follows from it.
- 02
Put fastmon in your privacy policy
Vendor, purpose, legal basis (Art. 6(1)(f)), retention and recipients. In Minimal and Standard this is the step that replaces the banner.
- 03
Gate Full mode behind consent
Via your consent management platform or via grantConsent(), so the identifier is only written after opt-in. Category statistics, not „strictly necessary“.
- 04
Assess relatability for your case
How specific are your paths, how many visitors do you have per path and country? Document the result. This is the part nobody can do for you.
- 05
Keep personal data out of collectable fields
Not in URL paths, query strings, UTM parameters, tag values or error contexts. Customer numbers, names and email addresses do not belong in a URL that gets measured.
- 06
Set retention to your own measure
90 days is the default, shorter is configurable. Longer only where you can justify why you need the data for that long.
Interactive check
Do you need a banner? Three questions.
Three questions in the order a data protection officer would ask them: what happens on the device first, then what your web addresses reveal, then how many people are behind them.
The three possible outcomes
No banner needed
In our assessment you need no consent: nothing is stored on the device, the values read only come into being during the page view, and your data does not give rise to a personal reference. What takes the place of the banner is naming fastmon in your privacy policy.
- Add fastmon to your privacy policy: vendor, purpose, legal basis Art. 6(1)(f), retention, recipients
- Document the outcome of this assessment so you can justify it later
- Keep personal data out of URL paths, query strings and UTM parameters
Consent required
The Full preset writes a tab-bound session ID into sessionStorage. A write to the device is uncontroversially covered by § 25(1) TDDDG, and the exemptions in subsection 2 do not carry a performance measurement. Either you collect consent, or you switch to Standard.
- Add fastmon to your consent management platform, category statistics, not „strictly necessary“
- Load the beacon only after opt-in, or set session_consent to deferred and call grantConsent() once consent is given
- Alternatively switch to the Standard preset, which removes the write entirely
Borderline, assess it yourself
Under § 25 TDDDG you need no consent in our assessment, because nothing is stored on the device. The GDPR question is open in your case, though: with speaking paths or few visitors the sum of attributes can converge on a single person. That assessment sits with you; we cannot make it for you.
- Defuse speaking paths: get IDs and names out of the URL, or switch collect_query_keys off
- Switch store_stitch off, and the stored row carries no visitor signal at all
- If doubt remains: put fastmon behind consent and list it as statistics in your CMP
- Document the assessment together with your data protection officer
This outcome is our view based on what you told us, and it is not legal advice. Have it confirmed by your data protection officer or a lawyer before you go live. Responsibility for the integration remains with you as the operator of the website.
The evaluation runs entirely in your browser. We learn neither your answers nor your result.
The asterisk
What the asterisk in our footer means.
Every page carries an asterisk after „no cookies“. That asterisk is the short version of everything above. Here is the long version, sentence by sentence.
- „In Minimal and Standard mode fastmon sets no cookie and stores nothing on the device“ means what exactly?
- That in these two modes no cookie is set and nothing is written, neither localStorage nor sessionStorage. The write path is not contained in the shipped script; it is removed at build time. That is verifiable, not merely promised.
- „What it reads are status values the browser generates at runtime“ means what exactly?
- That the values read were nowhere in the device before the page view. Timings come into being during page load, the window width is the current state, the connection class a running estimate. In our assessment that is not access to stored information within the meaning of § 25 TDDDG. The stricter opposing view is printed in full above.
- „Full mode writes an identifier“ means what exactly?
- That Full stores a tab-bound session ID in sessionStorage._fms, which expires when the tab closes. That is a write, and for it you need consent. Minimal and Standard do not do it.
FAQ
Cookie banners and consent, answered.
The questions a data protection officer asks first, with the answers we give even when they are inconvenient.
If I do use a banner: does fastmon have to be named in it?
A specific product name is not mandatory. What is mandatory is that it be clear which data is processed for which purpose by whom, and how long it is kept. Those are the ordinary requirements for consent. In practice, naming the vendor is the simplest way to meet them, and it helps you with the information duties under Art. 13 and 14 GDPR at the same time.
Why is „we set no cookies“ not sufficient as reasoning?
Because § 25 TDDDG names two acts: storing in the device, and accessing what is already stored there. Per the EDPB the two need not both be present. Setting no cookie settles the first. The second has to be assessed on its own, and that assessment is exactly what most vendors skip when they argue from cookie-freeness.
We process no personal data. Does that count for § 25?
No. The German Data Protection Conference states expressly that § 25 applies irrespective of personal data; the provision protects the device, not the data. For § 25 all that matters is whether there is storing, or access to something stored. Personal data decides the second, separate question under the GDPR.
What exactly does the beacon read from the browser?
The Performance API for LCP, INP, CLS, TTFB and the timings, the window width as one of six classes, the connection class, the referrer, the page URL, plus error type and count. All of these come into being at the moment of the page view; none was in the device beforehand. We never call navigator.userAgent, and the IP and user agent reach us only as HTTP headers.
The stricter view exists. Why do you not follow it?
Because the German statutory text requires information already stored in the terminal equipment, and runtime values are not that. The EDPB's stricter reading includes locally generated results of a browser API; we print it in full above, because it is defensible. Should it prevail, our recommendation changes, and the beacon can be pushed entirely behind a consent gate.
Is reading the window width not fingerprinting?
That is exactly where the line runs, which is why we transmit no pixel value but one of six classes. Combined with country, browser family and device class the entropy stays low enough that recognition is practically ruled out. No canvas, no font enumeration, no sensors, no audio.
And the stitch?
It comes into being at the edge, not in the browser, so it is not a § 25 question but a GDPR one. We treat it as personal data and rest it on the legitimate-interest basis in Art. 6(1)(f). HMAC-SHA256, the salt rotates every 24 hours and never leaves the edge's memory, different per domain, not reversible. It stays borderline regardless: with highly specific paths a personal reference can arise. store_stitch=false switches it off.
Why does the GDPR apply at all if the values are anonymous?
Because of the IP address. It travels in the HTTP header of every request even though we never query it, and under the CJEU's Breyer ruling it is personal data. The legal basis is the legitimate-interest balance in Art. 6(1)(f), and it holds because the IP and user agent are processed only to receive the request and discarded in under a second.
What happens to my numbers if I do put fastmon behind consent?
They get smaller, not skewed. fastmon measures aggregated field performance from a sample, and a smaller sample stays meaningful as long as it is not systematically distorted. Because no long-lived recognition exists anyway, no sessions break and no unique counts drift. With cookie-based tools every opt-out additionally costs you the recognition.
Do you need a data processing agreement?
If personal data is processed in your deployment, yes, then we are a processor under Art. 28 GDPR. The agreement is concluded on registration and is publicly available. Because the IP in the header means personal data is involved in any case, we conclude it either way.
Do I have to name fastmon in my privacy policy?
Yes, and in Minimal and Standard that is the step which takes the place of the banner. It should carry vendor, purpose, legal basis under Art. 6(1)(f), retention and recipients. The information duties under Art. 13 and 14 GDPR apply as soon as personal data is processed, and via the IP in the header that is the case.
How long may I retain the data?
Delete once it is no longer needed for the purpose and no statutory retention duty stands in the way. How long that is, you have to justify, and it depends on your case. In fastmon 90 days is the default, shorter is configurable, up to 13 months on Enterprise plans.
What if a court sees this differently later?
We expect it to, and the history above shows why. That is why nothing about fastmon depends on today's reading holding: the beacon can be pushed entirely behind a consent gate, the presets turned down, and the data basis is narrow enough to still carry. What would change is our recommendation, not your setup.
Is this legal advice?
No. This page describes how fastmon is built and how we read the legal position, reviewed with our external data protection officer. The assessment for your deployment is yours to make, ideally with your own data protection officer.
Not legal advice. This page reflects the state of our own assessment, reviewed with our external data protection officer, and describes how fastmon is built and documented. No court has ruled on this constellation; a residual risk remains. The legal position and supervisory practice change, and assessing your concrete deployment is your responsibility as controller. The binding documents are Privacy and Data Processing Agreement.
100% EU,
hosted in Germany.
No Cloudflare, no AWS, no GCP. Read-only by default: no cookies*, no long-lived identifiers.
Light
€29/month
200,000 pageviews included.
Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans