If Umami sets no cookies, is a consent banner still needed?

Setting no cookies satisfies a necessary condition, not a sufficient one. In the EDPB guidelines describing the technical scope of ePrivacy 5(3), what matters is the accessing party instructing the visitor's terminal equipment to send information back. The default tracker sends screen size and browser language with every event, which puts those fields in scope. The same setup lands somewhere far more defensible once the payload is cleaned before transmission. This is a technical account of what the setup transmits, not a legal opinion.

Does `data-auto-track="false"` stop the device read?

It does not. The tracker is an IIFE and its first statement reads screen size and browser language; the settings on the script tag are parsed after that read. The setting only turns off automatic events. The read itself cannot be blocked through the script tag, but the transmission can be, and the legal threshold sits at transmission anyway.

Why should decision events not go through the tracker?

Two reasons. First the payload: a call in the form `umami.track('name')` merges the default body, so device fields travel with it. Second the dependency: if the tracker has not loaded, the decision event is never sent. The day the loader tag gets a consent condition, the decisions of visitors who reject drop out of the data set and the acceptance rate reads one hundred percent. Writing the decision event straight to the collect endpoint solves both problems at once.

Where should segment information go instead of onto every event?

Fields that stay constant through a session belong to a session property. On the Umami side that is written with a `umami.identify()` call, and when the object argument carries no identity field, no identity is assigned to the visitor. A segment object attached to every event both inflates quota consumption by the number of events and stores the same information over and over. Add an identity field and the picture changes: at that point the setup is doing identified measurement.

How does turning on session replay change the setup?

Completely. Replay is a separate script and is not part of the default tracker; it loads only when it is enabled for that site. Once it runs, DOM mutations, clicks, scrolling and input events on the page are recorded in order. Input values arrive masked at both masking levels, so the default risk is not in form values but in the visible page text entering the recording at the moderate level. A setup used as a decision layer should keep replay off.

How do I verify the setup actually works?

In three layers. Reading the tag manager's published container file to see that the code is genuinely live, taking a network recording in the browser and checking field by field what the sent body contains, and looking at the status codes of both the preflight and the actual request. A success mark in the tag manager only shows that the code ran, not that the request was accepted.

Setting Up Umami with GTM in a Consent Compliant Way: The Transmission Threshold, the Decision Layer and the Replay Call

Using a cookieless tool does not by itself mean consent is unnecessary, because the threshold is not cookie usage but what leaves the device. What the tracker reads, what each setup transmits, how the decision tag runs without depending on the tracker, and where the replay call changes the picture.

TL;DR

Whether a cookieless tool needs consent is decided by what it sends from the device, not by whether it sets a cookie. The Umami tracker reads screen size and browser language the moment it loads, and the script tag settings are parsed only after that read. The read cannot be blocked, the transmission can: the payload is cleaned before sending, and the decision tag writes straight to the collect endpoint.

Create Free Account Sign In