Matomo statt Google Tag Manager: cookieless und ohne Banner

Im Dezember 2025 haben wir unsere Seiten mit dem Google Tag Manager ausgestattet, zuerst über Partytown in einen Worker ausgelagert, kurz darauf mit einem Cookie-Banner davor. Im Juni 2026 ist beides rausgeflogen. An seiner Stelle steht ein selbst gehostetes Matomo, das keine Cookies setzt.

Der Auslöser war nicht Ideologie, sondern eine schlichte Beobachtung: Das Banner war das erste, was jeder Besucher von uns zu sehen bekam. Eine Firma, die Software mit Hosting in Deutschland verkauft, sollte ihre eigene Reichweitenmessung so lösen können, dass sie niemanden um Erlaubnis fragen muss.

Warum das Banner überhaupt da war

Der Google Tag Manager selbst ist nur ein Ladeprogramm. Was er lädt, sind in der Regel Werkzeuge, die im Browser etwas ablegen und Daten an einen Dritten senden. Genau dafür verlangt § 25 TDDDG eine Einwilligung, und zwar bevor irgendetwas passiert. Daraus folgt die Kette, die man auf fast jeder Website sieht: Banner, Einwilligung, erst danach Messung.

Das hat zwei unangenehme Nebenwirkungen. Die erste ist der Sprung ins Gesicht des Besuchers. Die zweite ist, dass die Zahlen danach lückenhaft sind: Gemessen wird nur, wer zugestimmt hat. Wie groß diese Lücke ist, weiß man nicht, weil man ja gerade die nicht misst, die abgelehnt haben.

Was wir stattdessen machen

Matomo läuft bei uns selbst gehostet, und das Snippet setzt zwei Schalter, bevor irgendetwas geladen wird:

_paq.push(['disableCookies'])
_paq.push(['setDoNotTrack', true])

disableCookies heißt: Matomo legt nichts im Browser ab, weder Cookie noch Local Storage. Damit ist der Tatbestand aus § 25 TDDDG nicht erfüllt, und die Einwilligung entfällt. setDoNotTrack respektiert zusätzlich das Do-Not-Track-Signal des Browsers. Dazu kommt die IP-Anonymisierung in den Matomo-Einstellungen, die dort ohnehin Voreinstellung ist.

Das Ergebnis: kein Banner mehr, keine _pk_*-Cookies, keine Daten an einen Dritten. Die Messung läuft auf unserer eigenen Infrastruktur, und die Datenschutzerklärung wurde dabei deutlich kürzer.

Was wir dafür aufgeben

Das ist der Teil, den solche Artikel meistens weglassen. Ohne Cookies kann Matomo einen wiederkehrenden Besucher nicht sicher wiedererkennen. Es bildet stattdessen aus Merkmalen wie Browser, Betriebssystem und Auflösung eine Kennung, die einen Tag hält. Praktisch heißt das:

• Wiederkehrende Besucher sind unzuverlässig. Wer heute und übermorgen kommt, zählt zweimal.
• Besuchsdauern über Tagesgrenzen hinweg gibt es nicht.
• Attribution über mehrere Sitzungen funktioniert nicht. Wer über LinkedIn kommt, eine Woche später direkt zurückkommt und dann das Kontaktformular ausfüllt, erscheint als zwei unverbundene Besuche.

Für ein Werbekonto, das Kampagnen auf Conversions optimiert, wäre das ein echter Verlust. Für uns nicht. Wir wollen wissen, welche Seiten gelesen werden, woher die Leute kommen und wo sie abbrechen. Dafür reichen tagesgenaue Zahlen, und sie sind vollständig statt eingewilligt.

Der Umbau selbst

Technisch war es weniger Arbeit als erwartet. Die Astro-Seiten lesen MATOMO_URL und MATOMO_SITE_ID aus Umgebungsvariablen. Sind beide nicht gesetzt, lädt Matomo gar nicht, und die Seite funktioniert unverändert – praktisch für lokale Builds. Zum Testen steht eine Docker-Compose-Instanz aus Matomo und MariaDB im Repo, die man mit docker compose up -d startet und gegen den Dev-Server laufen lässt.

Eine Falle hat uns dabei einen halben Tag gekostet, und sie hat nichts mit Matomo zu tun. Das Snippet stand zuerst in einem JSX-Ausdruck, also in der Form {BEDINGUNG && (<script>…</script>)}. Prettier behandelt den Script-Inhalt dort als JSX-Text und bricht die Zeilen um wie Fließtext. Da unser Code ohne Semikolons geschrieben ist, entsteht dabei ungültiges JavaScript – und ein Script, das still ausfällt, ohne dass irgendwo ein Fehler auftaucht. prettier-ignore hilft an dieser Stelle nicht. Die Lösung ist eine eigene Komponente, deren <script> auf Template-Ebene steht; dort lässt Prettier den Inhalt in Ruhe. Das Muster steckt seither in jeder unserer Seiten.

Ausgerollt haben wir in zwei Wellen: zuerst die Produktseiten, zwei Wochen später die ZeitFabrik-Seite, die bis dahin noch auf GTM lief. Heute hängen sieben Seiten an derselben Instanz, jede mit eigener Site-ID.

Was danach noch dazukam

Wenn die Messung auf eigener Infrastruktur läuft, wird sie erweiterbar. Im August haben wir Video-Plays als Matomo-Events ergänzt: Jeder Start eines Videos auf einer unserer Seiten schlägt als Event auf, mit einem Label, das Video und Seite benennt. Damit lässt sich beantworten, welches Tutorial tatsächlich angesehen wird – eine Frage, die uns der Videohoster so nicht beantwortet, weil er die Plays seiner eingebetteten Player zählt und nicht unsere.

Dazu kommt, dass die Zahlen per API abrufbar sind. Die Auswertungen, die wir uns sonst aus einer Oberfläche zusammenklicken müssten, laufen als Skript.

Würden wir es wieder so machen

Ja, mit einer Einschränkung: Wer Werbung schaltet und auf Conversions optimiert, wird um wiedererkennbare Besucher nicht herumkommen und muss die Einwilligung dann eben einholen. Wer wie wir vor allem wissen will, ob die eigenen Inhalte gelesen werden, gibt mit den Cookies wenig auf und bekommt dafür einen Auftritt ohne Türsteher, eine kürzere Datenschutzerklärung und Zahlen, die nicht von einer Zustimmungsquote abhängen.

Der Betrieb kostet uns einen Container und eine Datenbank. Das ist der ganze Preis.