First-Party Analytics ohne Third-Party Tools

Sie wollen wissen, wie Besucher Ihre Website nutzen. Welche Seiten funktionieren, wo Nutzer abspringen, was sie interessiert. Das ist legitim – und für die Weiterentwicklung Ihres Angebots oft unverzichtbar.

Das Problem: Die gängigen Analyse-Tools wie Google Analytics setzen Cookies, tracken Nutzer über Websites hinweg und senden Daten an Server in den USA. Das kollidiert mit der DSGVO. Die Folge sind Cookie-Banner, Consent-Management und rechtliche Unsicherheit.

Im ersten Artikel dieser Serie haben wir gezeigt: Selbst Cloudflare Zaraz – eigentlich als datenschutzfreundlichere Alternative gedacht – setzt eigene Cookies, sobald Google Analytics aktiv ist. Egal wie Sie konfigurieren.

Die gute Nachricht: Es gibt einen anderen Weg. Zaraz bietet neben den klassischen Analytics-Integrationen auch ein HTTP Request Tool. Damit können Sie Events direkt an einen eigenen Endpoint senden – ohne Google Analytics, ohne Facebook Pixel, ohne Third-Party Tools. Zaraz arbeitet dann als reine Regel- und Filter-Schicht: Es entscheidet wann welche Daten gesendet werden, filtert sensible Informationen heraus und normalisiert die Events. Die eigentliche Speicherung und Auswertung passiert in Ihrer eigenen Infrastruktur. Das Ergebnis: Keine externen Tracker, keine Tool-Cookies, volle Datenhoheit.

Der Haken: Wer Analytics selbst baut, muss auch die Probleme selbst lösen, die fertige Tools im Hintergrund erledigen: Bots herausfiltern, doppelte Events erkennen, persönliche Daten aus URLs entfernen, Consent-Stufen abbilden. Dieser Artikel zeigt beides – die Architektur und die technischen Fallstricke, die Sie lösen müssen.

Die Zielarchitektur

Browser → Zaraz (nur Rules/Filter) → HTTP Request → Ihr Endpoint → Postgres

Was im Browser läuft:

• Nur Zaraz (leichtgewichtig)
• Keine GA-SDKs
• Keine Marketing-Pixel

Was Zaraz macht:

• Triggers definieren
• Events filtern
• PII entfernen
• HTTP Requests an Ihren Endpoint feuern

Was Sie bekommen:

• Zentrale Steuerung (Triggers/Variablen/Consent)
• PII-Filter an einer Stelle
• Keine Tool-Cookies (cfz_*, cfzs_*, _ga)
• First-Party Datenhoheit

*PII = Personally Identifiable Information – personenbezogene Daten wie E-Mail-Adressen, Namen oder Telefonnummern, die aus Analytics-Daten herausgefiltert werden sollten.

Zaraz-Konfiguration

Tools

1. GA4 Tool deaktivieren – komplett raus
2. HTTP Request Tool aktivieren – das ist Ihr einziges Tool

Das HTTP Request Tool finden Sie in der Zaraz Tool-Bibliothek. Es sendet Events als POST Request an eine URL Ihrer Wahl.

Warum keine Cookies? Die cfz_*-Cookies werden nicht von Zaraz selbst gesetzt, sondern von den integrierten Third-Party Tools – insbesondere GA4. Diese Tools brauchen Client-State für Session-Tracking, Engagement-Messung und Deduplizierung. Das HTTP Request Tool ist dagegen zustandslos: Es sendet einen POST Request und vergisst. Kein State, keine Cookies. Die Deduplizierung und Session-Logik verlagern Sie in Ihr eigenes Backend, wo Sie die volle Kontrolle haben.

Was Sie ohne GA4-Cookies verlieren:

Feature	Mit Cookies	Ohne Cookies
Wiederkehrende Besucher	Erkannt über Client-ID	Jeder Besuch = neuer User
Sessions	Gruppiert (30 Min. Timeout)	Nur einzelne Pageviews
User Journey	Pfade über mehrere Besuche	Nur innerhalb eines Besuchs
Engagement-Metriken	Scroll-Tiefe, Verweildauer	Eingeschränkt
Audiences/Remarketing	Möglich	Nicht möglich
Attribution	Über mehrere Sessions	Nur Last-Click

Für reine Reichweitenmessung (Welche Seiten werden aufgerufen? Woher kommen Besucher?) reichen cookieless Events. Für User-zentrierte Analyse (Wie entwickelt sich ein Nutzer über Zeit?) brauchen Sie entweder Cookies oder Login-basierte Identifikation.

Trigger

Trigger	Wann
Pageview	Seitenaufruf (inkl. SPA-Navigation)
Custom Events	signup_click, trial_start, etc.

SPA-Support können Sie anlassen – ohne Third-Party Tools setzt Zaraz keine problematischen Cookies.

Privacy-Filter (wichtig)

Unter Zaraz → Einstellungen → Privatsphäre:

Einstellung	Empfehlung
URL-Abfrageparameter entfernen	aktiviert
IP-Adressen trimmen	aktiviert
User-Agent bereinigen	aktiviert
Externe Verweise entfernen	aktiviert

Diese Filter greifen bevor die Daten Ihren Endpoint erreichen.

Ihr Backend-Endpoint

Beispiel: Astro API Route

// src/pages/api/events.ts
import type { APIRoute } from 'astro'
import { db } from '@/lib/db'

export const POST: APIRoute = async ({ request, clientAddress }) => {
  const event = await request.json()
  
  // 1. Validierung
  if (!isValidEvent(event)) {
    return new Response('Invalid', { status: 400 })
  }
  
  // 2. Bot-Filter
  const ua = request.headers.get('user-agent') || ''
  if (isBot(ua)) {
    return new Response('OK') // Silent drop
  }
  
  // 3. Deduplizierung
  const eventId = event.event_id || crypto.randomUUID()
  const exists = await db.query(
    'SELECT 1 FROM events WHERE event_id = $1', 
    [eventId]
  )
  if (exists.rows.length > 0) {
    return new Response('OK') // Bereits erfasst
  }
  
  // 4. PII Scrubbing (zusätzliche Sicherheit)
  const cleanProps = scrubPII(event.props)
  
  // 5. Speichern
  await db.query(`
    INSERT INTO events (event_id, name, props, page, ts)
    VALUES ($1, $2, $3, $4, NOW())
  `, [eventId, event.name, JSON.stringify(cleanProps), event.page])
  
  return new Response('OK')
}

function isValidEvent(e: unknown): e is Event {
  return typeof e === 'object' && e !== null 
    && typeof (e as Event).name === 'string'
}

function isBot(ua: string): boolean {
  const bots = ['bot', 'crawler', 'spider', 'monitoring', 'uptime']
  return bots.some(b => ua.toLowerCase().includes(b))
}

function scrubPII(props: Record<string, unknown>) {
  const piiKeys = ['email', 'phone', 'name', 'address']
  return Object.fromEntries(
    Object.entries(props).filter(([k]) => !piiKeys.includes(k.toLowerCase()))
  )
}

Cloudflare Worker Alternative

// worker.ts
export default {
  async fetch(request: Request): Promise<Response> {
    if (request.method !== 'POST') {
      return new Response('Method not allowed', { status: 405 })
    }
    
    const event = await request.json()
    
    // Validierung, Bot-Filter, Dedupe wie oben
    
    // In D1 oder externe DB schreiben
    await env.DB.prepare(`
      INSERT INTO events (event_id, name, props, page)
      VALUES (?, ?, ?, ?)
    `).bind(eventId, event.name, JSON.stringify(cleanProps), event.page).run()
    
    return new Response('OK')
  }
}

Postgres Schema

CREATE TABLE events (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  event_id TEXT UNIQUE NOT NULL, -- Für Deduplizierung
  ts TIMESTAMPTZ DEFAULT NOW(),
  name TEXT NOT NULL,
  props JSONB DEFAULT '{}',
  page TEXT,
  session_id TEXT,
  user_id TEXT, -- Nur bei Login
  consent_level TEXT DEFAULT 'minimal'
);

CREATE INDEX idx_events_ts ON events (ts);
CREATE INDEX idx_events_name ON events (name);
CREATE INDEX idx_events_dedupe ON events (event_id);

Technische Fallstricke lösen

1. Duplicate Events

SPA-Navigation, Back/Forward, Reloads – Zaraz kann doppelt feuern.

Lösung:

// Im Zaraz HTTP Request Body
{
  "event_id": "{{ client.randomUUID() }}",
  "name": "{{ event.name }}",
  "page": "{{ page.url.pathname }}"
}

Plus: UNIQUE Constraint auf event_id in Postgres.

2. Bot-Traffic

HTTP Endpoints bekommen Bot-Traffic. Ihre Analytics werden verfälscht.

Lösung (mehrstufig):

1. Cloudflare Bot Fight Mode – aktivieren
2. Rate Limiting – max. 10 Events/Sekunde pro IP
3. Server-Heuristik:

function isBot(request: Request): boolean {
  const ua = request.headers.get('user-agent') || ''
  const secFetchSite = request.headers.get('sec-fetch-site')
  
  // Bekannte Bots
  if (/bot|crawler|spider|monitoring/i.test(ua)) return true
  
  // Fehlende Browser-Header
  if (!secFetchSite) return true
  
  return false
}

3. PII-Leaks

Das größte Risiko: Query-Strings (?email=...), Form-Daten, freie Textfelder.

Lösung:

1. Zaraz-seitig: URL-Parameter entfernen (Privacy-Einstellung)
2. Backend-seitig: Allowlist für Event-Properties

const ALLOWED_PROPS = ['placement', 'plan', 'source', 'variant']

function sanitizeProps(props: Record<string, unknown>) {
  return Object.fromEntries(
    Object.entries(props)
      .filter(([k]) => ALLOWED_PROPS.includes(k))
      .map(([k, v]) => [k, String(v).slice(0, 100)]) // Länge begrenzen
  )
}

4. Consent-Steuerung

Ohne Third-Party Tools ist Consent oft nicht nötig. Aber Sie können trotzdem abstufen:

Consent-Level	Was Sie erfassen
none	Nichts
minimal	Nur Pageview-Zähler (kein Referrer, keine Props)
analytics	Vollständige Events mit Props

// Zaraz Consent Integration
if (zaraz.consent.get('analytics')) {
  // Volle Events
} else {
  // Nur anonymer Pageview
}

DSGVO-Einordnung

Was Sie durch diese Architektur vermeiden

• Drittlandtransfer zu Google/Meta im Browser
• Third-Party Scripts
• Tool-Cookies (cfz_*, _ga, _fbp)

Was bleibt

• Sie verarbeiten Nutzungsdaten first-party
• Sie sind Verantwortlicher, nicht Google
• Rechtsgrundlage wird einfacher:
  • Marketing-Seite: oft berechtigtes Interesse (mit Minimierung)
  • App/Login: Vertragserfüllung oder berechtigtes Interesse

Audiences: Was geht, was nicht

Business-Segmente (empfohlen)

Basieren auf Login / Account / Produktzustand:

• „Trial-User”
• „Paid-Kunde”
• „Feature X genutzt”

Kein Tracking über Websites hinweg nötig. DSGVO-fähig.

Remarketing-Audiences (problematisch)

Brauchen Wiedererkennung über Zeit/Seiten:

• Typischerweise Consent nötig
• Selbst first-party ist es Profiling
• Ohne Consent rechtlich wackelig

Export-Optionen

Aus Ihrer Postgres Event-Pipeline können Sie exportieren nach:

Ziel	Wie	Wofür
GA4	Measurement Protocol (serverseitig)	Stakeholder-Reports
BigQuery	Scheduled Export	Langzeit-Analyse
Metabase/Superset	Direkte DB-Verbindung	Eigene Dashboards

GA4 Measurement Protocol Export

async function exportToGA4(event: DbEvent) {
  await fetch(
    `https://www.google-analytics.com/mp/collect?measurement_id=${GA_ID}&api_secret=${SECRET}`,
    {
      method: 'POST',
      body: JSON.stringify({
        client_id: 'server-export',
        events: [{
          name: event.name,
          params: event.props
        }]
      })
    }
  )
}

Zusammenfassung

Diese Architektur lohnt sich, wenn Sie:

• Zaraz als Regel-/Filter-GUI nutzen wollen
• Aber die Daten first-party in Ihrer DB haben wollen
• Keine Third-Party Tool-Cookies akzeptieren wollen

Der Stack:

Schicht	Komponente
Browser	Zaraz (nur HTTP Request Tool)
Edge	Ihr Endpoint (Astro/Worker)
Storage	Postgres
Dashboard	Metabase/Superset
Export	Optional GA4 Measurement Protocol

Das Ergebnis:

• Weniger Arbeit als „alles selbst”
• Viel mehr Kontrolle als „GA über Zaraz”
• Keine Tool-Cookies
• Saubere DSGVO-Story

Alternative: Plausible oder Umami als Backend

Sie müssen nicht alles selbst bauen. Plausible und Umami bieten APIs, an die Sie Events direkt senden können – ohne deren JavaScript im Browser zu laden.

Zaraz → Plausible Events API

Plausible bietet eine Events API für serverseitige Events:

POST https://plausible.io/api/event

Vorteile:

• Kein Plausible-Script im Browser nötig
• Fertige Dashboards, keine eigene Entwicklung
• Cookieless, DSGVO-konform
• EU-gehostet (Cloud) oder Self-hosted (Community Edition)
• Custom Properties für erweiterte Analyse

Setup: Zaraz HTTP Request Tool sendet an Plausible statt an eigenen Endpoint. Sie konfigurieren die Events in Zaraz, Plausible liefert die Auswertung.

Zaraz → Umami API

Umami funktioniert ähnlich mit der Track Events API:

POST https://your-umami.com/api/send

Vorteile:

• Open Source, Self-hosted
• Keine Abhängigkeit von externem Anbieter
• Webhook-Integration für externe Events (z.B. Zahlungsanbieter)
• Python und Kotlin Clients verfügbar

Entscheidungshilfe

Kriterium	Eigene Pipeline	Plausible	Umami
Aufwand Setup	Hoch	Niedrig	Mittel
Dashboards	Selbst bauen	Fertig	Fertig
Datenhoheit	Maximal	Cloud oder Self-host	Self-host
Kosten	Hosting	Ab 9€/Monat oder Self-host	Nur Hosting
Flexibilität	Maximal	Begrenzt	Mittel

Empfehlung:

• Plausible Cloud: Schnellster Weg, wenn EU-Hosting reicht
• Umami Self-hosted: Volle Kontrolle ohne eigene Dashboard-Entwicklung
• Eigene Pipeline: Wenn Sie spezifische Auswertungen oder Integration mit anderen Systemen brauchen

Lohnt sich dieser Aufwand noch?

Eine berechtigte Frage, denn das EU-Datenschutzrecht ist in Bewegung.

Was sich ändert

Die EU arbeitet an einer ePrivacy-Verordnung, die das Cookie-Recht neu regeln soll. Gleichzeitig gibt es Bestrebungen, „berechtigtes Interesse” für Analytics klarer zu definieren. Die Tendenz:

• Anonyme Reichweitenmessung könnte explizit consent-frei werden
• First-Party Analytics werden voraussichtlich privilegiert
• Third-Party Tracking bleibt problematisch

Warum diese Architektur trotzdem sinnvoll ist

1. Zukunftssicher: First-Party, minimale Daten, keine Drittanbieter – das ist genau die Richtung, in die das Recht geht

2. Unabhängig von Regulierung: Selbst wenn Consent-Regeln gelockert werden, behalten Sie die Datenhoheit. Sie sind nicht abhängig von Google, Meta oder anderen Anbietern

3. Technisch sauberer: Weniger JavaScript, schnellere Seiten, keine Third-Party-Ausfälle

4. Vertrauen: Nutzer und Kunden schätzen transparente Datenverarbeitung – unabhängig von rechtlichen Mindestanforderungen

Wann Sie warten können

Wenn Sie eine kleine Marketing-Website betreiben und keine sensiblen Daten verarbeiten, reicht möglicherweise Cloudflare Web Analytics. Der Aufwand für eine eigene Pipeline lohnt sich dann nicht.

Wann Sie jetzt handeln sollten

• SaaS/Produkt mit Login: Sie brauchen Product Analytics sowieso
• Sensible Branchen: Gesundheit, Finanzen, B2B mit Unternehmenskunden
• Internationale Märkte: Unterschiedliche Regulierungen, eine saubere Lösung
• Langfristige Planung: Die Architektur wächst mit Ihren Anforderungen

Realität für kleinere Unternehmen

Die strengen Regularien und hohen Bußgelder treffen vor allem die großen Player – Google, Meta, Amazon. Für kleinere Unternehmen und Mittelständler gilt pragmatischer: Nicht offensichtlich gegen Regeln verstoßen, nur die Daten tracken, die man tatsächlich benötigt und auswertet.

Die kommenden rechtlichen Änderungen werden vermutlich genau diesen Graubereich legalisieren – anonyme Reichweitenmessung ohne Consent, First-Party Analytics mit berechtigtem Interesse.

Ein anderer Faktor verändert die Gleichung zusätzlich: Die zunehmende Nutzung von KI beim Einkauf durch Kunden reduziert die Notwendigkeit von klassischem Website-Tracking. Wenn Nutzer über Chatbots und KI-Assistenten einkaufen statt sich durch Ihre Website zu klicken, verschieben sich die relevanten Metriken. Aber das ist ein Thema für einen anderen Artikel.

---

Quellen und Tools

Cloudflare

• Zaraz HTTP Request Tool – Offizielle Dokumentation
• Cloudflare Workers – Edge-basierter Ingest
• D1 Database – Serverless SQL

Analytics & Dashboards

• Metabase – Open Source Dashboards
• Superset – Apache Analytics Platform

Weiterführend

• Google Tag Gateway vs. Cloudflare Zaraz – Der Vergleich und warum Zaraz Cookies setzt
• GA4 Measurement Protocol – Serverseitiger Export