Von Google Analytics zu Umami: Cookie-freie Webanalyse selbst gehostet

Meine Website lief lange mit Google Analytics — Consent-Banner, Cookie-Verwaltung inklusive. Nach der Umstellung auf Umami Analytics ist das alles weg. Kein Banner, keine Cookies, keine Daten in den USA. Hier ist, warum ich gewechselt habe und wie die Migration konkret ausgesehen hat.

Das Problem mit Google Analytics

Google Analytics ist mächtig. Aber für eine einfache Unternehmenswebsite ist es auch unverhältnismäßig viel:

• ~50 KB Tracking-Script, das die Ladezeit beeinflusst
• Cookie-Banner Pflicht nach DSGVO — jeder Besucher muss aktiv zustimmen
• Datenübertragung in die USA — datenschutzrechtlich problematisch, besonders für österreichische und deutsche Unternehmen
• Consent-Rate unter 50% — die Hälfte aller Besucher ist in GA unsichtbar, weil sie ablehnen

Das letzte Argument hat mich am meisten gestört. Ich sehe nur einen Bruchteil meiner tatsächlichen Besucher, weil die andere Hälfte das Banner weggeklickt hat.

Warum Umami

Umami ist eine Open-Source-Webanalyse-Alternative mit einem klaren Fokus:

• Cookie-frei — keine Cookies, kein Consent-Banner nötig
• ~2 KB Script — 25× kleiner als GA4
• Datenschutzkonform by default — keine personenbezogenen Daten, keine IP-Adressen im Klartext
• Self-hosted — volle Kontrolle, Daten bleiben auf meinen Servern
• MIT-Lizenz — kostenlos, keine versteckten Kosten
• Multi-Site — eine Instanz für mehrere Projekte

Der entscheidende Punkt: Umami ist nach § 165 Abs. 3 TKG 2021 und DSGVO ohne Einwilligung betreibbar, weil keine personenbezogenen Daten verarbeitet werden. Kein Banner, kein Consent-Management, kein Komplexitätsoverhead.

Meine Architektur

Ich betreibe Umami auf demselben Hetzner VPS wie meine anderen Tools:

analytics.example.com
    ↓ nginx (reverse proxy, Let's Encrypt SSL)
Docker Container (Umami Node.js App)
    ↓ SSL-Verbindung
Hetzner Managed PostgreSQL
    └── Schema: umami (isoliert vom Rest)

Bewusste Entscheidungen:

• Kein eigenes Postgres — ich nutze die bestehende Hetzner Managed DB mit einem eigenen Schema (umami), das vollständig isoliert vom Rest der Datenbank ist

Die Migration im Überblick

1. Infrastruktur vorbereiten

Schema in der bestehenden Postgres-Datenbank anlegen:

CREATE SCHEMA IF NOT EXISTS umami;
GRANT USAGE, CREATE ON SCHEMA umami TO youruser;

Docker Compose für Umami (/opt/umami/docker-compose.yml):

services:
  umami:
    image: docker.umami.is/umami-software/umami:postgresql-latest
    container_name: umami
    restart: unless-stopped
    ports:
      - "127.0.0.1:3002:3000"
    environment:
      DATABASE_URL: ${DATABASE_URL}
      DATABASE_TYPE: postgresql
      APP_SECRET: ${APP_SECRET}
      DISABLE_TELEMETRY: "1"
      NODE_EXTRA_CA_CERTS: /etc/ssl/certs/hetzner-ca.crt
    volumes:
      - /opt/umami/ca.crt:/etc/ssl/certs/hetzner-ca.crt:ro

Das Server-Zertifikat der Hetzner Managed DB habe ich direkt aus dem TLS-Handshake extrahiert und Node.js über NODE_EXTRA_CA_CERTS bekannt gemacht:

openssl s_client -connect db-host:5432 -starttls postgres 2>/dev/null </dev/null \
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
  | tee /opt/umami/ca.crt

2. nginx vhost + SSL

server {
    listen 443 ssl http2;
    server_name analytics.example.com;
    location / {
        proxy_pass http://127.0.0.1:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

SSL via Certbot, wie gewohnt.

3. Nuxt-Integration

In nuxt.config.ts — der Script wird nur injiziert wenn die Env-Variable gesetzt ist:

script: process.env.NUXT_PUBLIC_UMAMI_ID ? [
  {
    src: 'https://analytics.example.com/script.js',
    'data-website-id': process.env.NUXT_PUBLIC_UMAMI_ID,
    defer: true,
  },
] : [],

Dazu ein schlankes Composable für Custom Events:

// composables/useUmami.ts
export function trackEvent(event: string, data?: Record<string, unknown>): void {
  if (import.meta.client && window.umami) {
    window.umami.track(event, data)
  }
}

4. Cookie-Banner entfernen

Da Umami keine Cookies setzt, ist der Banner schlicht nicht mehr nötig. Zwei Zeilen entfernt aus den Layouts — fertig.

Was ich gewonnen habe

Der größte praktische Gewinn: vollständige Datensicht. Keine Besucher, die durch den Consent-Banner verschwinden.

Wann Umami nicht ausreicht

Umami ist kein GA-Ersatz für jeden Anwendungsfall. Wer folgendes braucht, sollte bei GA bleiben oder eine andere Lösung wählen:

• Conversion-Funnels mit tiefer Attribution (z. B. Google Ads-Integration)
• Remarketing-Zielgruppen für Google/Meta Ads
• E-Commerce-Tracking mit Umsatzdaten

Für eine Unternehmenswebsite, einen Blog oder ein SaaS-Dashboard ist Umami mehr als ausreichend.

Fazit

Die Migration hat wenige Stunden gedauert und war es wert. Ich sehe jetzt mehr Daten als vorher — ohne Banner, ohne Cookies, ohne Daten bei Google. Für Projekte, die DSGVO-Konformität ernst nehmen, ist Umami eine klare Empfehlung.