SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-28

Self-hosted Webanalyse: Welches Tool passt zum VPS?

Vergleichen Sie Plausible, Umami, Matomo, GoatCounter und GoAccess nach RAM, Datenbank, Speicherwachstum, Reverse Proxy und Adblocker-Lücke.

Welches Self-Hosting-Webanalyse-Tool sollten Sie auf einem VPS betreiben?

Self-hosted-Webanalyse lässt sich in zwei Gruppen einteilen. Die falsche Gruppe zu wählen kostet Sie mehr, als das falsche Produkt zu wählen. Die eine Gruppe führt ein kleines Skript im Browser des Besuchers aus und speichert die Daten, die dieses Skript meldet. Die andere Gruppe liest das Access-Log, das Ihr Webserver bereits schreibt. Alles Weitere, einschließlich der Datenbank und des benötigten Arbeitsspeichers, ergibt sich aus dieser grundlegenden Entscheidung.

Die kurze Antwort für einen kleinen Server: GoatCounter und Medama passen auf 1 GB, weil jedes Tool aus einem Prozess besteht, der auf eine Datei zugreift. Umami fügt einen Postgres-Container hinzu und stellt ein Dashboard bereit, das auch technisch nicht versierte Personen verstehen. Plausible Community Edition und Rybbit verwenden beide ClickHouse. Planen Sie deshalb 2 GB RAM oder mehr ein. Matomo ist das vollständige Produkt und benötigt einen Server, der auf Ihr Datenaufkommen ausgelegt ist. GoAccess fügt der Seite überhaupt nichts hinzu, weil es ein bereits vorhandenes Log liest.

Script-Tag oder Server-Log: Was die beiden jeweils erfassen können

Ein Script-Tag misst Browser. Die Seite wird geladen, das Script wird ausgeführt und es sendet eine Anfrage an Ihren Collector. Alles, was diese Kette unterbricht, bleibt für Sie unsichtbar: deaktiviertes JavaScript, eine Filterliste, die die Anfrage blockiert, eine fehlgeschlagene Anfrage an den Collector oder ein Crawler, der keine Scripts ausführt.

Ein Log-Parser misst Anfragen. Ihr Webserver schreibt für jede Anfrage eine Zeile, unabhängig davon, ob Sie zusätzliche Software installieren. Die Daten liegen daher bereits auf der Festplatte. Der Parser erfasst jeden Crawler und jeden Abruf einer Datei, die kein Script-Tag enthält. Er kann nicht sehen, was im Browser passiert ist. Außerdem erkennt er keine Seite, die aus dem Browser-Cache oder von einem vorgeschalteten CDN (Content Delivery Network) ausgeliefert wurde, weil diese Anfrage Ihren Server nie erreicht hat.

Die beiden Zahlen werden nicht übereinstimmen, und keine von beiden ist deshalb falsch. Matomo kann beides. In der Dokumentation wird beschrieben, welche Informationen beim Log-Import im Vergleich zum JavaScript-Tracker fehlen: Bildschirmauflösung und Seitentitel, Ereignisse, Content-Tracking, Heatmaps, Sitzungsaufzeichnungen und Formularanalysen. Das ist der Preis dafür, Anfragen statt Browser zu zählen.

Bot-Traffic ist die andere Ursache für die Abweichung. Auf Logs basierende Zählungen schließen Crawler ein, sofern Sie sie nicht filtern. Auf einer gewöhnlichen Website ist der Anteil der Crawler groß genug, um Ihre Schlussfolgerungen zu verändern. GoAccess und der Log-Import von Matomo filtern bekannte Bots. Keines der beiden Tools kann einen Crawler filtern, der seinen User-Agent fälscht. Das ist ein guter Grund, jede auf Logs basierende Zählung mit dem Blockieren von AI-Crawlern auf dem Server zu kombinieren und das Log erst nach der Blockierung statt davor auszuwerten.

GoAccess: Auswertung aus dem bereits vorhandenen Log

Installieren Sie GoAccess aus dem eigenen Debian- und Ubuntu-Repository des Projekts, da die Distributionspakete hinter den Releases zurückbleiben.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Verweisen Sie GoAccess anschließend auf das Log und schreiben Sie einen statischen Bericht.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Dieser Befehl schlägt für einen normalen Benutzer mit Permission denied fehl, da das nginx-Log unter Ubuntu root gehört und die Gruppe adm verwendet. Fügen Sie sich mit sudo usermod -aG adm $USER dieser Gruppe hinzu. Melden Sie sich anschließend ab und wieder an, da die Gruppenmitgliedschaft beim Anmelden eingelesen wird. Führen Sie id aus und prüfen Sie, ob adm in der Liste erscheint, bevor Sie den Befehl erneut ausführen.

Ein Bericht über das aktive Log umfasst nur Einträge, die logrotate noch nicht verschoben hat. Die Anfragen von gestern befinden sich in access.log.1. Ältere Logs sind komprimiert. Für eine Wochenansicht müssen daher auch die rotierten Dateien eingelesen werden.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

Es gibt außerdem den Live-Modus --real-time-html, der die Seite über einen WebSocket aktualisiert. Dafür sind ein zweiter Port und eine eigene Proxy-Regel erforderlich. Für die meisten Websites reicht ein stündlicher Bericht, den cron schreibt. Dadurch gibt es weniger abzusichern.

GoatCounter: ein Go-Binary und eine SQLite-Datei

GoatCounter wird als statisch kompiliertes Binary veröffentlicht. Daher muss keine Laufzeitumgebung installiert werden. Laden Sie einen Build von der Release-Seite herunter und führen Sie ihn aus. Alternativ können Sie das Image verwenden.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Als Binary ausgeführt, lauscht goatcounter serve auf Port 8080 und erstellt die SQLite-Datei unter ./goatcounter-data/db.sqlite3. Erstellen Sie die erste Site über die Kommandozeile und nicht über den Webassistenten, wenn die Instanz bereits hinter einem Proxy läuft.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

GoatCounter kann sein eigenes Zertifikat mit goatcounter serve -listen=:443 -tls=tls,rdr,acme verwalten. Dabei wird ACME (Automatic Certificate Management Environment) verwendet. Das ist auf einem Server sinnvoll, der keine anderen Dienste bereitstellt. Wenn nginx oder Caddy Port 443 bereits verwendet, lassen Sie GoatCounter auf Port 8080 lauschen und leiten Sie Anfragen stattdessen per Proxy dorthin weiter. Das Tracking-Script ist laut eigener Angabe des Projekts etwa 3.5K groß. Für Seiten ohne JavaScript gibt es außerdem ein Tracking-Pixel. Wenn SQLite bei einer stark ausgelasteten Site zum begrenzenden Faktor wird, kann dasselbe Binary mit goatcounter serve -db 'postgresql+dbname=goatcounter' PostgreSQL verwenden. Backups bestehen aus einer Dateikopie. Das ist der entscheidende Vorteil dieses Tool-Aufbaus.

Medama: ein einzelner Container mit einem Speicherbedarf von 256 MB

Medama ist hier die neueste Option als einzelnes Binary. Das Programm verwendet konstruktionsbedingt keine Cookies. Laut Projekt ist der Tracker kleiner als 1 KB. Außerdem sollen kleine Websites auf virtuellen Maschinen mit 256 MB Arbeitsspeicher laufen. Das sind veröffentlichte Angaben des Projekts und keine für diese Anleitung gemessenen Werte.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

Der offizielle Befehl veröffentlicht den Port als 8080:8080. Das Loopback-Präfix oben ist absichtlich gesetzt. Der Abschnitt zum Reverse Proxy erklärt den Grund. Die erste Anmeldung erfolgt mit admin und dem Passwort CHANGE_ME_ON_FIRST_LOGIN. Der Name dieses Passworts ist die Anweisung.

Eine dokumentierte Fehlerbedingung wird Sie wahrscheinlich betreffen. Die Anmeldung funktioniert nur über HTTPS oder auf localhost. Wenn Sie den Proxy vor dem Zertifikat einrichten, weist das Formular ein korrektes Passwort zurück, ohne den Grund auszugeben. Schließen Sie zuerst die TLS-Konfiguration ab. Melden Sie sich danach an.

Umami: PostgreSQL und ein Dashboard, das viele erkennen

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Damit startet die Anwendung auf Port 3000 zusammen mit einem PostgreSQL-Container. Die Dokumentation nennt PostgreSQL v12.14 als Mindestversion. Wenn Sie stattdessen aus dem Quellcode bauen, benötigen Sie Node.js 18.18 oder neuer. Es gibt ein vorkompiliertes Image, docker.umami.is/umami-software/umami:postgresql-latest. Dafür muss DATABASE_URL auf eine bereits von Ihnen betriebene Datenbank zeigen.

Die erste Anmeldung erfolgt mit admin und dem Passwort umami. Ändern Sie das Passwort, bevor Sie DNS auf den Server zeigen lassen. Sobald der DNS-Eintrag aufgelöst wird und der Proxy antwortet, ist die Instanz aus dem Internet erreichbar. Details zu Compose, Umgebungsdateien und der Neustart-Richtlinie finden Sie unter einem Docker-Compose-Stack auf einem VPS. Kopieren Sie keinen Stack, den Sie nicht gelesen haben.

Die Installation besteht aus einem Node-Prozess und PostgreSQL. Sie benötigt mehr Ressourcen als ein einzelnes Binary, aber deutlich weniger als eine Anwendung mit ClickHouse.

Plausible Community Edition: ClickHouse legt den RAM-Mindestbedarf fest

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

Version v3.2.1 ist im August 2026 aktuell. Der Clone-Befehl pinnt diese Version absichtlich fest. Der Stack besteht aus drei Teilen: der Anwendung, Postgres für Konten und Einstellungen sowie ClickHouse für Ereignisdaten. SECRET_KEY_BASE muss eine Zeichenfolge mit mindestens 64 Byte sein. Genau das erzeugt der Aufruf openssl.

Die Anforderungen von Plausible sehen mindestens 2 GB RAM vor, damit ClickHouse und die Anwendung nicht durch den Out-of-Memory-Killer beendet werden. Außerdem wird eine CPU mit SSE 4.2 oder NEON benötigt. ClickHouse setzt diese Erweiterungen voraus. Diese zweite Anforderung sollten Sie vor dem Kauf prüfen. Sie ist ein praktischer Unterschied bei der Auswahl zwischen einem ARM- und einem x86-VPS. ClickHouse verwendet außerdem so viel Speicher, wie nach seiner Einschätzung verfügbar ist. Legen Sie auf einem gemeinsam genutzten Server daher eine Obergrenze fest, wie unter Begrenzen des Container-Speichers in Compose beschrieben.

BASE_URL muss exakt der öffentlichen URL entsprechen. Ist das nicht der Fall, melden Sie sich an, die Anwendung leitet auf den falschen Host weiter und das Sitzungs-Cookie wird für eine Domain geschrieben, die Ihr Browser nicht verwendet. Dadurch landen Sie ohne Fehlermeldung wieder im Anmeldeformular.

Die mitgelieferte Compose-Datei veröffentlicht keinen Port, weil ein Proxy davor erwartet wird. Fügen Sie einen Override hinzu, der den Standardport der Anwendung nur auf dem Loopback-Interface veröffentlicht.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: das vollständige Produkt und der dafür erforderliche Server

Matomo läuft mit PHP sowie MySQL oder MariaDB. Damit gehört es zum klassischen Web-Stack und nicht zu einem Container-Stack. Außerdem ist es das einzige Tool in diesem Vergleich, das Hardwareempfehlungen nach dem Traffic-Volumen veröffentlicht.

ChartMatomo sizing guidance by monthly pageviews
The data behind this chart
[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Dies sind die von Matomo veröffentlichten Mindestanforderungen mit Stand August 2026 und keine Messwerte aus diesem Leitfaden. Bis zu 100,000 Seitenaufrufe pro Monat werden 2 CPU-Kerne, 2 GB RAM und 50 GB SSD-Speicher benötigt. Ein Server übernimmt dabei sowohl die Anwendung als auch die Datenbank. Bei 1M/month sind es 8 GB RAM und 250 GB Speicher. Bei 10M/month empfiehlt Matomo zwei Server. Die letzte Zeile zeigt den Datenbankserver mit 16 GB RAM und 400 GB Speicher. Vergleichen Sie diese Speicherwerte mit den Optionen für einzelne Binärdateien, bei denen der gesamte Datensatz in einer SQLite-Datei liegt.

Die Archivierung überrascht viele. Standardmäßig erstellt Matomo seine Berichte, wenn jemand das Dashboard öffnet. Mit wachsender Datenmenge wird das Dashboard dadurch langsamer und läuft schließlich in einen Timeout. Die dokumentierte Lösung besteht darin, die durch den Browser ausgelöste Archivierung in den allgemeinen Einstellungen zu deaktivieren und den Archiver stattdessen per cron auszuführen. Verwenden Sie dafür den Benutzer, dem die Matomo-Dateien gehören, und starten Sie den Befehl aus dem Matomo-Verzeichnis.

php console core:archive --url=https://analytics.example.com

Matomo speichert neben den verarbeiteten Berichtstabellen auch Tabellen mit Rohdaten aus den Logs. Alte Rohdaten und alte Berichte können nach einem Zeitplan gelöscht werden. Aktivieren Sie diese Funktion bei der Installation und nicht erst, wenn der Speicher voll ist. Matomo kann außerdem Server-Access-Logs importieren. Damit deckt es als einziges Produkt in diesem Vergleich beide Produktfamilien ab.

Rybbit und neuere Stacks

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit ist ein neues Projekt mit einem modernen Dashboard. Das Setup-Skript erstellt die Umgebungsdatei und startet den Stack mit Docker Compose. Rybbit verwendet ClickHouse und bringt Caddy als eigenen Webserver mit. Caddy belegt Port 443 und fordert ein Zertifikat für die angegebene Domain an. Wenn nginx auf dem Server bereits Port 443 verwendet, kann das Skript den Port nicht binden. Verwenden Sie in diesem Fall den manuellen Compose-Weg des Projekts und betreiben Sie Rybbit hinter Ihrem vorhandenen Proxy. Laut Dokumentation sind mindestens 2 GB RAM erforderlich. Getestet wurde das Setup unter Ubuntu 24 LTS. Auf ARM-Systemen wird wegen ClickHouse ARMv8.2-A oder neuer benötigt.

Bei jedem jungen Projekt gilt: Neue Funktionen werden schnell veröffentlicht, aber ebenso schnell können sich inkompatible Änderungen ergeben. Fixieren Sie ein Tag, lesen Sie vor dem Abruf die Release Notes und erstellen Sie zuerst ein Datenbank-Backup.

Aufbewahrung und Festplattenwachstum: Messen Sie selbst auf Ihrem Server

Das Festplattenwachstum hängt davon ab, welche Daten das Tool pro Ereignis speichert. GoatCounter aggregiert Aufrufe zu Zählern. Daher wächst seine Datei stärker mit der Anzahl unterschiedlicher Seiten und Tage als mit dem Rohvolumen. Umami und Matomo speichern pro Ereignis eine Zeile. Matomo speichert zusätzlich zu den Rohdaten verarbeitete Berichtstabellen. ClickHouse speichert Ereignisse spaltenorientiert und komprimiert sie stark. Deshalb kommt Plausible mit einem Volumen zurecht, das einen zeilenorientierten Speicher stark belasten würde.

Dieser Leitfaden nennt keinen Wert in Megabyte pro 1 Million Pageviews, weil dieser Wert nicht mit Ihrem Datenverkehr gemessen wurde. Führen Sie die Messung selbst durch. Passen Sie die Namen des Dienstes und des Benutzers an Ihre eigene Compose-Datei an.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Notieren Sie den Wert, warten Sie eine Woche, notieren Sie ihn erneut und teilen Sie die Differenz durch die Pageviews, die das Dashboard für diese Woche meldet. Dieser Wert bezieht sich auf Ihre Website und Ihre Bot-Filterung. Er ist daher aussagekräftiger als jeder veröffentlichte Durchschnittswert. Legen Sie anschließend ein Aufbewahrungslimit fest, solange der Wert noch niedrig ist. Eine volle Festplatte legt jeden Dienst auf dem VPS lahm, nicht nur die Analytics-Anwendung. Das ist das stärkste Argument dafür, das Datenbank-Volume an einem Ort abzulegen, vor dem df -h Sie warnen wird. Dieses Risiko erfordert auf einem Server, der bereits etwas Umfangreiches enthält, besondere Aufmerksamkeit, weil ein selbst gehosteter Fotoserver die Festplatte leert, lange bevor eine Analytics-Datenbank auch nur annähernd ihre Kapazitätsgrenze erreicht.

Verhalten hinter einem Reverse Proxy auf einer Subdomain

Platzieren Sie den Collector auf einer Subdomain der Website, die er misst, zum Beispiel stats.example.com. Dadurch gilt die Anfrage des Collectors als First-Party-Anfrage. Sie wird daher nicht von Browser-Regeln blockiert, die Third-Party-Anfragen verhindern.

Binden Sie die Anwendung an Loopback, wenn Sie den Container-Port veröffentlichen. Docker schreibt seine eigenen Firewall-Regeln vor den ufw-Regeln. Deshalb ist ein Container mit der Veröffentlichung -p 3000:3000 aus dem Internet erreichbar, auch wenn ufw status meldet, dass der Port verweigert wird. Testen Sie dies von einem anderen Rechner mit curl http://SERVER_IP:3000. Sie erhalten dann das Dashboard. Bei der Veröffentlichung als -p 127.0.0.1:3000:3000 liefert derselbe Test Connection refused. Nur der Proxy kann die Anwendung erreichen. Diese Vorgehensweise verbirgt nicht nur ein Dashboard. Sie ist die Grundlage für den Betrieb eines Onion-Dienstes auf demselben Host. Jeder Dienst, der weiterhin auf der öffentlichen Schnittstelle antwortet, kann die verborgene Adresse mit Ihrer IP-Adresse verknüpfen. Der Collector-Endpunkt muss aus dem offenen Internet erreichbar bleiben. Das Dashboard muss es nicht. Wenn Sie es lieber über ein privates Netzwerk lesen möchten, statt eine zweite Subdomain zu veröffentlichen, ermöglicht die Bekanntmachung des VPS-Netzwerks in Ihrem Tailnet mit einem Subnet-Router den Zugriff, ohne einen Port zu öffnen.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Die Forwarding-Header sind hier erforderlich. Ohne X-Forwarded-For stammt jeder Besuch scheinbar von 127.0.0.1. Der Länderbericht bleibt dann leer, und die Zahl der eindeutigen Besucher nähert sich dem Wert eins. Jedes Projekt legt selbst fest, welchem Header es vertraut und welche Einstellung dafür erforderlich ist. Lesen Sie daher einmal die Proxy-Dokumentation des Projekts, statt dies vorauszusetzen. Caddy setzt diese Header selbst. Ein Caddyfile für dieselbe Aufgabe umfasst zwei Zeilen.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Wenn Sie noch keinen Proxy ausgewählt haben, beschreibt der Vergleich von nginx, Caddy und Traefik, welcher Proxy für einen einzelnen Rechner mit einigen Subdomains geeignet ist.

Self-Hosting ändert, wer die Daten verwaltet. Es ändert nicht, was das Gesetz über diese Daten sagt. Halten Sie zwei Regeln getrennt. Die Einwilligungsregel der ePrivacy-Richtlinie betrifft das Speichern oder Auslesen beliebiger Daten auf dem Gerät des Besuchers. Ein Tool, das keine Cookies setzt und nichts im local storage speichert, fällt daher nicht unter diese konkrete Anforderung. Die DSGVO betrifft die Verarbeitung personenbezogener Daten. Eine IP-Adresse gilt als personenbezogenes Datum. Sie benötigen daher weiterhin eine Rechtsgrundlage, eine Aufbewahrungsfrist und eine Antwort, wenn jemand wissen möchte, welche Daten Sie über ihn gespeichert haben.

Plausible, Umami, GoatCounter und Medama setzen standardmäßig keine Cookies. Was die einzelnen Projekte stattdessen ableiten, unterscheidet sich je nach Projekt und kann sich zwischen Versionen ändern. Lesen Sie daher die Datenschutzdokumentation des jeweiligen Projekts und nicht nur eine Zusammenfassung. Matomo bietet IP-Anonymisierung und einen Opt-out-Endpunkt, den Sie in der Administrationsoberfläche aktivieren.

Behörden kommen in verschiedenen Ländern zu unterschiedlichen Ergebnissen. Die französische CNIL veröffentlicht beispielsweise Bedingungen, unter denen die Reichweitenmessung von der Einwilligungspflicht ausgenommen sein kann. Dieser Abschnitt ist eine sachliche Zusammenfassung und keine Rechtsberatung. Fragen Sie für eine echte Website mit echten Nutzern einen Anwalt in Ihrer Rechtsordnung.

Ein Punkt wird häufig übersehen: Auch ein Zugriffs-Log enthält personenbezogene Daten. GoAccess fügt der Seite kein Skript hinzu und verarbeitet trotzdem IP-Adressen. Logbasierte Analysen liegen daher nicht automatisch außerhalb der gesetzlichen Vorgaben. Wenn Sie einen Dienst auf Ihren eigenen Server verlagern, verlagern Sie die Risiken, statt sie zu beseitigen. Aus demselben Grund endet was eine selbst gehostete SearXNG-Instanz tatsächlich verbirgt bei den Suchmaschinen, während die Suchanfragen selbst weiterhin in Ihren eigenen Logs landen.

Werbeblocker und warum Ihre Zahlen sinken werden

Filterlisten gleichen Hostnamen und URL-Muster ab. Ein gehostetes Analyseprodukt lässt sich leicht abgleichen, weil es von allen über denselben bekannten Hostnamen geladen wird. Wenn Sie den Collector in eine eigene Subdomain verschieben, entfernen Sie diesen Hostnamen aus der Anfrage. Wenn Sie das Skript von einem selbst gewählten Pfad ausliefern, entfernen Sie außerdem den bekannten Dateinamen. Dadurch ändern sich beide Merkmale, die eine Filterliste abgleichen muss.

Dieser Beitrag nennt keine Trefferquote, weil keine gemessen wurde. Der Anteil der Besucher, die eine bestimmte Konfiguration blockieren, hängt von Ihrer Zielgruppe ab. Eine Zielgruppe aus Entwicklern blockiert deutlich häufiger als eine allgemeine Zielgruppe. Messen Sie stattdessen Ihre eigene Differenz. Zählen Sie über dieselbe Woche mit GoAccess die Anfragen für HTML-Seiten im Access-Log. Vergleichen Sie diesen Wert mit den Pageviews, die Ihr skriptbasiertes Tool meldet. Die Differenz umfasst auf Ihrer Website blockierte Besuche und Seiten, die aus dem Cache ausgeliefert wurden.

Rechnen Sie damit, dass sich die Gesamtzahlen an dem Tag ändern, an dem Sie von einem gehosteten Produkt wechseln. Ein Teil dieser Änderung hat jedoch nichts mit Blockierung zu tun. Produkte verwenden unterschiedliche Definitionen für einen Pageview. Sie unterscheiden sich auch darin, ob ein Routenwechsel innerhalb einer Single-Page-Anwendung als ein Pageview zählt und wann eine Sitzung endet. Vergleichen Sie die Trends über mehrere Wochen, bevor Sie auf einen Rückgang des Traffics schließen.

Welche Lösung für welche Website

  • Eine persönliche Website oder ein Blog mit ungefähr bis zu 50.000 Seitenaufrufen pro Monat: GoatCounter oder Medama auf einem VPS mit 1 GB RAM, mit Backups als einfache Dateikopie.
  • Eine Website, auf der Sie kein Script hinzufügen können, oder eine Zielgruppe, die Scripts weitgehend blockiert: GoAccess über das vorhandene Log, regelmäßig ausgeführt.
  • Eine Website eines kleinen Unternehmens, deren Dashboard von einer anderen Person gelesen wird: Umami mit seinem Postgres-Container.
  • Eine Website, für die Sie Ziele und Trichter benötigen, auf einem System mit mindestens 2 GB RAM: Plausible Community Edition oder Rybbit, wenn Sie ein moderneres Dashboard bevorzugen und ein jüngeres Projekt akzeptieren.
  • Viele Websites, viele Benutzerkonten oder die Anforderung, Rohdaten nach einer eigenen Aufbewahrungsrichtlinie zu speichern: Matomo, dimensioniert anhand der oben veröffentlichten Empfehlungen.

Beginnen Sie mit dem kleinsten Tool, das Ihre tatsächliche Frage beantwortet. Der Wechsel von GoatCounter zu Plausible kostet später nur eine Subdomain und einen Teil der Historie. Der Wechsel von Matomo zu einem anderen Tool erfordert eine Migration, die Sie nicht gerne durchführen werden. Wenn Sie noch entscheiden, was auf demselben System betrieben werden soll, behandelt der umfassendere Self-Hosting-Überblick, was sich dafür eignet. Wenn Sie eigentlich die Request-basierte Ablaufverfolgung einer Anwendung statt Besucherzahlen benötigen, ist ein selbst gehosteter Observability-Dienst dafür das passende Tool.

FAQ

Nein. Die beiden Fragen sind getrennt zu betrachten. Die Einwilligungsregel nach der ePrivacy-Richtlinie gilt für das Speichern oder Auslesen von Informationen auf dem Gerät des Besuchers. Ein Tool, das keine Cookies setzt und nichts im Local Storage speichert, fällt daher nicht unter diese spezielle Anforderung. Die DSGVO ist eine andere Regelung und betrifft die Verarbeitung personenbezogener Daten. Eine IP-Adresse ist ein personenbezogenes Datum. Sie benötigen daher auch ohne Cookie eine Rechtsgrundlage und eine Aufbewahrungsfrist. Beim Self-Hosting liegen die Daten auf Ihrem Server, und Sie sind dafür verantwortlich. Prüfen Sie die Vorgaben Ihrer zuständigen Aufsichtsbehörde und lassen Sie sich zu Ihrem konkreten Fall juristisch beraten.

Wie viel RAM benötigt selbst gehostete Analyse auf einem VPS?

Der Datenspeicher entscheidet, nicht das Dashboard. GoatCounter und Medama laufen als ein Prozess mit einer Datei. Die Dokumentation von Medama gibt an, dass kleine Websites auf Systemen mit 256 MB laufen. Umami fügt neben einer Node-Anwendung einen Postgres-Container hinzu. Plausible Community Edition und Rybbit verwenden beide ClickHouse. Beide Projekte nennen mindestens 2 GB. Die Empfehlungen von Matomo beginnen bei 2 CPU-Kernen und 2 GB RAM für bis zu 100,000 Pageviews pro Monat.

Warum sind die Zahlen meines selbst gehosteten Systems niedriger als die der abgelösten Analyse?

Es gibt zwei Ursachen. Beide sind relevant. Filterlisten blockieren einige Collector-Anfragen. Dadurch verliert jedes auf Skripten basierende Tool diese Besuche. Außerdem zählen die Produkte unterschiedlich. Was als Pageview gilt und wann eine Sitzung endet, ist je nach Produkt verschieden. Vergleichen Sie eine Woche lang die HTML-Seitenanfragen aus Ihrem Access-Log mit den scriptbasierten Pageviews derselben Woche. Die Differenz entspricht blockierten Besuchen und Seiten aus dem Cache. Sie wird auf Ihrer eigenen Website gemessen und nicht aus einer veröffentlichten Rate eines anderen Anbieters übernommen.

Kann ich Plausible oder Rybbit auf einem ARM-VPS ausführen?

Beide verwenden ClickHouse. ClickHouse benötigt SSE 4.2 auf x86 oder NEON auf ARM. Die Anforderungen von Plausible nennen genau diese Voraussetzung. In der Dokumentation von Rybbit steht, dass ARM-Systeme ARMv8.2-A oder neuer benötigen. Aktuelle ARM-Serverkerne erfüllen diese Voraussetzung, ältere jedoch nicht. Der Fehler zeigt sich darin, dass ClickHouse mit einem Fehler zum Befehlssatz nicht startet. In den Anwendungslogs erscheint er nicht als anderer Anwendungsfehler. Auf einem kleinen ARM-System vermeiden Sie diese Frage mit den Tools, die eine einzelne Datei verwenden, weil keines davon ClickHouse ausführt.

Sollte ich Serverlogs auswerten, statt ein Tracking-Skript zu verwenden?

Verwenden Sie die Logauswertung, wenn Sie kein Skript hinzufügen können, wenn Ihre Zielgruppe häufig Inhalte blockiert oder wenn Sie eine Zählung einschließlich Crawlern benötigen. GoAccess liest ein Log, das Ihr Server bereits schreibt. Dadurch entstehen weder zusätzliches Seitenschnellgewicht noch eine zusätzliche Datenbank. Sie erfassen jedoch keine Vorgänge im Browser. Außerdem fehlen Seiten, die von einem CDN oder aus dem Browser-Cache ausgeliefert werden, weil diese Anfrage Ihren Server nie erreicht hat. Viele Websites verwenden beide Verfahren und behandeln sie als zwei unterschiedliche Messungen.