Was bauen wir?

Am Ende läuft Matomo 5.12 in Docker hinter deinem Traefik-Reverse-Proxy, erreichbar unter deiner eigenen (Sub-)Domain mit gültigem HTTPS-Zertifikat. Als Datenbank kommt MariaDB 11.4 dazu – beides in einem compose.yaml. Du bekommst ein vollwertiges Analytics-Dashboard, das Besucherzahlen, Herkunft, Geräte und beliebte Seiten auswertet – die Daten liegen ausschließlich auf deinem Server.

Der eigentliche Gewinn gegenüber Google Analytics ist der Datenschutz: Wir kontrollieren die IP-Anonymisierung und konfigurieren Matomo so, dass es ohne Cookies auskommt. Das ist die technische Grundlage dafür, dass du in vielen Fällen auf einen nervigen Consent-Banner verzichten kannst. Matomo ist dabei das Vollpaket – wenn du nur wissen willst, welche Seiten wie oft aufgerufen werden, reicht auch das deutlich schlankere HitKeep.

Voraussetzungen

• Ein abgesicherter Server mit Debian 13 und einem sudo-Benutzer
• Docker & Docker Compose installiert
• Ein laufender Traefik-Reverse-Proxy mit dem externen Netzwerk proxy und dem Zertifikats-Resolver le – Matomo hängt sich dort ein
• Eine (Sub-)Domain, deren A-/AAAA-Record auf deinen Server zeigt, z. B. statistik.DEINE-DOMAIN.de
• Eine funktionierende Backup-Strategie mit Restic – Analytics-Daten sammeln sich über Jahre an, die willst du nicht verlieren

Matomo ist genügsam: Für eine kleine bis mittlere Website reicht der VPS 1000 locker. Erst bei sehr viel Traffic oder wenn viele andere Dienste mitlaufen, lohnt der Blick auf mehr RAM – unser Server-Rechner hilft dir bei der Einschätzung.

Schritt für Schritt

Schritt 1: Projektordner anlegen und Netzwerk prüfen

Wir legen für Matomo einen eigenen Ordner unter /opt an – so bleibt jeder Dienst sauber getrennt:

mkdir -p /opt/matomo && cd /opt/matomo

Matomo muss ins selbe Docker-Netzwerk wie Traefik, damit der Proxy den Container erreicht. Prüfe, dass das Netzwerk proxy aus dem Traefik-Tutorial existiert:

docker network ls | grep proxy

Du solltest eine Zeile mit proxy sehen. Falls nicht, richte zuerst Traefik ein – ohne den Proxy bekommt Matomo kein Zertifikat.

Schritt 2: Passwörter in eine .env auslagern

Die Datenbank-Passwörter gehören nicht ins compose.yaml, sondern in eine separate .env. Wir lassen sie von openssl zufällig erzeugen:

{
  echo "DB_PASSWORD=$(openssl rand -hex 16)"
  echo "DB_ROOT_PASSWORD=$(openssl rand -hex 16)"
} > .env
chmod 600 .env

chmod 600 sorgt dafür, dass nur root die Datei lesen kann. Wirf einmal einen Blick hinein, damit du die Werte kennst:

cat .env

DB_PASSWORD=b51024e3f9a7c8d1e2f3a4b5c6d7e8f9
DB_ROOT_PASSWORD=1a2b3c4d5e6f70819a0b1c2d3e4f5061

Schritt 3: Die compose.yaml schreiben

Lege die Datei /opt/matomo/compose.yaml mit folgendem Inhalt an. Ersetze im Traefik-Label statistik.DEINE-DOMAIN.de durch deine echte (Sub-)Domain:

services:
  db:
    image: mariadb:11.4
    container_name: matomo-db
    command: --max-allowed-packet=64MB
    environment:
      MARIADB_DATABASE: matomo
      MARIADB_USER: matomo
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - db:/var/lib/mysql
    networks: [intern]
    restart: unless-stopped

  app:
    image: matomo:5.12-apache
    container_name: matomo
    environment:
      MATOMO_DATABASE_HOST: db
      MATOMO_DATABASE_ADAPTER: mysql
      MATOMO_DATABASE_USERNAME: matomo
      MATOMO_DATABASE_PASSWORD: ${DB_PASSWORD}
      MATOMO_DATABASE_DBNAME: matomo
    volumes:
      - app:/var/www/html
    depends_on: [db]
    networks: [proxy, intern]
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.matomo.rule=Host(`statistik.DEINE-DOMAIN.de`)"
      - "traefik.http.routers.matomo.entrypoints=websecure"
      - "traefik.http.routers.matomo.tls.certresolver=le"
      - "traefik.http.services.matomo.loadbalancer.server.port=80"

networks:
  proxy:
    external: true
  intern:
    external: false

volumes:
  db:
  app:

Das Wichtigste an dieser Datei:

• Zwei Netzwerke, bewusst getrennt. Nur der app-Container hängt im proxy-Netz und ist damit von außen erreichbar. Die Datenbank liegt im internen Netz intern und ist nicht über Traefik ansprechbar – genau richtig.
• Die MATOMO_DATABASE_*-Variablen füllen den Web-Installer im nächsten Schritt automatisch vor. Du musst die DB-Daten also nicht noch einmal von Hand eintippen.
• max-allowed-packet=64MB empfiehlt Matomo für die Datenbank, sonst kann der Import großer Berichte abbrechen.
• Kein Port nach außen. Weder Matomo noch die DB veröffentlichen einen Host-Port. Der einzige Weg hinein führt über Traefik und damit über HTTPS.

Schritt 4: Den Stack starten

docker compose up -d

Beim ersten Start lädt Docker die Images (rund 310 MB Download, entpackt gut 1,3 GB) und legt die Volumes an. Prüfe danach den Status:

docker compose ps

NAME        IMAGE                COMMAND                  SERVICE   CREATED          STATUS          PORTS
matomo      matomo:5.12-apache   "/entrypoint.sh apac…"   app       15 seconds ago   Up 13 seconds   80/tcp
matomo-db   mariadb:11.4         "docker-entrypoint.s…"   db        15 seconds ago   Up 14 seconds   3306/tcp

Beide Container sollten Up sein. Traefik erkennt den neuen Container automatisch über die Labels und holt im Hintergrund ein Let’s-Encrypt-Zertifikat für deine Domain. Das dauert meist nur wenige Sekunden. Prüfe von deinem eigenen Rechner aus, ob Matomo antwortet:

curl -sI https://statistik.DEINE-DOMAIN.de | head -1

HTTP/2 200

Ein HTTP/2 200 bedeutet: Zertifikat steht, Traefik routet, Matomo läuft. Falls stattdessen ein Zertifikatsfehler kommt, gib Traefik ein paar Sekunden mehr – siehe „Wenn es nicht funktioniert".

Schritt 5: Den Web-Installer durchklicken

Öffne https://statistik.DEINE-DOMAIN.de im Browser. Matomo begrüßt dich mit einem achtstufigen Einrichtungsassistenten.

Klicke dich durch die ersten Schritte:

1. Willkommen → Weiter.
2. Systemprüfung: Matomo prüft PHP-Version, Erweiterungen und Schreibrechte. Dank des offiziellen Images bleibt die Liste fehlerfrei. Eine gelbe Warnung siehst du trotzdem: Erzwungene SSL Verbindung. Sie ist hier normal und kein Grund abzubrechen – Matomos eigene Option force_ssl ist schlicht noch nicht gesetzt, ausgeliefert wird trotzdem nur über HTTPS. Wir räumen sie in Schritt 7 aus. → Weiter.
3. Datenbank einrichten: Die Felder sind bereits ausgefüllt (das erledigen die MATOMO_DATABASE_*-Variablen aus der compose.yaml). Kontrolliere kurz, dass als Server db steht, und klicke Weiter.
4. Tabellen anlegen: Matomo legt sein Datenbankschema an. → Weiter.

Jetzt legst du deinen Hauptadministrator an. Wähle einen Benutzernamen, ein starkes Passwort und eine echte E-Mail-Adresse (über sie kommen Sicherheits- und Update-Hinweise).

Danach richtest du die erste Website ein, die du tracken willst. Neben Name und URL ist die Zeitzone ein Pflichtfeld: Lässt du sie auf der Vorauswahl stehen, weist das Formular dich mit Zeitzone der Webseite ist nicht gültig zurück. Sie entscheidet, wann für deine Berichte ein neuer Tag beginnt – für eine deutsche Website also Deutschland – Berlin.

Schritt 6: Den Tracking-Code einbauen

Im vorletzten Schritt zeigt dir Matomo den JavaScript-Tracking-Code. Das ist das kleine Snippet, das in jede Seite deiner Website gehört – idealerweise direkt vor </head>:

<!-- Matomo -->
<script>
  var _paq = window._paq = window._paq || [];
  _paq.push(['disableCookies']);
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//statistik.DEINE-DOMAIN.de/";
    _paq.push(['setTrackerUrl', u+'matomo.php']);
    _paq.push(['setSiteId', '1']);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<!-- End Matomo Code -->

Die Zeile _paq.push(['disableCookies']); (im Original-Snippet nicht enthalten) haben wir bewusst ergänzt: Damit verzichtet Matomo komplett auf Cookies – ein wichtiger Baustein für den Betrieb ohne Consent-Banner. Betreibst du deine Website mit einem CMS wie WordPress, gibt es fertige Plugins („Matomo for WordPress", „Connect Matomo"), die das Snippet automatisch einbinden. Nach dem letzten Schritt („Fertig") meldest du dich mit deinem eben angelegten Konto an und landest im Dashboard.

Das Dashboard bündelt die wichtigsten Berichte: Besuche in Echtzeit, den Graph der letzten Besuche, die Besucherübersicht, eine Besucherkarte und unter Kanaltypen die Herkunft der Besucher (Suchmaschine, Direktzugriff, Verweis). Über das Menü links kommst du tiefer – Besucher (Geräte, Browser, Standort), Verhalten (Seiten, Ein- und Ausstiege) und Akquisition (welche Kanäle Besucher bringen). Genau die Fragen, die Google Analytics beantwortet – nur eben auf deinem Server.

Schritt 7: Datenschutz-Einstellungen prüfen (der wichtige Teil)

Matomo 5.12 startet datenschutzfreundlicher, als viele erwarten: Die IP-Anonymisierung ist ab Werk aktiv. Trotzdem gehst du die Seite einmal durch – erstens, um es mit eigenen Augen gesehen zu haben, zweitens, weil dort ein Schalter liegt, der dein cookieloses Tracking wirklich absichert. Öffne oben rechts Verwaltung (Zahnrad) → im Menü links Privatsphäre → Daten anonymisieren.

Drei Stellschrauben sind entscheidend:

• Anonymisiere die IP-Adresse von Besuchern: steht schon auf Ja, maskiert werden standardmäßig 2 byte(s) – aus 203.0.113.45 wird also 203.0.xxx.xxx (Matomo markiert diese Stufe selbst als Empfohlen). Kontrolliere nur, dass das so geblieben ist; damit ist der einzelne Besucher nicht mehr identifizierbar.
• Tracking ohne Cookies erzwingen: einschalten. Matomo ergänzt dann matomo.js serverseitig um den passenden Code und ignoriert Tracking-Cookies zusätzlich beim Empfang. Das wirkt auch dann noch, wenn irgendwo doch das Original-Snippet ohne disableCookies landet – ein Sicherheitsnetz für den Punkt, an dem dein Consent-Banner-Verzicht hängt.
• „Do Not Track": liegt unter Privatsphäre → Benutzer Opt-Out. Matomo stuft die Unterstützung inzwischen selbst als veraltet ein – weil Browser das Signal ungefragt senden oder gar nicht mehr unterstützen, „empfehlen wir nicht mehr, diese Option zu aktivieren". Verlass dich also nicht darauf. Der belastbare Weg steht auf derselben Seite: der Opt-out-Baustein (iframe oder eigenes Formular), den du in deine Datenschutzerklärung einbaust.

Bleibt noch der Schalter, den die Systemprüfung aus Schritt 5 angemahnt hat: force_ssl. Er weist unverschlüsselte Zugriffe in Matomo selbst ab, statt sich allein auf Traefik zu verlassen. In der Oberfläche gibt es ihn nicht, er steht in Matomos config/config.ini.php im Volume:

cd /opt/matomo
docker compose exec -u www-data app sed -i '/^\[General\]/a force_ssl = 1' config/config.ini.php

sed hängt die Zeile force_ssl = 1 direkt unter den Abschnitt [General]; -u www-data sorgt dafür, dass die Datei ihrem bisherigen Besitzer gehört und Matomo sie weiter schreiben kann. Lade danach das Dashboard neu – unter Verwaltung → Diagnose → Systemprüfung ist die Warnung Erzwungene SSL Verbindung verschwunden.

Schritt 8: Berichte per Cron archivieren

In der Grundeinstellung berechnet Matomo seine Berichte „on the fly", sobald jemand das Dashboard öffnet. Das wird bei mehr Traffic langsam und ist offiziell nicht empfohlen. Besser: ein Cronjob rechnet die Berichte regelmäßig im Hintergrund vor.

Trage dazu auf dem Host einen Cronjob ein, der alle 15 Minuten das Archivierungskommando im Container ausführt:

crontab -e

Füge diese Zeile hinzu (Domain anpassen):

*/15 * * * * cd /opt/matomo && docker compose exec -T -u www-data app ./console core:archive --url=https://statistik.DEINE-DOMAIN.de >> /opt/matomo/archive.log 2>&1

Das Log landet bewusst in /opt/matomo/archive.log und nicht unter /var/log: Läuft dein Cron als sudo-Benutzer (nicht als root), scheitert ein Schreibzugriff auf /var/log still. In /opt/matomo hast du Schreibrechte, und du findest das Log direkt beim Projekt.

Anschließend schaltest du die alte Betriebsart ab: Verwaltung → Allgemeine Einstellungen → Archivierungseinstellungen, dort „Berichte archivieren, wenn diese im Browser angezeigt werden" auf Nein stellen und speichern. So bleibt das Dashboard auch bei viel Traffic schnell – und die Systemprüfung meldet nicht mehr, dass Browser- und Cron-Archivierung gleichzeitig laufen.

Wenn es nicht funktioniert

Wartung & Backups

Updates sind bei Matomo unkritisch, aber regelmäßig fällig – etwa monatlich erscheint eine neue Version. Weil wir den Image-Tag auf 5.12 gepinnt haben, ziehst du Sicherheits-Patches innerhalb der 5.12-Reihe so:

cd /opt/matomo && docker compose pull && docker compose up -d

Beim ersten Aufruf nach einem Update prüft Matomo, ob ein Datenbank-Upgrade nötig ist, und führt es nach einem Klick aus.

Backups umfassen zwei Dinge: die Datenbank (alle Besuchsdaten) und das app-Volume (deine Konfiguration in config/config.ini.php). Erstelle regelmäßig einen Datenbank-Dump …

docker compose exec -T db sh -c 'exec mariadb-dump -u matomo -p"$MARIADB_PASSWORD" matomo' > /opt/matomo/dump.sql

… und nimm diesen Dump zusammen mit dem Ordner /opt/matomo in deine Restic-Off-Site-Backups auf. Ein netcup-Snapshot des ganzen Servers ist eine gute Ergänzung, aber kein Ersatz für ein echtes Off-Site-Backup – liegt beides beim selben Anbieter, sind bei einem Totalausfall auch beide weg.

Laufender Betrieb: Behalte den Speicherplatz im Auge – bei viel Traffic wächst die Datenbank. Die automatische Löschung alter Rohdaten (Schritt 7) und der Archivierungs-Cron (Schritt 8) halten Matomo dauerhaft schlank und schnell. Damit du merkst, wenn Matomo einmal nicht erreichbar ist, nimm die Instanz in dein Uptime-Kuma-Monitoring auf – ein einfacher HTTP-Check auf deine Statistik-Domain genügt.

Und der wichtigste Betriebs-Hinweis zum Schluss: Matomo lebt vom Datenschutz-Versprechen. Wer den Dienst einmal aufgesetzt hat, sollte die Anonymisierungs- und Lösch-Einstellungen aus Schritt 7 nicht wieder aufweichen – sie sind der Grund, warum du überhaupt ohne Consent-Banner auskommst. Prüfe nach jedem größeren Update kurz, dass sie noch stehen.

Was bauen wir?

Am Ende läuft HitKeep 2.12.0 als einzelner Container hinter deinem Traefik, erreichbar unter https://DEINE_DOMAIN. Du bekommst ein Dashboard mit Seitenaufrufen, Besuchern, Verweildauer, Referrern und Geräten – gespeist von einem winzigen JavaScript-Snippet, das du in deine Website einbaust. HitKeep arbeitet cookielos (kein Consent-Banner nötig) und speichert alles lokal in einer eingebetteten DuckDB-Datenbank. Das Image ist ein schlankes Distroless-Image (rund 71 MB), das komplett ohne externe Datenbank auskommt – ideal für einen kleinen VPS.

Voraussetzungen

• Ein Server mit Debian 13 und laufendem Docker (getestet auf einem netcup VPS).
• Ein Reverse Proxy mit Traefik, der TLS-Zertifikate per Let’s Encrypt holt. HitKeep bringt keinen eigenen HTTPS-Server mit – Traefik übernimmt die Verschlüsselung. Dieses Tutorial setzt das dort beschriebene proxy-Netz und den Resolver le voraus.
• Eine (Sub-)Domain, die auf deinen Server zeigt (A-/AAAA-Record). Wir nutzen im Beispiel DEINE_DOMAIN.
• Die Website, die du messen willst – HitKeep misst jede Seite, in die du das Snippet einbaust.

Schritt für Schritt

Schritt 1: JWT-Secret erzeugen

HitKeep signiert die Login-Sitzungen mit einem geheimen Schlüssel. Erzeuge dir einen zufälligen 32-Byte-Wert – nicht ausdenken, sondern generieren:

openssl rand -hex 32

Du bekommst eine 64 Zeichen lange Hex-Zeichenkette. Kopiere sie – sie kommt gleich in die Konfiguration. Ändert sich dieses Secret später, werden alle offenen Logins ungültig; halte es also stabil und geheim.

Schritt 2: Compose-Datei anlegen

Lege einen Ordner für den Stack an und wechsle hinein:

mkdir -p /opt/hitkeep && cd /opt/hitkeep

Erstelle die Datei compose.yaml. Ersetze DEINE_DOMAIN durch deine echte Domain und DEIN_JWT_SECRET durch den Wert aus Schritt 1:

services:
  hitkeep:
    image: pascalebeier/hitkeep:2.12.0
    container_name: hitkeep
    restart: unless-stopped
    environment:
      HITKEEP_PUBLIC_URL: https://DEINE_DOMAIN
      HITKEEP_JWT_SECRET: DEIN_JWT_SECRET
      HITKEEP_TRUSTED_PROXIES: 172.16.0.0/12
      HITKEEP_DB_PATH: /var/lib/hitkeep/data/hitkeep.db
      HITKEEP_DATA_PATH: /var/lib/hitkeep/data
      HITKEEP_ARCHIVE_PATH: /var/lib/hitkeep/archive
      HITKEEP_BACKUP_PATH: /var/lib/hitkeep/backups
    volumes:
      - hitkeep_data:/var/lib/hitkeep/data
      - hitkeep_archive:/var/lib/hitkeep/archive
      - hitkeep_backups:/var/lib/hitkeep/backups
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.hitkeep.rule=Host(`DEINE_DOMAIN`)"
      - "traefik.http.routers.hitkeep.entrypoints=websecure"
      - "traefik.http.routers.hitkeep.tls.certresolver=le"
      - "traefik.http.services.hitkeep.loadbalancer.server.port=8080"
    networks: [proxy]
volumes:
  hitkeep_data: {}
  hitkeep_archive: {}
  hitkeep_backups: {}
networks:
  proxy:
    external: true

Die wichtigsten Stellen im Detail:

• HITKEEP_PUBLIC_URL ist die öffentliche Adresse, unter der HitKeep erreichbar ist. Daraus baut die Oberfläche später den Tracking-Snippet und die Links. Sie muss exakt der URL entsprechen, unter der du HitKeep aufrufst – sonst kommst du in eine Login-Schleife.
• HITKEEP_TRUSTED_PROXIES ist der Knackpunkt hinter einem Reverse Proxy: Ohne diesen Wert sieht HitKeep als Absender jedes Aufrufs nur die interne IP von Traefik – dann landen alle Besucher als ein einziger. 172.16.0.0/12 deckt die Docker-Netze ab, sodass HitKeep dem X-Forwarded-For-Header von Traefik vertraut und die echte Besucher-IP auswertet.
• loadbalancer.server.port=8080 sagt Traefik, dass HitKeep intern auf Port 8080 lauscht. Der Container veröffentlicht selbst keine Ports nach außen – der Zugriff läuft ausschließlich über Traefik.
• Die vier _PATH-Variablen legen Datenbank, Daten, Archiv und Backups unter /var/lib/hitkeep/ ab; die passenden Volumes sorgen dafür, dass sie ein Update oder einen Neustart überleben.

Schritt 3: Stack starten und auf TLS warten

Starte den Container:

docker compose up -d

Prüfe nach ein paar Sekunden den Status:

docker compose ps

Du solltest den Container als healthy sehen – HitKeep bringt einen eigenen Healthcheck mit:

NAME      IMAGE                         SERVICE   STATUS                   PORTS
hitkeep   pascalebeier/hitkeep:2.12.0   hitkeep   Up 18 minutes (healthy)  7946/tcp, 8080/tcp

Traefik holt jetzt im Hintergrund das Let’s-Encrypt-Zertifikat für deine Domain. Prüfe von deinem eigenen Rechner aus, dass die Auslieferung des Tracking-Skripts steht:

curl -sI https://DEINE_DOMAIN/hk.js

Erwartete Ausgabe (gekürzt) – Status 200 und ein text/javascript-Typ, aggressiv gecacht:

HTTP/2 200
content-type: text/javascript; charset=utf-8
cache-control: public, max-age=31536000, immutable

Schritt 4: Admin-Konto anlegen

Rufe https://DEINE_DOMAIN im Browser auf. Beim allerersten Start begrüßt dich HitKeep mit der Ersteinrichtung. Lege hier dein Administrator-Konto an – Name, E-Mail-Adresse und ein Passwort. Nimm eine lange Passphrase oder ein per Passwortmanager erzeugtes Zufallspasswort; dieses Konto sieht sämtliche Statistiken und darf nicht an einem schwachen Passwort hängen:

Schritt 5: Website anlegen und Tracking-Code holen

Nach dem Login klickst du links oben bei Sites auf das Plus und legst deine Website an – als Domain trägst du die Domain der Seite ein, die du messen willst (z. B. DEINE_WEBSITE).

Öffne dann die Site-Einstellungen und wechsle auf den Reiter Tracking. Dort findest du den Live tracking verifier (der auf den ersten Treffer wartet) und die Konfiguration des Tracking-Codes samt Tracker-Host:

Der einzubauende Code besteht aus einer einzigen Zeile. HitKeep braucht keine Site-ID im Snippet – die Zuordnung passiert automatisch über die Domain der Seite, auf der das Skript läuft:

<script async src="https://DEINE_DOMAIN/hk.js"></script>

Automatisches Event-Tracking (ausgehende Klicks, Downloads, Formular-Absendungen) ist standardmäßig aktiv. Optional kannst du auf demselben Reiter „Web Vitals" einschalten, um Ladezeiten (LCP, INP, CLS, FCP, TTFB) mitzumessen, oder „Collect DNT" aktivieren, wenn du auch Besucher mit „Do Not Track" zählen willst – aus Datenschutzsicht ist die Voreinstellung (DNT respektieren) die sauberere.

Schritt 6: Tracking-Code in die Website einbauen

Füge die Snippet-Zeile aus Schritt 5 in den <head> deiner Website ein – bei einer statischen Seite direkt ins HTML-Template, bei einem CMS in den Kopfbereich bzw. ein „Custom HTML"-Feld. Durch das async-Attribut blockiert das Skript den Seitenaufbau nicht.

Rufe danach eine Seite deiner Website im Browser auf. Der Live tracking verifier aus Schritt 5 sollte innerhalb weniger Sekunden von „Waiting" auf einen ersten Treffer springen – das ist die Bestätigung, dass die Kette Website → hk.js → HitKeep steht.

Schritt 7: Das Dashboard prüfen

Sobald Treffer eintrudeln, füllt sich das Dashboard. Unter Dashboard siehst du die Kennzahlen deiner Website – Live-Besucher, Seitenaufrufe, eindeutige Sitzungen, Absprungrate, Verweildauer und den Traffic-Verlauf:

Weiter unten listet Latest Hits die einzelnen Aufrufe mit Pfad, Zeitpunkt, Referrer und Gerät auf – hier siehst du auf einen Blick, über welche Suchmaschinen und Verweise deine Besucher kommen:

Damit steht deine selbst gehostete Statistik: Jeder Aufruf deiner Website landet direkt in deiner eigenen Datenbank, ohne Umweg über Dritte.

Schritt 8: Mehr als nur Seitenaufrufe

Für den Anfang reichen Seitenaufrufe und Referrer – HitKeep kann aber deutlich mehr, und die Bausteine dafür findest du in der linken Navigation. Ein paar, die sich für die meisten Seiten lohnen:

• Goals (Ziele): Definiere ein Ereignis als Ziel – etwa das Absenden eines Kontaktformulars oder einen Klick auf „Kaufen". So misst du nicht nur, wie viele kommen, sondern wie viele das tun, was du willst.
• Funnels (Trichter): Verkette mehrere Schritte (Startseite → Produktseite → Warenkorb) und sieh, an welcher Stelle Besucher abspringen.
• Events: Neben den automatisch erfassten Ereignissen (ausgehende Klicks, Downloads, Formulare) kannst du eigene Ereignisse aus deinem Frontend senden.
• Web Vitals: Schaltest du sie im Tracking-Reiter ein, siehst du echte Ladezeiten deiner Besucher (LCP, INP, CLS) statt synthetischer Laborwerte.
• UTM: Kampagnen-Parameter (utm_source, utm_medium, utm_campaign) werden ausgewertet – praktisch, um Newsletter- oder Social-Reichweite auseinanderzuhalten.
• Email Reports: Lass dir eine Zusammenfassung regelmäßig per E-Mail schicken, statt selbst ins Dashboard schauen zu müssen.

Eine einzelne HitKeep-Instanz verwaltet außerdem beliebig viele Websites: Über das Plus bei Sites legst du weitere an, jede mit eigenem Snippet und eigenem Dashboard. Du brauchst also keinen zweiten Container, wenn du mehrere Projekte messen willst.

Wenn es nicht funktioniert

Wartung & Backups

Updates: HitKeep bewegt sich in der 2.x-Reihe zügig weiter – schau etwa monatlich in die Releases. Für ein Update setzt du den neuen Tag in der compose.yaml (ersetze 2.12.0 durch die neue Version) und ziehst ihn:

docker compose pull && docker compose up -d

Weil die Daten in Volumes liegen, bleiben deine Statistiken dabei erhalten. Pinne die Version bewusst auf einen festen Tag statt latest, damit ein Neustart dir nicht ungeplant eine neue Hauptversion unterschiebt.

Backups: Deine gesamte Statistik steckt in einer eingebetteten DuckDB-Datei (hitkeep.db samt Write-Ahead-Log hitkeep.db.wal) unter /var/lib/hitkeep/data. Sichere deshalb nicht eine Einzeldatei, sondern das komplette Volume hitkeep_data regelmäßig – am saubersten mit restic. Weil diese Dateien im laufenden Betrieb beschrieben werden, sicherst du sie am konsistentesten, indem du den Container kurz stoppst (docker compose stop), das Volume sicherst und wieder startest – oder das von HitKeep unter HITKEEP_BACKUP_PATH abgelegte Backup mit einbeziehst. Ein Backup, das du nie zurückgespielt hast, ist nur ein Hoffnungsschimmer: Teste die Wiederherstellung einmal auf einem Testsystem.

Aufräumen: Die Datenbank wächst mit dem Traffic. Behalte die Größe der Volumes im Blick (docker system df -v) und plane bei viel Traffic genügend Speicher ein.