Analytik ohne Überwachung

Sie haben eine Website. Wissen Sie, was darauf passiert?

Die meisten wissen es nicht. Diese hier wusste es auch nicht. Die Seite war live, Seiten kamen hinzu, Beiträge wurden geschrieben, Inhalte in fünf Sprachen übersetzt. Nichts davon ergab ein einziges Signal, ob jemand mitliest. Es gab keine Seitenaufrufe, keine Referrer-Daten und keine Möglichkeit zu erkennen, ob die Startseite ihre Aufgabe erfüllt oder ob die Besucher sofort wieder gehen.

Die naheliegende Antwort heißt Google Analytics. Ein Skript-Tag einbauen, Dashboard bekommen. Die meisten Websites machen genau das. Aber Google Analytics ist nicht kostenlos. Sie zahlen mit den Daten Ihrer Besucher. Google verknüpft jeden Seitenaufruf mit allem anderen, was es über diese Person weiß: Suchverlauf, YouTube-Gewohnheiten, Standortdaten. Ihre Website wird zu einem weiteren Datenpunkt in einem Profil, dem Ihr Besucher nie zugestimmt hat.

Hinzu kommt die DSGVO-Frage. Wenn Ihr Geschäft Besucher aus der EU bedient, verlangt Google Analytics ein rechtskonformes Einwilligungs-Banner. Die meisten Umsetzungen davon sind fehlerhaft. Das rechtliche Risiko ist real.

Die Seite brauchte Analytik. Nicht von Google.

Wie die Alternative aussieht

Das Werkzeug heißt Umami.

Open Source, MIT-lizenziert, datenschutzfreundlich, cookie-frei. Es läuft auf Ihrem eigenen Server. Die Daten werden inshallah niemals Ihre Infrastruktur verlassen. Kein Cookie-Hinweis nötig, weil es nichts gibt, dem zugestimmt werden müsste. Keine Cookies, keine personenbezogenen Daten, kein seitenübergreifendes Tracking.

Was es Ihnen liefert: Seitenaufrufe, Referrer, Aufschlüsselung nach Browser und Gerät, Herkunftsland und benutzerdefinierte Ereignisse. Sauberes Dashboard, Echtzeitdaten. Ein Geschäftsinhaber kann es inshallah öffnen und ohne Schulung verstehen, was passiert.

Was es nicht liefert: individuelle Besucherprofile, Sitzungsaufzeichnungen oder Heatmaps. Es identifiziert keine einzelnen Besucher. Es zeigt Ihnen, was auf Ihrer Seite passiert ist.

Umami lief bereits auf dem Server, hinter einem privaten VPN. Dort begannen die interessanten Entscheidungen.

Wer sieht das Dashboard?

Die meisten Anleitungen für selbstgehostete Analytik enden mit „rufen Sie ihre-domain.de auf und melden Sie sich an“. Ihr Analytik-Dashboard liegt damit im öffentlichen Internet. Jeder kann es finden. Automatisierte Scanner werden es entdecken. Bots probieren Standard-Zugangsdaten aus.

Das Dashboard ist ein Verwaltungswerkzeug. Es hat eine Anmeldeseite, eine Webanwendung und eine Datenbank dahinter. Jedes davon ist eine Angriffsfläche. Verpassen Sie ein Sicherheits-Update, ist das Dashboard und potenziell der Server angreifbar.

Die Umami-Instanz dieser Seite existiert nicht im öffentlichen Internet. Sie läuft hinter einem privaten Netzwerk (NetBird).

Das Dashboard ist nur von Geräten erreichbar, die Teil dieses Netzwerks sind. Für alle anderen gibt es keine Anmeldeseite, keine Fehlermeldung, keine Antwort. Die Domain löst zu einer IP auf, die nur innerhalb des VPN existiert; vom öffentlichen Internet aus gibt es nichts, womit man sich verbinden könnte. Es gibt nichts anzugreifen, weil es nichts zu finden gibt.

Das ist ein Prinzip, das weit über Analytik hinausgeht: Die höchste Form von Sicherheit ist, gar nicht erst sichtbar zu sein.

Was darunter läuft

Der Analytik-Dienst läuft als zwei Container in einem Podman-Pod: PostgreSQL und die Next.js-Anwendung, die sich einen Netzwerk-Namespace teilen, sodass die Anwendung die Datenbank erreicht, ohne sie je freizugeben. Alles läuft als dedizierter Service-Account-Benutzer ohne Shell, überwacht zusammen mit den anderen Diensten des Servers. Beszel verfolgt die Ressourcen-Auslastung (CPU, RAM, Festplatte, Netzwerk); Dozzle übernimmt die Logs (was der Dienst tut, auf welche Fehler er gestoßen ist). Ressourcen und Logs beantworten unterschiedliche Fragen, und ein Dienst, dem Sie in Produktion vertrauen, braucht beides.

Aber Besucher müssen ihn erreichen

Wenn der Analytik-Dienst vor dem öffentlichen Internet verborgen ist, wie schicken die Browser der Besucher dann Daten an ihn?

Sie sprechen nicht direkt mit dem Analytik-Dienst. Sie sprechen mit der Website selbst. Der Webserver (Caddy) wirkt als Proxy und leitet zwei spezifische Pfade intern an den Analytik-Dienst weiter. Mit den dokumentierten Standardwerten von Umami sieht das ungefähr so aus:

(umami_proxy) {
    handle /umami.js {
        reverse_proxy 127.0.0.1:8089
    }

    handle /api/send {
        reverse_proxy 127.0.0.1:8089
    }
}

Ein Pfad liefert das Tracking-Skript. Der andere empfängt die Analytik-Daten. Beide werden in den Caddy-Block der Seite eingebunden:

example.com {
    import tls_config
    root * /var/www/example.com
    import umami_proxy
    import static_files
}

Aus Sicht des Besuchers gehen beide Anfragen an dieselbe Domain wie die Website, ohne externen Dienst und ohne Cross-Origin-Anfrage. Der Browser lädt ein Skript von der Website und schickt Daten zurück an die Website.

Der Analytik-Dienst verarbeitet alles im Hintergrund, vollständig unsichtbar für den Besucher und vollständig unerreichbar von außen.

Für ein Geschäft sitzt damit kein Anbieter zwischen Ihnen und Ihrer Analytik. Preise können sich inshallah nicht über Nacht ändern, Funktionen können nicht abgekündigt werden, und das Produkt kann nicht aufgekauft und abgeschaltet werden. Die historischen Daten bleiben auf dem Server, den Sie kontrollieren, abfragbar und exportierbar zu Ihren Bedingungen.

Das unsichtbare Problem: Werbeblocker

Werbeblocker blockieren auch datenschutzfreundliche Analytik.

Umami verwendet keine Cookies. Es trackt keine Einzelpersonen. Es teilt keine Daten mit Dritten. Aber große Sperrlisten (EasyPrivacy, uBlock Origin, AdGuard) enthalten Regeln, die Umami gezielt treffen. Die Blocker bewerten keine Ethik. Sie gleichen Muster ab:

• Domain-Muster: alles mit analytics, stats oder tracking in der Subdomain
• Skript-Namen: script.js, ausgeliefert von einem bekannten Analytik-Werkzeug
• Endpunkt-Muster: /api/send steht speziell in Umamis Sperrlisten-Eintrag

Schätzungen zur Werbeblocker-Nutzung liegen üblicherweise im Bereich von 10 bis 40 Prozent, bei jüngerem und technisch versiertem Publikum höher. Diese Besucher tauchen niemals in Ihrer Analytik auf. Sie treffen Entscheidungen auf Basis unvollständiger Daten und wissen nicht, dass die Daten unvollständig sind.

Selbsthosten löst das Problem der Datensouveränität. Es löst nicht das Werbeblocker-Problem. Die Lösung muss weiter gehen.

Analytik unsichtbar machen

Die Lösung des Werbeblocker-Problems ist konzeptioneller, nicht technischer Natur. Lassen Sie die Analytik-Anfragen wie gewöhnliche Seiten-Assets aussehen. Ein anderer Name für das Skript, ein anderer Pfad für den Endpunkt, beide passend zu dem, was die Seite ohnehin schon lädt. Die Sperrlisten-Muster greifen dann nicht mehr.

Ein Reverse-Proxy bildet einen öffentlichen Pfad auf das ab, was die Anwendung intern erwartet. Der Browser sieht eine gewöhnliche Same-Origin-Anfrage; der Analytik-Dienst empfängt die Daten dahinter.

Wenn die Konfiguration Sie täuscht

Das hat am längsten gedauert. Hier zeigt sich der Unterschied zwischen „Ich bin einer Anleitung gefolgt“ und „Ich verstehe das System“.

Umami stellt zwei Umgebungsvariablen für die Umbenennung bereit. TRACKER_SCRIPT_NAME steuert den Dateinamen, unter dem der Server das Tracker-Skript ausliefert. COLLECT_API_ENDPOINT steuert den Pfad, an den der Tracker Daten sendet. Beides sieht aus wie gewöhnliche Laufzeit-Konfiguration.

TRACKER_SCRIPT_NAME ist es. Der Dateiname des Skripts wird entschieden, wenn der Server auf eine Anfrage antwortet. Variable setzen, neu starten, der Server liefert das Skript unter dem neuen Namen aus. Fertig.

COLLECT_API_ENDPOINT ist die Falle. Nach dem Setzen und Neustart gehorchte das serverseitige Routing. Anfragen am neuen Pfad wurden angenommen. Alles sah korrekt aus. Aber im Browser sendete der Tracker weiterhin an /api/send. Der Proxy kannte diesen Pfad nicht, also liefen die Daten ins Leere. Das Dashboard zeigte null Besucher. Keine Fehler irgendwo. Alles sah gut aus. Nichts funktionierte.

Der Quellcode erklärt es. Das Tracker-Skript wird beim Build des Docker-Images von Rollup zusammengebaut:

plugins: [
    replace({
      __COLLECT_API_ENDPOINT__: process.env.COLLECT_API_ENDPOINT || '/api/send',
    }),
]

Der Endpunkt wird als String-Literal in die JavaScript-Ausgabe einkompiliert. Zur Laufzeit ändert die Umgebungsvariable, wo der Server lauscht, aber der Browser führt vorkompilierten Code mit dem alten Pfad aus.

Das offizielle Docker-Image von ghcr.io/umami-software/umami wird mit fest einkompiliertem /api/send im Tracker-Skript ausgeliefert. COLLECT_API_ENDPOINT in der .env-Datei auf einen neuen Wert zu setzen, sorgt dafür, dass der Server Anfragen am neuen Pfad annimmt, aber der Tracker weist den Browser weiterhin an, an /api/send zu senden. Die beiden Seiten widersprechen sich lautlos.

Die Lösung ist, das Image aus dem Quellcode zu bauen und den neuen Wert zur Build-Zeit einzubacken. Umamis Dockerfile stellt diese Variable nicht ab Werk als Build-Argument bereit, aber zwei Zeilen in der Builder-Stufe schließen die Lücke:

ARG COLLECT_API_ENDPOINT=/api/send
ENV COLLECT_API_ENDPOINT=$COLLECT_API_ENDPOINT

ARG deklariert eine Build-Zeit-Variable; ENV macht sie für Rollup sichtbar, damit der Wert in das Tracker-Skript einkompiliert wird. Mit diesen beiden Zeilen ist das Bauen mit einem eigenen Wert ein einziges Flag:

podman build --build-arg COLLECT_API_ENDPOINT=<your-endpoint> -t umami-custom:latest .

Das Ergebnis ist dasselbe Image wie das offizielle, mit einer geänderten Zeichenkette in einer einzigen JavaScript-Datei.

Wenn der Host Podman rootless mit einem separaten Service-Account-Benutzer betreibt, ist das unter Ihrem Entwickler-Benutzer gebaute Image für diesen Service-Benutzer nicht sichtbar. Jeder rootless-Benutzer hat einen isolierten Image-Speicher. Die Übertragung sind zwei Befehle:

podman save localhost/umami-custom:latest -o /tmp/umami-custom.tar
cd /tmp && sudo -u umami podman load -i /tmp/umami-custom.tar

Das cd /tmp ist wichtig. sudo -u umami erbt standardmäßig das aktuelle Arbeitsverzeichnis des Aufrufers. Wenn Ihre Shell in Ihrem Entwickler-Home steht, schlägt das Laden mit cannot chdir: Permission denied fehl, weil der Service-Benutzer nicht in Ihr Home lesen darf. Der Fehler zeigt auf chdir, nicht auf sudo oder podman, daher ist die Ursache beim ersten Mal nicht offensichtlich.

Damit ist abgedeckt, wie ein eigener Umami-Build im Allgemeinen aussieht. Was diese Seite bei <your-endpoint> setzt und welcher passende Skript-Pfad vom öffentlichen Proxy umgeschrieben wird, steht nicht in diesem Beitrag.

Die Astro-Seite

Das Tracking-Skript muss auf jeder Seite geladen werden. In Astro heißt das, es in das gemeinsame Layout zu schreiben:

<script is:inline defer
  src="/umami.js"
  data-website-id="..."
  data-host-url="/">
</script>

Ein paar Hinweise dazu.

is:inline weist Astro an, das Skript-Tag genau so stehen zu lassen, wie es geschrieben ist, und es nicht zu verarbeiten oder zu bündeln. Der Tracker ist ein Fire-and-Forget-Drittanbieter-Skript; er braucht Astros Bündelungs-Pipeline nicht.

defer lädt das Skript, ohne das Rendern der Seite zu blockieren. Analytik darf eine Seite nie verlangsamen.

Die Astro-Referenz fügt einen Hinweis hinzu, der breiter klingt, als er reicht:

Will not be bundled into an external file. This means that attributes like defer which control the loading of an external file will have no effect.

Das beschreibt den Inline-Inhalt-Fall, in dem es keine externe Datei gibt, deren Laden man verzögern könnte. Für ein Skript mit src sagt is:inline nur, dass Astro das Tag nicht verarbeiten soll. Die dist-Ausgabe gibt es wortgetreu mit erhaltenem defer aus, und der Browser wendet das Attribut normal an.

data-host-url="/" überschreibt die Basis-URL, mit der der Tracker seinen Endpunkt zusammensetzt. Ohne das leitet der Tracker die Basis aus dem eigenen Skript-Speicherort ab. Ein Skript an einem Unterverzeichnis-Pfad (etwa /path/to/umami.js) würde an /path/to/api/... statt an /api/... senden. Den Wert auf / zu setzen (oder auf das Site-Root, was immer es ist), hält ihn korrekt.

Diese Seite hat außerdem eine eigenständige 404.html, die außerhalb der Astro-Pipeline liegt (eine Lösung für einen Routing-Bug des Frameworks, dokumentiert in einem eigenen Beitrag).

Dasselbe Skript-Tag wird dort manuell ergänzt, da es nicht durch das gemeinsame Layout läuft.

Warum das Rezept privat bleibt

Die konzeptionelle Lösung ist bereits benannt: das Skript und den Endpunkt wie gewöhnliche Seiten-Assets aussehen lassen. Diese Seite tut das. Die konkreten Namen und die Begründung, die Namenswahl an das Inhaltsprofil einer Seite zu binden, stehen nicht in diesem Beitrag.

Die Kosten dafür sind real. Das Upstream-Image lässt sich mit podman pull aktualisieren. Ein eigener Build heißt, bei jeder Upstream-Veröffentlichung neu aus dem Quellcode zu bauen.

Werbeblocker existieren, weil Tracker das Misstrauen verdient haben. Die meiste Analytik im öffentlichen Internet ist tatsächlich Überwachung: Drittanbieter-Skripte, Fingerprinting, Daten, die nach unten weitergereicht werden. Die Blocker können nicht unterscheiden, welche Seiten ehrlich sind. Sie blockieren die Muster.

Eine mustererkennende Gegenmaßnahme hilft ehrlichen und unehrlichen Seiten gleichermaßen. Ein öffentlicher Beitrag mit einem fertigen Rezept ist derselbe Schlüssel, den man einem Zahnarzt in die Hand drückt, der seine Termine zählt, und einer Tracking-Firma, die ihr Pixel zurück auf den Bildschirm einer Person schmuggeln will. Die erste Verwendung ist in Ordnung. Die zweite ist genau das, was die Blocker nötig gemacht hat.

Deshalb endet der Beitrag beim Prinzip.

Die vollständige Einrichtung, die konkreten Namen und die Überlegung, wie sie für eine bestimmte Seite gewählt werden, bleibt aus den genannten Gründen außerhalb der öffentlichen Dokumentation. Wenn das für Ihre Situation relevant ist, ist die Über mich-Seite der richtige Ausgangspunkt.

Was ist mit der Ladegeschwindigkeit?

Eine schnelle Seite hält Besucher. Langsame Seiten verlieren sie, fallen im Suchranking und wirken unprofessionell. Analytik muss gegen diese Kosten abgewogen werden.

Es gibt eine bekannte Lösung für schwere Analytik-Skripte: Partytown. Es verschiebt das Skript in einen Hintergrund-Thread, sodass die Hauptseite reaktionsfähig bleibt, während der Tracker seine Arbeit erledigt. Für Seiten, die etwa Google Tag Manager oder Facebook Pixel laden (50 bis 200 KB JavaScript, das fortlaufend pollt und einfügt), ist Partytown ein echter Geschwindigkeitsgewinn.

Dieses Setup braucht es nicht.

Der Umami-Tracker ist 2,63 KB unkomprimiert, 1,43 KB nach gzip. Er lädt mit defer, sendet beim Aufruf einer Seite eine einzige POST-Anfrage und beendet sich.

Partytown hinzuzufügen würde es sogar langsamer machen. Seine Laufzeit liegt bei rund 15 KB gzipped, das alles in den Browser des Besuchers geladen: ein 1,2 KB großer Loader plus ein 13,6 KB großer Worker, der Anfragen im Hintergrund abfängt. Nichts davon läuft auf dem Server. Ein 1,43 KB großes Skript in 15 KB Overhead zu verpacken, ist zehnmal so viel JavaScript wie das Skript selbst.

Die ehrliche Antwort ist die einfachere. Ein Tracker, klein genug, dass die Seite schnell bleibt, weil sie nichts ausbremst.

Worauf es hinausläuft

Jedes Stück dieses Setups löst ein bestimmtes Problem. Umami ersetzt Google Analytics ohne die Überwachung. Das private Netzwerk hält das Dashboard aus dem öffentlichen Internet heraus. Der Caddy-Proxy lässt Besucher die Analytik über die Website selbst erreichen. Das Werbeblocker-Problem hat eine Lösung, auf die dieser Beitrag zeigt, ohne sie auszubreiten. Jede Entscheidung für sich ist klein.

Zusammen entscheiden sie zwei Dinge: ob Sie wissen, was auf Ihrer Seite passiert, und ob die Beziehung zu Ihren Besuchern bei Ihnen bleibt.

Das ist es inshallah wert, richtig gemacht zu werden.