DSGVO-konforme Analytics ohne Third-Party-Cookies

Letzten Monat haben Sie ein Redesign der Landing Page veröffentlicht. Die Conversions scheinen gestiegen zu sein – zumindest sagt das Ihr Bauchgefühl. Aber Ihr Google-Analytics-Dashboard zeigt eine Ablehnungsrate von 35 % beim Consent, und Sie sehen Daten von weniger als zwei Dritteln Ihrer Besucher. Hat das Redesign funktioniert? Sie können es schlicht nicht sagen.

Das ist der Stand der Analytics für europäische SaaS-Produkte im Jahr 2026. DSGVO und ePrivacy-Richtlinie haben den Standard-Third-Party-Analytics-Stack – Google Analytics mit Cookie-Consent-Bannern – sowohl rechtlich riskant als auch praktisch unzuverlässig gemacht. Eine Consent-Ablehnungsrate über 30 % ist für europäisches Publikum typisch, was bedeutet, dass Sie Produkt- und Marketingentscheidungen auf Basis einer systematisch verzerrten Stichprobe Ihrer Nutzer treffen.

Die Antwort besteht nicht darin, einen cleveren Weg zu finden, Menschen ohne ihr Wissen zu tracken. Die Antwort ist, ein Analytics-Setup aufzubauen, das gar keinen Consent erfordert – weil es in einem rechtlich relevanten Sinne keine personenbezogenen Daten verwendet. Dieser Beitrag erklärt, wie das geht.

Warum Consent-basierte Analytics ein kaputtes Fundament ist

Der Consent-Wall-Ansatz bei Analytics hat zwei Probleme, die sich gegenseitig verstärken.

Das erste ist rechtliches Risiko. Unter der DSGVO ist ein Consent-Banner nur dann gültig, wenn die „Nein"-Option genauso einfach zu wählen ist wie „Ja", wenn Consent freiwillig ohne Bedingungen gegeben wird und wenn eine Ablehnung das Nutzererlebnis nicht verschlechtert. Die meisten Consent-Implementierungen erfüllen mindestens eine dieser Anforderungen nicht. Durchsetzungsmaßnahmen europäischer Datenschutzbehörden haben von Jahr zu Jahr deutlich zugenommen – und Regulatoren zielen jetzt gezielt auf Unternehmen ab, die Dark Patterns in der Consent-UI verwenden.

Das zweite ist Datenqualität. Selbst mit einer perfekt konformen Consent-Implementierung sind Nutzer, die das Analytics-Tracking ablehnen, keine zufällige Stichprobe Ihres Publikums. Datenschutzbewusste Nutzer sind tendenziell technisch versierter, nutzen unabhängig vom Consent eher Ad-Blocker, und sind in manchen Branchen (FinTech, Healthcare, Legal) wahrscheinlicher Ihre wertvollsten Kunden. Sie sind systematisch blind für ein nicht-zufälliges Segment Ihres Publikums.

Die saubere Alternative ist, die Schwelle personenbezogener Daten komplett zu vermeiden. Die DSGVO gilt für die Verarbeitung personenbezogener Daten, also Informationen, die zur Identifizierung einer natürlichen Person genutzt werden können. Analytics, das Verhalten auf Session-Ebene aggregiert, ohne IP-Adressen zu speichern, ohne Cookies zu setzen, die über Sessions hinweg bestehen, und ohne Verhalten mit identifizierbaren Nutzerprofilen zu verknüpfen, fällt unterhalb dieser Schwelle. Keine verarbeiteten personenbezogenen Daten bedeutet kein erforderlicher Consent.

Datenschutzfreundliche Analytics-Tools: Was sie wirklich bieten

Drei Tools dominieren den datenschutzfreundlichen Analytics-Bereich, jedes mit anderen Abwägungen, die es wert sind, verstanden zu werden, bevor Sie sich festlegen.

Plausible Analytics

Plausible ist die einfachste Option und am leichtesten gegenüber einem DSB oder Rechtsteam zu rechtfertigen. Es speichert keine personenbezogenen Daten, verwendet keine Cookies und ist von Grund auf für DSGVO-Konformität konzipiert. Traffic-Daten werden aggregiert; es gibt kein Session-Level-User-Tracking. Plausible kann auf EU-Infrastruktur selbst gehostet werden, was für Unternehmen wichtig ist, deren Kunden Datenspeicherung innerhalb Deutschlands oder der EU fordern.

Der Kompromiss ist eine bewusste Featurebeschränkung. Plausible zeigt keine individuellen User-Journeys, unterstützt keine Trichteranalysen auf Nutzerebene und bietet im Vergleich zu GA4 begrenzte Event-Filterung. Für Produkt-Analytics – zu verstehen, wie spezifische Nutzer Ihre Anwendung navigieren – ist Plausible nicht das richtige Tool. Für Traffic-Analytics – zu verstehen, woher Ihre Besucher kommen, welche Seiten sie lesen und welche Kanäle konvertieren – ist es ausgezeichnet und schnell zu implementieren.

<!-- Plausible-Skript: kein Cookie, keine IP-Speicherung, kein Consent erforderlich -->
<script
  defer
  data-domain="yourapp.com"
  src="https://plausible.io/js/script.js">
</script>

Ein praktischer Vorteil: Da das Plausible-Skript keine Cookies setzt, wird es von den meisten Ad-Blocking-Erweiterungen, die Tracking-Skripte anvisieren, nicht blockiert. Sie erhalten vollständigere Traffic-Daten als mit Google Analytics, nicht weniger.

Umami

Umami ist eine Open-Source-Alternative, die Sie selbst hosten und Ihnen damit vollständige Datenkontrolle geben. Wie Plausible ist es cookielos und trackt keine personenbezogenen Daten. Das Self-hosted-Modell bedeutet, dass Ihre Analytics-Daten Ihre Infrastruktur nie verlassen – ein erheblicher Vorteil, wenn Sie Enterprise-Kunden mit Datenverarbeitungsverträgen haben, die das Teilen von Daten mit Dritten einschränken.

Umanis Event-Tracking ist etwas leistungsfähiger als Plausibles Basistier, und der Self-hosted-Ansatz eliminiert das Preismodell pro Seitenaufruf. Für eine Next.js-Anwendung fügt die Integration minimalen Overhead hinzu:

// utils/analytics.ts — Umami Event-Tracking-Wrapper
export function trackEvent(eventName: string, eventData?: Record<string, string | number>) {
  if (typeof window !== 'undefined' && (window as any).umami) {
    (window as any).umami.track(eventName, eventData);
  }
}

// Verwendung in einer Komponente
import { trackEvent } from '@/utils/analytics';

function PricingPage() {
  const handlePlanSelect = (planId: string) => {
    trackEvent('plan_selected', { plan: planId });
    // ... Rest des Handlers
  };
}

Da Umami Open Source und selbst gehostet ist, können Sie genau auditieren, welche Daten es speichert. Diese Auditierbarkeit hat Wert, wenn das Rechtsteam eines Kunden Fragen stellt.

Matomo (Self-Hosted)

Matomo nimmt eine andere Position ein: Es ist eine vollwertige Analytics-Plattform mit Fähigkeiten, die GA4 annähern, kann aber durch sorgfältige Einstellungen für DSGVO-Konformität konfiguriert werden. Die entscheidenden Konfigurationsentscheidungen sind das vollständige Deaktivieren von Cookie-Tracking (disableCookies()), die Aktivierung von IP-Anonymisierung und das Festlegen kurzer Datenaufbewahrungsfristen.

Matomos Vorteil ist die Tiefe: Trichteranalyse, Heatmaps, Session-Recordings mit Datenschutzfilterung und A/B-Testing – alles Features, die datenschutzfreundliche Tools wie Plausible opfern. Wenn Sie Analytics-Tiefe neben DSGVO-Konformität benötigen, ist Matomo selbst gehostet mit richtiger Konfiguration der praktikabelste Weg.

Die Vorsicht ist, dass Matomo auf nicht DSGVO-konforme Weisen konfiguriert werden kann. Die Standardinstallation speichert vollständige IP-Adressen und verwendet persistente Cookies. Matomo ohne explizite DSGVO-Konfiguration zu deployen verfehlt den Zweck. Dokumentieren Sie Ihre Konfigurationsentscheidungen und überprüfen Sie sie, wenn Matomo Updates veröffentlicht, die Standardeinstellungen ändern.

Serverseitiges Tracking: Die zuverlässigere Alternative

Clientseitige Analytics-Skripte stehen vor zwei strukturellen Problemen, die serverseitiges Tracking eliminiert: Ad-Blocker und Consent-Ablehnung. Keines davon betrifft Anfragen von Ihrem Server.

Der Ansatz ist unkompliziert. Anstatt sich auf ein JavaScript-Snippet im Browser zu verlassen, senden Sie Analytics-Events von Ihrem Anwendungsserver, wenn bedeutsame Aktionen stattfinden. Ihr Server weiß bereits, wenn sich Nutzer registrieren, Käufe abschließen, Features aktivieren oder Fehler auftreten – er muss den Browser nicht fragen.

Für eine Next.js-Anwendung mit einem PHP/Symfony-API-Backend kann serverseitiges Event-Tracking so einfach sein wie ein Plausible-serverseitiger API-Aufruf:

// lib/server-analytics.ts (Next.js Server Action oder API-Route)
export async function trackServerEvent(
  event: string,
  url: string,
  referrer?: string
): Promise<void> {
  if (process.env.PLAUSIBLE_API_KEY && process.env.PLAUSIBLE_DOMAIN) {
    await fetch('https://plausible.io/api/event', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'User-Agent': 'server-side-tracker',
        'X-Forwarded-For': '0.0.0.0', // Echte IPs niemals weiterleiten
      },
      body: JSON.stringify({
        name: event,
        url: `https://${process.env.PLAUSIBLE_DOMAIN}${url}`,
        domain: process.env.PLAUSIBLE_DOMAIN,
        referrer: referrer ?? '',
      }),
    });
  }
}

In einem Symfony-Backend gilt dasselbe Muster für das Tracking von Conversion-Events:

// src/Service/AnalyticsService.php
class AnalyticsService
{
    public function __construct(
        private readonly HttpClientInterface $httpClient,
        private readonly string $plausibleDomain,
        private readonly string $plausibleApiKey,
    ) {}

    public function trackEvent(string $event, string $url): void
    {
        if (!$this->plausibleDomain) {
            return;
        }

        $this->httpClient->request('POST', 'https://plausible.io/api/event', [
            'headers' => [
                'Content-Type' => 'application/json',
                'User-Agent'   => 'server-side-tracker/1.0',
            ],
            'json' => [
                'name'   => $event,
                'url'    => 'https://' . $this->plausibleDomain . $url,
                'domain' => $this->plausibleDomain,
            ],
        ]);
    }
}

Serverseitige Events erfassen 100 % der bedeutsamen Conversions unabhängig von Browser-Einstellungen, Consent-Entscheidungen oder Ad-Blockern. Der Kompromiss ist, dass Sie passive Verhaltensdaten verlieren – Scroll-Tiefe, Verweildauer, Navigationspfade –, die clientseitige Skripte automatisch erfassen. Für die meisten SaaS-Produkte sind die Conversion-Events ohnehin das, was für Entscheidungen zählt.

Was ohne Consent gemessen werden kann

Das Verständnis der rechtlichen Grenze hilft Ihnen, Ihre Anwendung korrekt zu instrumentieren, anstatt übervorsichtig zu sein.

Traffic-Level-Analytics – Seitenaufrufe, Referrer-Quellen, Browser-Typ, Standort auf Länderebene – liegt im Allgemeinen unterhalb der Schwelle personenbezogener Daten, wenn es ohne Cookies und ohne Speicherung oder Kürzung von IP-Adressen auf Netzwerkebene verarbeitet wird. Das deckt den größten Teil dessen ab, was Marketing-Teams brauchen: Kanal-Attribution, Content-Performance und geografische Verteilung.

Das Verhalten authentifizierter Nutzer in Ihrer Anwendung ist eine andere Kategorie. Wenn ein eingeloggter Nutzer mit Ihrem Produkt interagiert, haben Sie bereits eine Rechtsgrundlage für die Verarbeitung seiner Daten (Vertragserfüllung, berechtigtes Interesse) und benötigen keinen separaten Consent-Mechanismus für Analytics seines In-Produkt-Verhaltens. Das Tracking, welche Features ein zahlender Kunde nutzt, wo er den Onboarding-Flow abbricht und welche Integrationen er aktiviert, ist legitimes First-Party-Analytics, das kein Cookie-Consent-Popup erfordert.

Der Graubereich ist anonymes Session-Tracking über Seiten hinweg – der Versuch, die vollständige Journey eines Besuchers vor der Anmeldung zu verstehen. Wenn Sie diesen Einblick ohne Consent möchten, müssen Sie wirklich sicher sein, dass Sessions nicht re-identifiziert werden können: keine IP-Speicherung, keine persistenten Identifier, keine geräteübergreifende Korrelation. Cookieloses Session-Tracking, das Fingerprinting oder probabilistische Identifikation verwendet, stellt nach den meisten EU-Regulatoreninterpretationen immer noch personenbezogene Datenverarbeitung dar.

Ihre Next.js-Anwendung korrekt instrumentieren

Ein praktisches Analytics-Setup für ein Next.js-SaaS-Produkt im Jahr 2026 kombiniert typischerweise drei Schichten.

Die erste Schicht ist ein datenschutzfreundliches Skript (Plausible oder Umami), das passive Traffic-Daten erfasst – Seitenaufrufe, Referrer, Gerätetypen – ohne Cookies oder personenbezogene Daten. Das läuft ohne Consent-Banner.

Die zweite Schicht ist serverseitiges Event-Tracking für Conversion-Meilensteine: Registrierungen, Trial-Aktivierungen, Feature-Completions und Zahlungs-Events. Diese werden von Ihrem Backend unabhängig vom Browser-Verhalten ausgelöst.

Die dritte Schicht ist First-Party-In-Produkt-Analytics für authentifizierte Nutzer, bei denen Sie eine vertragliche Grundlage haben und das Verhalten im Rahmen der Serviceleistung tracken. Das kann reichhaltigere Instrumentierung nutzen, da Consent nicht die Rechtsgrundlage ist – berechtigtes Interesse oder Vertragserfüllung ist es.

Was das ersetzt, ist der Third-Party-Cookie-Stack: GA4, Facebook Pixel, Intercom-Tracking und ähnliche Tools, die persistente Cross-Site-Cookies setzen, Consent erfordern und die Verhaltensdaten Ihrer Nutzer an externe Plattformen zur Aggregation senden. Das Entfernen dieser Tools verbessert auch die Ladeleistung Ihrer Anwendung – der Consent-Banner und seine unterstützenden Skripte sind typischerweise 50–150 KB JavaScript, die Ihren initialen Seitenaufbau verlangsamen.

Die Architekturentscheidung, die das erfordert

Die Entscheidung für datenschutzfreundliche Analytics ist auch eine Tech-Stack-Strategie-Entscheidung mit nachgelagerten Infrastrukturimplikationen. Wo leben Ihre Analytics-Daten? Wem gehört die Datenbank? Wie werden sie aufbewahrt und gelöscht, um dem Datensparsamkeitsgrundsatz der DSGVO zu entsprechen?

Wenn Sie ein selbst gehostetes Tool wie Umami oder Matomo wählen, fügen Sie Ihrer Infrastruktur eine Datenbank und einen Service hinzu. Dieser Service benötigt Backups, Monitoring und Sicherheits-Patching. Für die meisten Teams ist das handhabbar, aber es sollte eine bewusste Wahl sein, kein Nachgedanke.

Die Frage der Datenspeicherung ist wichtig für Produkte, die an deutsche Mittelstandsunternehmen oder Enterprise-Kunden mit Datenverarbeitungsverträgen verkauft werden. Das Speichern von Analytics auf EU-Infrastruktur – ob selbst gehostet oder über einen EU-basierten Analytics-Anbieter – vermeidet die Schrems-II-Komplikationen, die mit US-basierten Analytics-Plattformen einhergehen.

Wenn Sie Ihre Analytics-Architektur im Rahmen einer umfassenderen technischen Überarbeitung neu aufbauen, ist ein Webanwendungsentwicklungs- oder Digitale-Transformation--Engagement der richtige Kontext, um es ordentlich zu tun, anstatt es nachträglich anzuheften.

Praktische erste Schritte

Der schnellste Weg zu einem konformen, vollständigen Analytics-Setup für ein europäisches SaaS-Produkt:

Entfernen Sie Google Analytics oder ersetzen Sie es durch Plausible oder Umami. Fügen Sie das Skript-Tag hinzu, verifizieren Sie, dass es Traffic ohne Consent-Banner empfängt, und entfernen Sie die Consent-Management-Plattform, wenn das einzige Tool, das Consent erforderte, das Analytics-Skript war. Das allein vereinfacht Ihre rechtliche Compliance-Position erheblich.

Fügen Sie serverseitiges Event-Tracking für Ihre wichtigsten Conversion-Events hinzu. Identifizieren Sie die fünf bis zehn Momente in Ihrer User-Journey, die tatsächlich Produktentscheidungen beeinflussen – Aktivierungs-Events, Zahlungsabschluss, Feature-Adoptions-Meilensteine – und emittieren Sie serverseitige Events für jeden.

Etablieren Sie eine Datenaufbewahrungsrichtlinie für Ihre Analytics-Daten. Konfigurieren Sie die automatische Löschung von Daten, die älter als 12 Monate sind, dokumentieren Sie die Richtlinie und nehmen Sie sie in Ihre Datenschutzerklärung auf. Das erfüllt die Grundsätze der Datensparsamkeit und Speicherbegrenzung der DSGVO ohne manuelle Eingriffe.

Überprüfen Sie schließlich, welche anderen Third-Party-Skripte Sie im Laufe der Zeit hinzugefügt haben. Marketing-Pixel, Session-Recording-Tools und Chatbots erheben häufig personenbezogene Daten, ohne dass das Entwicklungsteam es merkt. Ein Content-Security-Policy-Audit deckt diese schnell auf.

Fazit

DSGVO-konforme Analytics ist keine Einschränkung, die es zu umgehen gilt – sie ist eine Architekturentscheidung, die bessere Daten produziert. Consent-Ablehnung entfernt ein nicht-zufälliges Stück Ihres Publikums aus Ihrem Analytics-Bild, und Third-Party-Tracking-Skripte geben externen Plattformen Daten über Ihre Nutzer, die Sie nicht kontrollieren. Datenschutzfreundliche Analytics – Plausible, Umami oder Matomo selbst gehostet mit ordentlicher Konfiguration – plus serverseitiges Event-Tracking für Conversions gibt Ihnen vollständige, zuverlässige Daten, die Ihnen gehören und denen Ihre Nutzer niemals zustimmen müssen.

Der Implementierungsaufwand ist für eine neue Anwendung bescheiden und eine überschaubare Migration für eine bestehende. Die rechtlichen und Datenqualitätsvorteile multiplizieren sich über die Zeit.

Wolf-Tech baut Next.js- und PHP/Symfony-Anwendungen mit datenschutzfreundlicher Instrumentierung von Grund auf und hilft bestehenden europäischen SaaS-Teams, von Consent-abhängigen Analytics-Stacks zu migrieren. Kontaktieren Sie uns unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io für eine kostenlose Beratung.