⚡ HomelabVergleich

Selbst gehostete Webanalyse: Was du selbst hosten kannst – und was nicht

Du betreibst eine Website, vielleicht für Kundschaft, vielleicht für dein Homelab. Du willst wissen, wie oft welche Seite besucht wird, woher die Besucher kommen, welche Seiten funktionieren und welche nicht. Das ist legitimate Fragestellung. Google Analytics (GA) ist die Standardlösung, mit der viele starten – und viele landen nach einem Blick auf die Datenschutzpflicht, die Logik der Tracking-Cookies und die Dokumentation des Datenprofils des Anbieters wieder raus.

Dieser Artikel erklärt, warum GA aus Datenschutz- und Technik-Sicht problematisch sein kann, was eine selbst gehostete Analyse konkret kann, welche drei bekannten Open-Source-Tools es gibt, wie man sie einrichtet, und wo ihre Grenzen liegen. Am Ende steht eine konkrete Entscheidungshilfe mit Kosten und Aufwand.

Warum Google Analytics datenschutzrechtlich und technisch problematisch sein kann

Google Analytics verarbeitet Daten auf Servern von Google. Das hat mehrere Konsequenzen, die für kleine Betreiber und insbesondere für BSI- oder DSGVO-bewusste Unternehmen relevant sind.

1. IPs und persönliche Daten im Ausland. GA erfasst IP-Adressen. IP-Adressen können personenbezogene Daten sein (EuGH, C-131/12 „Google-Musterentscheidung", 2014; C-311/18 „Schrems II", 2020). Ob deine konkrete IP-Verarbeitung personenbezogen ist, hängt von Kontext ab – aber die Frage taucht auf, sobald du Analytics-Erhebung über das reine reine Datenbewusstsein hinaus auf deine Kund:innen beziehst. Google selbst weist darauf hin, dass IPs pseudonymisiert werden sollen (GA4-Maskierung), aber die Daten liegen weiterhin auf Google-Infrastruktur und können mit anderen Google-Diensten korreliert werden.

2. Consent-Pflicht für Marketing-Tracking. Wenn GA für Marketing-, Retargeting- oder Profiling-Zwecke genutzt wird, ist ein Rechtsgrund, der nicht Einwilligung ist, schwierig. Die DSGVO erfordert bei profilbildendem Tracking eine Rechtsgrundlage; in Deutschland ist Einwilligung (Art. 6 Abs. 1 lit. a DSGVO) der übliche Weg für Werbetracking. Das führt zu dem Consent-Banner, den so viele Seiten haben – also ein technischer Aufwand und UX-Nachteil als Folge einer gewählten Analytics-Lösung.

3. Profil-Aufbau und datenökonomische Abhängigkeit. GA sammelt mehr als Seitenaufrufe: Geräte-Hints, Referrer-Ketten, event-basierte Verfolgung, User-ID-Integrationen, Conversion-Tracking, Google Ads-Integration. Das ist bewusst gewollt angesichts des Geschäftsmodells (Werbeplattform), aber es bedeutet, dass Analytics-Erhebung und Profil-Aufbau nicht sauber getrennt sind. Wenn du nur Meter- und Reichweitenwissen willst, ist das Profil-Aufbau-Konstrukt Overkill und potenzielle Compliance-Treiber.

4. Technische Abhängigkeit. GA ist ein Cloud-Dienst. Wenn Google die Schnittstelle ändert, Reports ändert, auf Daten zugreift oder Account-Modelle ändert, ist das extern vom eigenen Infrastruktur-Kontrolle. Self-Hosted-Lösungen verlegen die Kontrolle auf dein eigenes System.

Zusammengefasst: Das Kernproblem ist nicht, dass GA illegitim wäre – es ist, dass GA als Marketingprodukt des Ad-Tech-Konzepts konzipiert ist, und das erzeugt DSGVO-Compliance-Arbeit und Consent-Banner, wenn du es für reine Nutzungsstatistiken wählst, für die eine selbsterhobene Lösung ausreichen würde. ## Was eine selbst gehostete Analyse leisten kann – und was nicht

Eine selbst gehostete Analytics-Lösung kann einige Dinge gut und andere Dinge gar nicht. Klare Erwartungsabgrenzung ist wichtig, sonst landet man bei Enttäuschung.

Was sie kann:

Was sie NICHT leistet:

Die Architektur: eigener Server, eigener Proxy, eigene Domain

Die typische Architektur einer selbst ge hosteten Webanalyse ist bersichtlich. Sie besteht aus vier Bausteinen:

1. Der Analyse-Ansatz selbst. Eine Anwendung, die Requests eines Tracking-Skripts entgegennimmt, speichert Metriken, bietet Reporting über ein Interface. Beispiele: Plausible Analytics CE, Umami, Matomo.

2. Eine eigene Domain. Eine Subdomain wie analytics.deineseite.de oder statistik.unternehmen.de. Diese Domain wird im Tracking-Skript als data-domain oder äquivalent referenziert. Das Skript sendet Requests an diese Domain.

3. Ein Zertifikat. Da das Tracking-Skript über HTTPS mit dem Browser kommuniziert, muss die Domain ein gültiges TLS-Zertifikat haben. Let's Encrypt via ACME (HTTP- oder DNS-Challenge) ist der Standardweg. Das Zertifikat wird vom Reverse Proxy verwaltet; die Analyse-Anwendung selbst muss keine Zertifikatsadministration durchführen.

4. Ein Reverse Proxy, der den Tracking-Pfad vor dem Skript ausblendet. Das Skript wird in die Ziel-Website eingebunden (HTML <script> oder img-Tag). Der Skript-Code macht Requests an die Analyse-Domain (z.B. https://analytics.meinedomain.de/js/script.js oder /api/event). Der Reverse Proxy leitet diese Requests an die Analyse-Anwendung weiter. Die Analyse-Anwendung läuft hinter dem Proxy und wird nie direkt von außen exponiert. Das ist das saubere Muster: Skript ist extern einbindbar, Backend-Logik ist proxy-geschützt.

Wo der Zaehlcode hingehört. Der Analytics-Script-Code gehört in den <head> oder das <body> des getrackten Dokuments. Der konkrete Mechanismus variiert je Tool:

Der entscheidende Punkt: Das Skript gehört in deine Website, nicht in das Backend. Das Backend (die Analytics-Anwendung) empfängt die Requests, die das Skript schickt. Das Backend läuft auf einem Server mit Reverse Proxy davor. Du brauchst nichts von der Website selbst, außer dass sie das Skript einbindet. Das ist der Architekturvorteil: Analytics-Anwendung und Ziel-Website sind losgelöst voneinander.

Drei Ansätze im Vergleich

Die bekannten selbst ge hosteten Analytics-Optionen im Kleinen sind Plausible Community Edition (CE), Umami und Matomo On-Premise. Alle drei existieren, alle drei sind quelloffen, alle drei hosten sich selbst. Sie unterscheiden sich in Anspruch, Ressourcenaufwand und Funktionsumfang.

Die folgende Tabelle vergleicht sie nach Kriterien, die für die Entscheidung relevant sind. Werte sind zum größten Teil aus den jeweiligen Dokumentationen und einem Einführungs-Setup abgeleitet; konkrete Ressourcenverbräuche hängen von Traffic-Volumen und Konfiguration ab. Wo kein hard fact verfügbar ist, steht „zu prüfen" oder ein plausible Bereich.

|| Kriterium | Plausible CE | Umami | Matomo On-Premise |

||---|---|---|---|

|| Lizenz | AGPL-3.0 (Community Edition) | MIT | GPL-3.0 / kommerzielle Lizenz möglich (Core ist quelloffen) |

|| Technische Basis | Elixir/BEAM + SQLite/PostgreSQL + Go-Tracker | Next.js + PostgreSQL (optional SQLite) | PHP + MySQL/MariaDB |

|| Speicherbedarf (Anwendung) | Gering: mehrere Dutzend MB RAM im Betrieb, Datenbank je nach Wahl SQLite (Datei) oder PostgreSQL | Niedrig-Mittel: Anwendung wenige Dutzend bis ~100 MB RAM; PostgreSQL-Datenbank beansprucht je nach Traffic 100 MB–einige GB | Mittel-Hoch: PHP-FPM + Datenbank + Cron-Jobs; PostgreSQL ähnlich wie Umami, aber Oberfläche und Funktionsumfang sind größer |

|| Speicherbedarf (Datenbank, zu prüfen) | SQLite-Datei wächst mit Traffic; bei mehreren Hunderttausend Pageviews/Monat plausibel <1 GB. PostgreSQL ähnlich. | PostgreSQL-Datenbank bei moderaten Traffic-Mengen typischerweise <500 MB/Monat (Schätzwert, zu prüfen je nach Datenmodell). | MariaDB/MySQL-Datenbank bei mittlerem Traffic oft einige hundert MB bis 1-2 GB/Monat; zu prüfen je nach Auflösung der Ereignisse. |

|| Erst-Setup-Aufwand | Niedrig-Mittel: Docker Compose bereitgestellt, Umgebungsvariablen gesetzt, Domain und Zertifikat besorgt. 1–2 Stunden für erstes laufendes Setup. | Niedrig-Mittel: Docker Compose mit PostgreSQL, Umgebungsvariablen gesetzt, Domain und Zertifikat. 1–2 Stunden. | Mittel-Hoch: Docker Compose oder manuelle PHP-Installation + Datenbank-Konfiguration + Super-User im Setup-Wizard. 2–4 Stunden bis zum ersten Dashboard. |

|| Funktionsumfang | Seitenaufrufe, eindeutige Besucher, Session-Dauer, Referrer, Land/Region (mit Geo-IP), Echtzeit. Kein User-ID-Tracking für Geräteübergreifendes. Keine Conversion-Tracking-Deep-Dive wie Wirtschaftlichkeitsanalyse. | Seitenaufrufe, Besucher, Sessions, Referrer, Land/Region (Geo-IP erforderlich), Echtzeit, einfache Conversion-Ereignisse (Eigen-Code). Minimaler Funktionsumfang; Fokus auf einfache Privacy-First-Statistiken. | Umfangreich: Seitenaufrufe, Besucher, Sessions, Referrer, Geo, Kampagnen-Tracking, Conversion-Tracking, Event-Tracking, Custom-Dimensionen, Daten-Import, Segmentierung, Reporting-APIs, Export. Nähert sich dem Funktionsumfang von GA im Basismodul. |

|| Cookie-Pflicht | Ohne Cookies normalerweise nicht nötig (Tracking-Parameter als selbst-bereitstelltes First-Party-Skript, keine Third-Party-Cookie-Tools). Datenbasis local. Rechtsgrund zu prüfen: Legitimate Interest oder Einwilligung je nach Zweck. | Ohne Cookies; gleiche Überlegung wie Plausible. Kein Cookie-Set durch Analytics-Skript im Standard. Rechtsgrund zu prüfen. | Ohne Cookies im Basis-Tracking möglich (Matomo Zählpixel oder cookie-freier Tracker); Matomo bietet aber Cookie-basierte Tracking-Modi an, die dann Consent erfordern würden. Matomo-Dokumentation dokumentiert DSGVO-Compliance-Optionen; zu prüfen ob konkret konfiguriert. |

|| Datenhaltung | Du bestimmst die Aufbewahrung. Standardaufbewahrung zu prüfen in Konfiguration; eine explizite Aufbewahrungsfrist zu setzen ist sinnvoll. | Du bestimmst die Aufbewahrung in der Datenbank. Aufbewahrungsfrist zu konfigurieren. | Du bestimmst die Aufbewahrung in Matomo-Einstellungen (Datenbank-Archivierung, Löschregeln für nonparametric Daten, IPs). Detaillierte Kontrolle vorhanden. |

|| Eignung für statische Seiten | Sehr gut geeignet. Leichtgewichtig, kein Server-seitiges Rendering nötig, Skript einfach einzubinden, Reporting ohne Komplexität. | Geeignet. Einfach und leichtgewichtig; gut für statische Sites und Blogs. | Eher für dynamische Kontexte, wenn Funktionsumfang gebraucht wird; für statische Seiten mit wenigen Anforderungen Overkill, aber technisch machbar. |

|| Geo-IP Option | Optional mit MaxMind GeoLite2 (free) oder käuflicher Edition. Lizenzschlüssel einbinden (to prüfen: das Skript setzt auf MaxMind; Lizenz Bestimmungen beachten). | Geo-IP mit externen Datenbanken, zu prüfen welche Integration verfügbar; Umami kann Geo über zusätzliche Konfiguration anbieten, Details in Dokumentation. | Matomo hat eingebaute Geo-IP mit Lizenzoptionen (MaxMind-Lizenz), oder manuelle Konfiguration; Details zu prüfen. |

|| Reporting-API | Einfaches Reporting, API vorhanden, Authentifizierung zu prüfen (API-Key), um externe Auswertungen zu tun. | Reporting-Oberfläche vorhanden, API-Export/Abfragen zu prüfen in Dokumentation (zu prüfen, welche Formate/export-Möglichkeiten). | Umfassende API für Reporting, Daten-Export (CSV, JSON), Dashboard-Export, API-Authentifizierung. |

|| Passend für … | Blogs, Marketing-Seiten, einfache Websites, Homelab-Präsenz, kleine Unternehmensseiten mit Bedarf an sauberen Grundstatistiken ohne Komplexität. | Einfache Websites, statische Seiten, Blogs, einfache Projektseiten, wenn Fokus auf minimalem Aufwand und Privacy-First. | Firmenseiten mit Conversion-Bedarf, E-Commerce-Licht, Kampagnen-Tracking, zweiichtsensiblyere Reporting-Ansprüche, wenn Funktionsumfang GA-ähnlich gewünscht, aber lokal. |

Lesehinweis zur Tabelle. Die Vergleichswerte sind grobe Orientierungshilfen. Ressourcenverbräuche sind je nach Traffic, Anbieter und Hardware abweichend. Speicherbedarf ist ein Schätzwert unter Standardannahmen (z.B. einzelner Hosting-Server, kein Clustering, ohne-Redundanz-Betrieb). Konkrete Werte zu messen, indem du das Setup laufen lässt und mit deinem eigenen Traffic beobachtest, ist der zuverlässige Weg.

Anleitung: Plausible Analytics CE mit Docker Compose auf Proxmox

Plausible Community Edition läuft als Docker Compose-Stack. Die Komponenten sind: der Plausible-App-Server, ein Datenbank-Backend (standardmäßig SQLite, optional PostgreSQL), und optional eine Umgebungsvariable für Geo-IP (MaxMind).

Voraussetzungen

Schritt 1: Verzeichnis und .env erstellen


mkdir -p /opt/plausible
cd /opt/plausible
cp .env.example .env

Die .env-Datei aus dem Plausible CE-Repository (.env.example) enthält die Hauptumgebungsvariablen. Die wesentlichen Variablen, die du setzen musst oder solltest, sind:


# Basis-URL, unter der das Plausible-Interface und der Tracker erreichbar sind
BASE_URL=https://analytics.beispiel.de

# Secret Key Base – ein zufälliger String für Session-Cookies undinterne Hashes
SECRET_KEY_BASE=<32-zu-mehr-zeichen-zufaellig-string>

# HTTP/HTTPS Ports (fuer eigene Port-Bindung oder fuer Caddy vorgesehen)
HTTP_PORT=8080
HTTPS_PORT=8443

# Optional: Geo-IP mit MaxMind
# MAXMIND_LICENSE_KEY=<falls MaxMind-Lizenz vorhanden>
# MAXMIND_EDITION=GeoLite2-City

SECRET_KEY_BASE kannst du z.B. mit openssl rand -base64 64 oder einem gleichwertigen Zufallsgenerator erzeugen. Das ist ein sensitiver Wert – behandele ihn wie ein Passwort.

Die Ports HTTP_PORT und HTTPS_PORT sind die Ports, die Plausible selbst bindet. Wenn du Caddy als Reverse Proxy vor Plausible setzt, bindet Plausible typischerweise auf einem lokalen Port (z.B. 8080 für HTTP), und Caddy leitet von 443 auf diesen lokalen Port weiter. Das ist das saubere Muster: Plausible selbst hat kein TLS; Caddy terminiert TLS.

Schritt 2: Docker Compose erstellen

Die offizielle Compose-Datei aus dem Plausible-Repository (docker-compose.yml) wird bei der Initialisierung mitgeliefert. Sie enthält die Dienste plausible, pb (den PostgreSQL- oder SQLite-Connector, je nach Konfiguration), und ggf. andere Hilfskomponenten. Die genaue Struktur folgt dem Beispiel aus dem Repository; du adaptierst sie auf deine Umgebung.

Ein minimaler Customizing-Ansatz (mit Caddy im selben Host oder extern) bindet nicht direkt an 80/443, sondern an den lokalen Port:


services:
  plausible:
    image: plausible/plausible-ce:latest
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - plausible-data:/app
volumes:
  plausible-data:

Die Bindung an 127.0.0.1:8080 (nicht an 0.0.0.0) ist wichtig: Damit ist Plausible nur von localhost erreichbar, und Caddy muss explizit vorgeschaltet werden. Ohne diese Bindung wäre Plausible direkt aus dem Netzwerk erreichbar, was du vermeiden willst, solange Caddy den Traffic filtert.

Schritt 3: Starten


docker compose up -d

Im ersten Start initialisiert Plausible die Datenbank. Das kann einige Sekunden bis Minuten dauern. Das Interface ist nach dem Start unter http://localhost:8080 (intern) oder – nach Caddy-Konfiguration – unter https://analytics.beispiel.de erreichbar.

Das erste Mal meldet sich ein Setup-Assistent oder ein Login; die genaue Mechanismus variieren je Konfiguration. Ein Admin-Benutzer wird erstellt; danach kannst du das Dashboard aufrufen.

Schritt 4: Caddy als Reverse Proxy für Plausible

Das Caddyfile für die Analyse-Domain:


analytics.beispiel.de {
    reverse_proxy 127.0.0.1:8080

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output file /var/log/caddy/analytics.log
        format console
    }
}

Das reverse_proxy 127.0.0.1:8080 leitet alle Anfragen an den Plausible-Container weiter. Caddy bindet an 80 und 443, erneuert das Let's Encrypt-Zertifikat automatisch, und der Plausible-Container selbst muss sich nicht um TLS kümmern.

Wichtiger Hinweis für Plausible: Das Plausible-Tracking-Skript verweist auf BASE_URL aus der .env-Datei. Wenn du den Tracker-Script-Tag in deine Website einbindest, muss das Skript auf derselben Domain wie BASE_URL liegen. Also: Website https://beispiel.de, Tracker-Skript verweist auf https://analytics.beispiel.de/js/script.js (Pfad je nach Version zu prüfen – der Standard für CE ist /js/script.js oder ein ähnlicher Pfad; in der Dokumentation zu verifizieren).

Schritt 5: Tracking-Skript in die Website einbinden

In dein HTML (oder Template deiner statischen Seite), im <head>:


<script defer data-domain="beispiel.de" src="https://analytics.beispiel.de/js/script.js"></script>

Eventuell erforderlich: data-domain muss mit der Domain übereinstimmen, die Plausible als data-domain konfiguriert hat. Die exakte Bedeutung des data-domain Attributs ist in der Plausible-Dokumentation zu verifizieren; es identifiziert in der Regel die Domain, deren Traffic gemeldet wird, und kann für Cross-Domain-Tracking verwendet werden (zu prüfen).

Schritt 6: Geo-IP optional aktivieren

Wenn du Geo-IP (Land/Region-Statistiken) willst, setzt du in der .env die MaxMind-Lizenzschlüssel und Edition. Für die kostenlose GeoLite2-Lizenz musst du einen Account bei MaxMind erstellen und einen Lizenzschlüssel anfordern; der Lizenzschlüssel ist eine konkrete Angabe, die in der .env gesetzt wird. Das ist kein zwingender Bestandteil von Plausible, sondern eine optionale Erweiterung.

Schritt 7: Daten und Backups

Plausible speichert Daten in einem Docker-Volume (plausible-data:/app). Für Backups mountest du das Volume oder erstellst Snapshots. Die Datenbank (SQLite oder PostgreSQL) liegt im Volume; ein Backup besteht aus einem Mount-Volume oder einem Dump der Datenbank.

Ein Backup-Kommando (zu prüfen, ob SQLite oder PostgreSQL im genutzten Setup):

Für SQLite (Beispiel, grob):


docker compose exec plausible sqlite3 /app/plausible.db ".backup '/backup/plausible-$(date +%Y%m%d).db'"

Für PostgreSQL: Ein pg_dump des Datenbank-Users. Das ist abhängig von der genutzten Datenbank-Konfiguration.

Eine präzise Backup-Strategie zu planen, bevor Traffic aufgebaut wird, ist sinnvoll – Daten in der Analytics-Datenbank sind löschbar, aber du willst nicht versehentlich alle Statistiken verlieren.

Schritt 8: Aufbewahrung und Löschung

Plausible bietet Einstellungen für Datenaufbewahrung (zu prüfen in der Admin-Oberfläche). Du kannst Statistiken für ältere Daten löschen, indem du die entsprechenden Aufbewahrungsregeln konfigurierst. Rohdaten (IP-Adressen etwa) können durch IP-Anonymisierung oder Löschregeln geschützt werden.

Anleitung: Umami – kurze Variante für Docker Compose und Caddy

Umami ist die schlankere Alternative. Es läuft mit Docker Compose, benötigt eine PostgreSQL-Datenbank, und wird ebenfalls über Caddy oder einen anderen Reverse Proxy proxyt.

Schritt 1: Verzeichnis und docker-compose.yml


mkdir -p /opt/umami
cd /opt/umami

Eine Compose-Datei für Umami mit PostgreSQL (Beispiel nach Dokumentation von Umami):


services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:3000:3000"
    depends_on:
      db:
        condition: service_healthy
    volumes:
      - umami-data:/app/data
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    env_file: .env
    environment:
      POSTGRES_DB: umami_db
      POSTGRES_USER: umami_user
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - umami-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami_user"]
      interval: 10s
      retries: 5

volumes:
  umami-data:
  umami-db:

Die Umgebungsvariablen in .env:


DATABASE_URL=postgresql://umami_user:CHANGE_ME_PASSWORD_HERE@db:5432/umami_db
DATABASE_TYPE=postgresql
UMAMI_SITE_URL=https://analytics.beispiel.de
APP_SECRET=<openssl rand -hex 32, oder aehnlich zufaelliger 64-stelligen String>
DISABLE_TELEMETRY=1

APP_SECRET ist ein sensitiver Wert. Erstelle ihn mit z.B. openssl rand -hex 32.

Schritt 2: Caddy-Eintrag für Umami


analytics.beispiel.de {
    reverse_proxy 127.0.0.1:3000

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output file /var/log/caddy/analytics.log
        format console
    }
}

Den gleichen Caddy-Eintrag wie bei Plausible – die Domain ist dieselbe, nur der Backend-Port ändert sich (3000 statt 8080). Sollte das bereits einen Caddy-Eintrag für eine andere Subdomain sein, musst du eine eigene Subdomain (z.B. statistik.beispiel.de) wählen.

Schritt 3: Tracking-Skript einbinden

Umami-eigenes Skript (Pfad je nach Version zu prüfen, Standard oft /script.js oder ähnlich, nach je Dokumentation):


<script defer data-domain="beispiel.de" src="https://analytics.beispiel.de/script.js"></script>

Die data-domain Angabe ist das, was Umami als Domänen-Filter nutzt. Exakte Attribute je Version zu prüfen.

Schritt 4: Backup

PostgreSQL-Datenbank-Backup bei Umami:


docker compose exec db pg_dump -U umami_user umami_db > /backup/umami-$(date +%Y%m%d).sql

Das Volume umami-db (PostgreSQL-Daten) ist ebenfalls ein Backup-Ziel über Platte; eine gezielte Strategie zu planen.

Consent: Braucht eine selbst gehostete Analyse einen Consent-Banner?

Kurzantwort: Es kommt darauf an, was du trackst und unter welcher Rechtsgrundlage.

Wenn keine Cookies gesetzt werden. Selbst gehostete Analytics-Tools wie Plausible und Umami setzen in der Standardeinstellung keine Cookies. Das Tracking-Skript führt Server-Statistiken durch, ohne dem Browser ein Cookie auszuliefern. Das vereinfacht die Consent-Situation deutlich: Du musst nicht über „Cookie-Consent" diskutieren für die reine Analytics-Erhebung.

Aber: Die Abwesenheit von Cookies befreit nicht von der DSGVO. Die Rechtsgrundlage für die Datenverarbeitung (IP-Adressen, Browser-Hints, Referrer) muss dennoch bestehen. Das kann sein:

Praktische Empfehlung für kleine Betreiber:

Wichtig: Consent-Management-Tools (Banners) sind nicht das gleiche wie Consent-Pflicht für Analytics. Wenn du keine Cookies setzt und dein Analytics-Purpose auf reine Statistiken beschränkt ist, ist ein Banner nicht automatisch erforderlich – aber eine entsprechende Datenschutz-Grundlage und Dokumentation ist.

Datenschutz-Datenpunkte: was genau wird erhoben, wie lange, wie wird gelöscht

Für die Dokumentation (z.B. in der Datenschutzerklärung) und für interne Transparenz ist eine explizite Liste hilfreich.

Was die selbst gehostete Analyse typischerweise erhöht:

Was in der Regel NICHT erhoben wird (bei Privacy-First-Konfiguration):

Aufbewahrung:

Wie der Betreiber seine Rohdaten selbst löscht:

Was zu dokumentieren ist (in Datenschutzerklärung oder internes Datenschutz-Dokument):

Kosten und Betriebsaufwand: drei Varianten im Euro- und Megabyte-Vergleich

Die Kosten einer selbst gehosteten Analyse setzen sich zusammen aus Server-Kosten (VPS/VM), Betrieb (Updates, Backups, Monitoring), und gegebenenfalls Lizenzkosten (Geo-IP-Datenbank, falls Premium). Die Speicherbedarfe sind Schätzwerte unter Standardannahmen (einzelner Server, keine Redundanz, mittleres Traffic-Volumen).

Annahmen:

|| Variante | Server-Kosten (geschätzt) | Speicherbedarf (geschätzt, zu prüfen) | Betriebsaufwand (einmalig Setup / monatlich) |

||---|---|---|---|

|| Plausible CE | VPS 5–15 €/Monat (einzelner Server für Analytics + ggf. anderer Dienste) | Datenbank-Speicher: <500 MB/Monat bei moderatem Traffic (Schätzwert; SQLite/PostgreSQL, zu prüfen); App-Speicher wenige Dutzend MB | Setup: 1–2 Stunden; Wartung: Docker-Image-Updates regelmäßig, Backups der Datenbank; monatlicher Aufwand: ~30–60 Minuten (Updates + Backup-Prüfung) |

|| Umami | VPS 5–15 €/Monat (PostgreSQL + Umami-App auf gleichem oder getrenntem Host) | PostgreSQL-Datenbank bei moderatem Traffic <500 MB–1 GB/Monat (Schätzwert, zu prüfen); App-Speicher wenige Dutzend MB | Setup: 1–2 Stunden; Wartung: Image-Updates, Datenbank-Backups; monatlicher Aufwand: ~30–60 Minuten |

|| Matomo On-Premise | VPS 10–25 €/Monat (PHP/MySQL/MariaDB + mehr RAM, je nach Traffic; bei höherem Funktionsumfang eher 2 vCPU, 4 GB RAM empfohlen) | Datenbank bei moderatem Traffic 500 MB–2 GB/Monat (Schätzwert, zu prüfen); Overhead durch mehr Funktionsumfang und Archivierung | Setup: 2–4 Stunden (inkl. Datenbank-Setup, Admin-Wizard, Konfiguration); Wartung: PHP/Updates, Datenbank-Backups, fehlertolerante Archivierung; monatlicher Aufwand: ~1–2 Stunden |

Lizenzkosten:

Hinweis zu Traffic-Volumen. Diese Schätzspanne sind Richtwerte für kleine bis mittlere Websites (<100.000 Pageviews/Monat). Bei höherem Traffic skalieren die Datenbank-Bedürfnisse und RAM-Ansprüche; dann ist die VPS-Skalierung entsprechend höher. Das ist kein Fehler der Tools, sondern eine Funktion von Datenmenge.

Häufige Fehler und was tatsächlich passiert

1. Tracker-Skript lädt über HTTP statt HTTPS. Wenn das Tracking-Skript über http:// geladen wird, blockieren moderne Browser Mixed-Content; das Skript wird nicht geladen, und du siehst keine Daten. Lösung: Immer HTTPS in der src-Adresse, und Zertifikat für die Analyse-Domain einrichten.

2. BASE_URL stimmt nicht mit der Domain überein. Der Tracker verweist auf die BASE_URL aus der Konfiguration. Wenn BASE_URL https://analytics.altedomain.de ist und das Skript auf https://analytics.andere.de/js/script.js verweist, werden Requests an die falsche Domain gesendet, und du siehst nichts. Lösung: BASE_URL und das Skript-Src-Attribut müssen übereinstimmen.

3. Caddy-Richtung falsch. Der Reverse Proxy muss auf den lokalen Port des Analyse-Containers zeigen (z.B. 127.0.0.1:8080). Wenn stattdessen localhost oder 0.0.0.0 verwendet wird, ohne Bindung an localhost, kann der Container direkt erreichbar sein, und Caddy macht keinen Sinn. Ausehender Fehler: Caddy-Eintrag existiert, aber der Backend-Port ist falsch, und der Dienst ist nicht erreichbar.

4. Daten gespeichert, aber nicht gelöscht. Wenn du keine Aufbewahrungsregeln konfigurierst, wachsen Datenbanken über die Jahre. Dass die Daten nicht gelöscht werden, ist ein Betriebsfehler, kein Datenschutzfehler pro se – aber wenn du Datenschutz dokumentierst und dann nichts löschst, widerspricht das der Dokumentation. Lösung: Frühzeitig Aufbewahrungsregeln setzen und mit einem Backup-Backup-Strategie.

5. Backup-Dateien ohne Dauerhaftigkeit. Ein Backup-Skript, das Datenbankdumps in ein temporäres Directory schreibt, das nicht persistiert ist, führt dazu, dass Backups verschwinden. Lösung: Backups auf persistente Platte oder dedizierte Backup-Location speichern, und regelmäßig prüfen.

6. Geo-IP-Lizenz nicht eingerichtet, aber Land-Statistiken erwartet. Wenn Geo-IP nicht konfiguriert ist, bekommst du keine Land-Statistiken. Manche Betreiber erwarten Land-Statistiken von Haus aus; das ist nicht der Fall. Lösung: Geo-IP explizit aktivieren (MaxMind Lizenz oder andere Datenbank) und dokumentieren.

7. Matomo: Cookie-Tracking aktiviert, ohne Consent. Matomo kann Cookie-basiertes Tracking aktivieren. Wenn du das aktivierst und ES ist rechtlich erforderlich, fehlt der Consent. Lösung: Standard-Konfiguration auf cookie-freies Tracking stellen, oder Consent-Management einrichten.

8. Tracking-Skript nicht auf allen Seiten eingebunden. Wenn das Skript nur auf der Homepage steht, siehst du nur Traffic von der Homepage. Lösung: Skript auf allen getrackten Seiten einbinden (Header- oder Footer-Embed, templat-basiert).

FAQ: Häufige Fragen zu selbst gehosteter Webanalyse

Brauche ich eine GPU für selbst gehostete Webanalyse?

Nein. Webanalyse-Tools (Plausible, Umami, Matomo) sind server-side-Anwendungen, die CPU, RAM und Plattenplatz verbrauchen, aber keine GPU. Ein VPS oder eine Proxmox-VM mit ein paar GB RAM und einer gewöhnlichen CPU ist vollständig ausreichend. GPUs sind irrelevant für diese Workloads.

Darf ich selbst gehostete Analyse bei Firmenkunden einsetzen?

Grundsätzlich ja – das ist eine datenschutzrechtlich und lizenziell nutzbare Webanalyse. Die Fragen sind: (1) Konfiguration auf Datenschutz-Compliance (keine unnötigen personenbezogenen Daten, Aufbewahrungsfristen, rechtsgrundlagen-konforme Dokumentation), (2) Lizenz der Software (Open-Source-Lizenzen wie AGPL, MIT, GPL sind kommerziell einsetzbar; AGPL ist copyleft, das bedeutet, dass bei Weitergabe der Software Änderungen unter denselben Bedingungen veröffentlicht werden müssen – das ist relevant, wenn du die Software modifizierst und weitergibst, nicht wenn du sie nur im eigenen Betrieb nutzt. Zweideutigkeit mit dem Jen entweder eigenständig über Software-Lizenzprüfung klären). (3) Vertragsklauseln mit Kunden, die Auskunft über Datenverarbeitung erfordern. Für die meisten normalen Website-Kunden ist eine privacy-fokussierte selbst ge hostete Analyse ein legitimer Dienstleistungsbestandteil. Das ist keine Rechtsberatung; für konkrete Fälle konsultiere einen Datenschutz-Fachanwalt oder einen Datenschutzbeauftragten.

Kann ich mehrere Websites mit einer Analyse-Instanz tracken?

Ja, bei allen drei Tools mehr Domains verfolgen. Umami und Plausible erlauben die Angabe mehrerer Domains (Über data-domain bei Plausible; Umami hat einen Domain-Verwaltungsbereich im Admin). Matomo unterstützt mehrere Websites in einer Installation, konfiguriert über das Admin-Interface. Die Einzelheiten zu prüfen in der jeweiligen Dokumentation.

Was passiert, wenn meine Analyse-Domain ein ungültiges Zertifikat hat?

Der Tracker-Skript-Request wird blockiert oder führt zu Browser-Warnungen. Nutzer, die auf deine Website kommen, fordern das Skript von der Analyse-Domain. Wenn die Analyse-Domain kein gültiges Zertifikat hat, blockiert der Browser den Request (Mixed-Content-Block) oder zeigt eine Warnung an und das Skript wird nicht geladen. Die Folge: keine Daten im Dashboard. Lösung: Zertifikat einrichten und regelmäßig prüfen, dass es erneuert wird.

Ist ein nicht-authentifiziertes Analyse-Interface ein Sicherheitsproblem?

Ja, wenn das Analyse-Interface öffentlich erreichbar ist und keine Authentifizierung hat. Dann kann jeder Traffic-Daten sehen. Die Lösung: Analyse-Interface hinter Authentifizierung schützen (Benutzer-Login in der Analyse-Software), oder nur über das interne Netz oder VPN erreichbar machen. Bei einer öffentlichen Website-Analyse ist das Interface des Tools normalerweise nicht öffentlich sein; nur das Tracking-Skript ist öffentlich (das ist gewollt).

Interne Verlinkungsvorschläge zu vorhandenen BsN-Artikeln

Bildvorschläge

Bild 1

Bild 2

Bild 3

Bild 4

Bild 5

Quellen

Die Artikelinformationen stützen sich auf folgende öffentlich zugängliche Quellen (Zugriff zum Zeitpunkt der Erstellung; Angaben zur Version, Lizenz und Konfiguration sind aus diesen Quellen übernommen; aktuelle Änderungen sind zu prüfen):

1. Plausible Community Edition – Docker Compose und Konfiguration – GitHub-Repository plausible/community-edition (https://github.com/plausible/community-edition) und Wiki-Konfigurationsseite (https://github.com/plausible/community-edition/wiki/configuration) – Umgebungsvariablen BASE_URL, SECRET_KEY_BASE, HTTP_PORT, HTTPS_PORT, MaxMind GeoIP-Optionen.

2. Plausible: Self-hosted web analytics – https://plausible.io/self-hosted-web-analytics – AGPL Community Edition, Feature-Übersicht.

3. Umami – offizielle Dokumentation – https://docs.umami.is/docs/install – Docker-Compose-Beispiel mit PostgreSQL, Umgebungsvariablen DATABASE_URL, DATABASE_TYPE, UMAMI_SITE_URL, APP_SECRET, DISABLE_TELEMETRY.

4. Umami – GitHub – https://github.com/umami-software/umami – MIT-Lizenz, Versions- und Release-Status (zu prüfen; v3.x wurden im Zeitraum 2025–2026 referenziert).

5. Matomo On-Premise – Docker-Installation – Matomo GitHub-Repository matomo-org/docker (https://github.com/matomo-org/docker) und Matomo-Installations-FAQ (https://matomo.org/faq/how-to-install/install-matomo-with-docker/) – Docker Compose mit MariaDB/MySQL, Umgebungsvariablen MATOMO_DATABASE_HOST, MATOMO_DATABASE_USERNAME, MATOMO_DATABASE_PASSWORD, MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD.

6. Matomo – Datenschutz und DSGVO-Compliance – https://matomo.org/matomo-on-premise/ und entsprechende Dokumentation zur IP-Anonymisierung und Datenhaltung.

7. EuGH-Rechtsprechung zu IP-Adressen und personenbezogenen Daten – C-131/12 („Google-Musterentscheidung", 2014), C-311/18 („Schrems II", 2020) – grundlegendes Datenreferentum zu IP-Adressen als potenziell personenbezogene Daten; keine eigene Rechtsberatung.

8. DSGVO Art. 6 (Rechtsgrundlagen) – offizieller Text der DSGVO, zur Einordnung von Einwilligung vs. berechtzimmt Interesse bei Analysezwecken.

Hinweis zu Versionsangaben. Versionsnummern für Plausible CE, Umami und Matomo sind aus öffentlich zugänglichen Quellen zum Zeitpunkt der Recherche übernommen. Software-Versionen ändern sich regelmäßig; vor einem Setuperstellungstermin die aktuellen Tags im jeweiligen Repository zu prüfen.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.