Spoiler: „Server-Side“ macht dich nicht automatisch legal. Und „Consent Mode“ ist kein DSGVO-Freifahrtschein. Hier ist der pragmatische Weg: messen, ohne dich juristisch oder technisch zu zerlegen.
Tracking ist 2026 ein Spagat: Business will Zahlen, Privacy will Kontrolle, und du willst einfach, dass es sauber läuft – ohne Banner-Zirkus, ohne Abmahn-Panik.
Die Kernfrage ist nicht „welches Tool“, sondern: Welche Daten brauchst du wirklich? Und: Welche Daten darfst du ohne Einwilligung überhaupt anfassen?
Wir schauen uns drei Wege an: Consent Mode (Google), Server-Side Tracking (z.B. GTM Server Container) und Alternativen (Logfiles, datensparsame Analytics).
- Consent Mode = Signal an Google-Tags, wie sie sich bei Consent verhalten. Kein Ersatz für CMP/Einwilligung.
- Server-Side Tracking = bessere Kontrolle & Datenqualität möglich, aber Consent-Pflichten bleiben, wenn du Endgerätezugriffe/IDs nutzt.
- Wenn du „ohne Consent“ messen willst: in DE ist Logfile-Analytics der sauberste Minimalweg (sehr eingeschränkt, aber oft genug für Basics).
- Die häufigste Falle: Tags feuern vor Consent → Banner ist dann Deko, Risiko hoch.
- Pragmatischer Sweet Spot: CMP + saubere Consent-Signale + stark reduzierte Tags + minimalistische KPIs.
Rechts-Basics ohne Juristen-Deutsch (DACH/DE-Fokus)
Es gibt zwei Ebenen, die du auseinanderhalten musst:
- Endgerätezugriff (ePrivacy/DE: § 25 TDDDG): Speichern oder Auslesen von Infos auf dem Gerät braucht grundsätzlich Einwilligung – außer es ist „unbedingt erforderlich“. Die Datenschutzkonferenz (DSK) beschreibt das in der Orientierungshilfe zu digitalen Diensten.
- DSGVO: Sobald personenbezogene Daten verarbeitet werden (Tracking ist praktisch fast immer dabei), brauchst du eine passende Rechtsgrundlage. Für viele Tracking-Setups ist das Einwilligung. Anforderungen an Einwilligung (freiwillig, informiert, eindeutig, widerrufbar) sind in den EDPB-Guidelines zusammengefasst.
Und ja: Der BfDI hat z.B. beim „Zählpixel“ sehr klar formuliert, dass der Zugriff auf die Endeinrichtung nach § 25 TDDDG eine Einwilligung erfordert und dabei regelmäßig personenbezogene Daten anfallen (DSGVO also mit im Boot).
Consent Mode: was es ist (und was nicht)
Consent Mode ist eine Google-Mechanik: Du übergibst Consent-Zustände, und Google-Tags passen ihr Verhalten an. Das ist vor allem relevant für EEA-Traffic und Google-Produkte (Ads/Analytics/Tagging).
Google hat dafür Updates kommuniziert (u.a. zusätzliche Consent-Signale in v2). Die Kernbotschaft aus den Google-Help-Docs: Wenn du Google-Tags in der EEA nutzt, sollst du die Endnutzer-Consent-Choices an Google weiterreichen.
Was Consent Mode NICHT ist
- Keine CMP: Consent Mode sammelt nicht automatisch eine gültige Einwilligung. Dafür brauchst du ein Consent-Banner/CMP, das sauber fragt.
- Keine DSGVO-Zauberei: „Ich hab Consent Mode, also bin ich compliant“ ist Wunschdenken. Die Einwilligung muss trotzdem die DSGVO-Anforderungen erfüllen.
- Keine Ausrede für Dark Patterns: Ablehnen muss leicht sein wie Akzeptieren – das ist auch regulatorisch im Fokus (z.B. CNIL).
Server-Side Tracking: kann viel – aber löst Consent nicht automatisch
Server-Side Tagging (z.B. GTM Server Container) verschiebt Teile des Taggings von der Browser-Seite auf deinen Server. Google beschreibt das als Ansatz, um Messung „serverseitig“ zu instrumentieren und u.a. Performance/Privacy-Kontrolle zu verbessern.
Was Server-Side dir реально bringt
- Kontrolle: Du entscheidest zentral, welche Requests an welche Vendoren gehen.
- Datenqualität: Du kannst Ereignisse normalisieren, filtern und konsistenter senden.
- Performance: Weniger Third-Party im Browser kann die Seite spürbar entlasten (aber nur, wenn du wirklich reduzierst).
Was Server-Side NICHT automatisch löst
- Consent-Pflicht: Wenn du weiterhin Endgerätezugriffe nutzt (Cookies/IDs/LocalStorage) oder personenbezogene Daten verarbeitest, bleibst du in der DSGVO/TDDDG-Welt.
- Transparenz: „Wir machen das serverseitig“ muss trotzdem in Datenschutzinfo/Consent sauber erklärt werden.
- Risiko-Illusion: Server-Side kann sich sogar riskanter anfühlen, wenn dadurch mehr Daten zusammenlaufen. Da zählt Datenminimierung.
Alternativen: Was ist sinnvoll, wenn du weniger Stress willst?
1) Logfile-Analytics (Minimal-Messung, oft der cleanste Weg ohne Consent)
Wenn du wirklich „ohne Einwilligung“ messen willst, ist der robusteste Ansatz oft: Server-Logs auswerten. Das ist funktional begrenzt, aber liefert dir Basics wie Requests, Statuscodes, Top-Pages, Referrer-Trends – ohne im Browser zu speichern/auszulesen.
Matomo selbst nennt Log Analytics bzw. serverseitige Methoden als Weg, der nicht auf den Zugriff auf die Endeinrichtung angewiesen ist (und ordnet das für Deutschland als klarer außerhalb der TDDDG-Scope ein als clientseitige Varianten).
2) „Privacy-first“ Analytics (mit Consent – aber weniger Vendor-Zirkus)
Wenn du aussagekräftigere Metriken brauchst (Funnel, Events) und Consent sowieso einholst: dann kann ein datensparsames Setup sinnvoll sein. Wichtig ist weniger das Tool-Logo, mehr diese Punkte:
- Tag-Diät: wirklich nur messen, was Entscheidungen beeinflusst
- Purpose sauber: Statistik klar getrennt von Marketing
- Widerruf easy: Consent jederzeit änderbar (EDPB-Logik)
- Third-Party minimal: weniger externe Calls = weniger Risiko/Overhead
Und: Bei cookieless/consent-exempt Behauptungen extrem vorsichtig sein – gerade in Deutschland ist die Linie oft strenger.
3) „KPIs ohne Tracking“ (unterschätzt)
Du kannst verdammt viel steuern, ohne jeden Nutzer zu verfolgen:
- Search Console (Impressions/Clicks/Queries)
- Server-Logs (Traffic-Muster, Fehler, Bots)
- Conversion-Zahlen aus deinem System (Bestellungen/Leads) ohne Nutzerprofiling
Das ist nicht fancy, aber extrem robust – und spart Consent-Drama.
Vergleich: Consent Mode vs Server-Side vs Alternativen
| Ansatz | Wofür gut | Consent/Legal-Aufwand | Aufwand/Komplexität | Risiko-Fallen |
|---|---|---|---|---|
| CMP + Consent Mode (Google Tags) | Google Ads/GA/Measurement in EEA sauber steuern | hoch (Consent muss gültig sein) | mittel | „Tags feuern vor Consent“, falsche Zwecke, Dark Patterns |
| Server-Side Tagging | Kontrolle/Datenqualität/Performance, weniger Browser-Chaos | mittel–hoch (je nach IDs/Endgerätezugriff) | hoch | „server-side = legal“, Datenzusammenführung, Intransparenz |
| Client-side Analytics mit Consent | Events/Funnel schnell umsetzbar | hoch | niedrig–mittel | Vendor-Wildwuchs, CLS/INP-Schäden, Consent-Widerruf vergessen |
| Logfile-Analytics | Basis-KPIs ohne Browser-Tracking | niedrig–mittel (trotzdem DSGVO-Basics beachten) | mittel | Erwartungen: keine User-Journeys, keine sauberen Events |
So setzt du’s um: 90-Minuten-Plan (praxisnah)
So setzt du’s um
- Mess-Ziel definieren: Welche 3 Entscheidungen willst du mit Daten treffen? (Alles andere raus.)
- Tag-Inventur: Liste aller Tags/Embeds/Third-Party. Owner & Zweck dazu.
- CMP sauber: echte Wahl, Reject nicht verstecken, Widerruf-Link dauerhaft.
- Consent-Signale: Wenn Google-Tags: Consent Mode korrekt anbinden.
- Blocken prüfen: Vor Consent dürfen keine Marketing/Analytics-Tags laufen (Netzwerk-Check).
- Plan B: Wenn du ohne Consent messen willst: Logfile-Analytics aufsetzen (minimal, aber robust).
Mini-Use-Case: „Wir brauchen Conversion-Tracking, aber sauber“
- Nur 1–2 essentielle Tags (nicht 12)
- Consent Mode nur, wenn Google-Tags wirklich genutzt werden
- Server-Side nur, wenn du echten Mehrwert hast (z.B. Datenqualität/Tag-Reduktion), nicht als Placebo
Typische Fehler & wie du sie vermeidest
- Fehler: Consent Mode eingebaut, aber keine gültige Einwilligung. Fix: CMP/Consent sauber nach EDPB-Logik (freiwillig, informiert, eindeutig, widerrufbar).
- Fehler: Tags feuern trotzdem vor Consent (Tag Manager, Embeds, iframes). Fix: technische Blockade prüfen (Netzwerk/Storage), Trigger-Logik konsequent.
- Fehler: „Server-Side = kein Consent“. Fix: Prüfen, ob Endgerätezugriff/IDs/Profiling stattfindet (TDDDG/DSGVO bleiben relevant).
- Fehler: Zu viele Zwecke in einem Schalter. Fix: Zwecke trennen (Statistik vs Marketing) und verständlich erklären.
- Fehler: Widerruf fehlt/ist versteckt. Fix: „Cookie-Einstellungen“ dauerhaft erreichbar (Footer reicht oft).
Fazit: Sinnvoll ist, was du erklären, begrenzen und technisch durchziehen kannst
Consent Mode ist sinnvoll, wenn du Google-Tags nutzt und Consent sauber einsammelst. Server-Side ist sinnvoll, wenn du damit wirklich reduzierst und Kontrolle gewinnst – nicht als Legal-Schminke. Und wenn du Stress minimieren willst: Logfile-Analytics + datensparsame KPIs sind oft der unterschätzte Sweet Spot.
Nächster Schritt: Mach eine Tag-Inventur und streich die Hälfte. Dann baust du Consent/Signale sauber – und erst dann diskutierst du Server-Side.
FAQ
Consent Mode ist ein technisches Steuerungs-Framework für Google-Tags. DSGVO-konform wird dein Setup nur, wenn du eine gültige Einwilligung einholst und korrekt umsetzt (inkl. Widerruf). Consent Mode ersetzt keine CMP.
Nein. Wenn du Endgerätezugriff/IDs/Profiling nutzt, bleibt §25 TDDDG/DSGVO relevant. Server-Side ist eine Architekturentscheidung, keine automatische Rechtsgrundlage.
Viele Analytics-Setups greifen auf Endgeräte zu (Cookies/IDs) und landen damit in §25 TDDDG. Für „ohne Consent“-Basics ist Logfile-Analytics oft der pragmatischste Weg.
CMP sammelt Consent (UI, Protokoll, Widerruf). Consent Mode ist die technische Weitergabe/Anwendung von Consent-Signalen für Google-Tags. Beides hat unterschiedliche Jobs.
„Ohne Cookies“ heißt nicht automatisch „ohne Endgerätezugriff“ oder „ohne personenbezogene Daten“. In DE ist Logfile-Analytics oft der klarste Minimalweg. Für alles, was Nutzer wiedererkennt oder Profile baut, wird’s schnell consent-relevant.
Dark Patterns im Banner, Tags vor Consent, fehlender Widerruf, „alles ist notwendig“, und Intransparenz bei Drittanbietern/Zwecken. Das sind die Klassiker, die Aufsichtsbehörden immer wieder kritisieren.