Wenn Statistik und Server-Log verschiedene Zahlen zeigen, ist keine davon falsch
Der unangenehmste Moment in einer Auswertungssitzung ist der, in dem zwei Zahlen auf dem Tisch liegen, die nicht zusammenpassen. Das Analyse-Werkzeug sagt, im letzten Monat hätten so und so viele Menschen die Website besucht. Das Server-Protokoll sagt etwas anderes. Und jeder im Raum fragt sich, welche der beiden Zahlen jetzt gelogen hat.
Keine. Die beiden messen verschiedene Dinge, und das ist kein Mangel, sondern der ganze Punkt.
Das Analyse-Werkzeug schaut dem Besucher über die Schulter: Es sieht, was er anklickt, wie weit er liest, ob er das Formular abschickt. Dafür braucht es seine Erlaubnis – und wer sie verweigert oder einen Blocker im Browser hat, taucht dort nie auf. Das Server-Protokoll dagegen notiert jeden einzelnen Abruf, ganz gleich, wer ihn ausgelöst hat. Dafür sieht es nichts von dem, was danach auf der Seite passiert. Es weiss, dass jemand die Tür geöffnet hat, aber nicht, was er drinnen getan hat.
Was da eigentlich zählt, wenn jemand eure Website öffnet
JavaScript-Tracking
Die übliche Art zu messen: Ein kleines Programm läuft im Browser eures Besuchers mit und meldet, was er tut. Es sieht Klicks, Scrollen und Formularabschlüsse – aber nur bei den Besuchern, die es laufen lassen.
Server-Logfile
Das Protokoll, das euer Server beim Ausliefern jeder Seite ohnehin schreibt, noch bevor irgendein Programm im Browser startet. Es enthält jeden Zugriff, auch die von Maschinen und von Besuchern ohne Einwilligung. Was danach auf der Seite geschieht, sieht es nicht – kein Scrollen, keinen Klick.
Consent-Gap
Die Lücke zwischen den Menschen, die auf eurer Website waren, und denen, die ihr messen durftet. Sie entsteht am Cookie-Banner und an den Blockern in den Browsern. Wie gross sie bei euch ist, hängt von eurem Publikum ab – eine allgemeingültige Prozentzahl dafür gibt es nicht.
Warum ich beide Quellen nebeneinanderlege, bevor ich eine Zahl glaube
Eine einzelne Zahl aus einer einzelnen Quelle ist mir zu wenig, um daran ein Budget zu hängen. Nicht weil ich der Software misstraue, sondern weil jede Messmethode einen eingebauten blinden Fleck hat – und beide Flecken liegen praktischerweise auf entgegengesetzten Seiten. Das Tracking sieht das Verhalten, aber nicht alle Leute. Das Logfile sieht alle Zugriffe, aber kein Verhalten. Wer nur eines von beiden liest, hält einen Ausschnitt für das Bild.
Wirtschaftlich zählt daran vor allem eines: das Verhältnis der beiden Zahlen zueinander. Liegen sie nahe beieinander, könnt ihr euch auf euer Dashboard verlassen. Klaffen sie weit auseinander, ist eure Erfassung lückenhaft – und dann ist die Kanalverteilung, auf die ihr eure Werbeentscheide stützt, ebenfalls verzerrt. Das ist kein Detail für die IT. Das entscheidet mit, wohin euer nächster Marketingfranken geht.
Der Abgleich kostet euch fast nichts. Das Logfile ist bereits da, es entsteht beim Betrieb ohnehin – keine zusätzliche Datensammlung, kein neues Werkzeug, keine Einwilligung, die ihr einholen müsstet. Ihr müsst nur hineinschauen, und die meisten tun es nie.
Was ich euch nicht verspreche: dass danach jede Zahl stimmt. Auch das Logfile hat seine Tücken – Maschinen zählen fleissig mit, und ein vorgeschalteter Zwischenspeicher kann Zugriffe verschlucken, bevor euer Server sie sieht. Aber ihr entscheidet dann auf zwei Quellen, die unabhängig voneinander entstehen. Das ist der ganze Unterschied.
Es gibt zwei grundlegende Arten, Zugriffe auf eine Website zu messen: JavaScript-Tracking im Browser des Besuchers und Server-Logfiles auf der Maschine, die eure Seite ausliefert. Beide messen etwas Echtes, aber keine der beiden sieht alles. Wenn ihr nur eine Quelle nutzt, fehlt euch systematisch ein Teil des Bildes.
JavaScript-Tracking: sieht Verhalten, aber nicht jeden
Tools wie Google Analytics (GA4) oder ein Matomo-Tag laden ein Stück JavaScript im Browser. Dieses Skript meldet zurück, was im Browser passiert – und genau dort liegt seine Stärke:
- Verweildauer, Scrolltiefe und Klicks auf einzelne Elemente
- Reihenfolge der besuchten Seiten innerhalb eines Besuchs
- Geräteklasse, Bildschirmgrösse, ungefähre Herkunft
- Conversions, Formularabbrüche, interne Suchbegriffe
Die Einschränkung: Gezählt wird nur, wer JavaScript ausführt und einwilligt. Wer den Consent-Banner ablehnt, einen Adblocker nutzt oder das Skript blockiert, taucht nicht auf. Diese systematische Lücke heisst Consent-Gap – und sie wächst.
Server-Logfiles: sehen jeden, aber kein Verhalten
Jeder Aufruf hinterlässt eine Zeile im Logfile des Servers – unabhängig von Cookies, JavaScript oder Einwilligung. Das Logfile ist dadurch die vollständigere, aber rohere Quelle:
- jeden einzelnen Zugriff, auch von einwilligungslosen Besuchern
- Bots, Crawler und automatisierte Zugriffe
- Fehler wie 404 (nicht gefunden) und 500 (Serverfehler)
- Lastspitzen, Angriffsversuche und verdächtige Muster
Was das Logfile nicht kann: Es weiss nicht, wie weit jemand gescrollt hat, wie lange eine Seite wirklich betrachtet wurde oder ob ein Besucher zufrieden war. Verhalten innerhalb der Seite und echte Nutzererfahrung bleiben unsichtbar.
Was JavaScript-Tracking sieht und was das Logfile sieht
| Frage | JavaScript-Tracking | Server-Logfiles |
|---|---|---|
| Verhalten auf der Seite (Scroll, Klick, Verweildauer) | ja | nein |
| Besucher ohne Einwilligung / mit Blocker | nein | ja |
| Bots und automatisierte Zugriffe | meist gefiltert | ja, vollständig |
| Fehlerseiten (404 / 500) | nur teilweise | ja |
| Angriffsversuche und Lastspitzen | nein | ja |
| Conversions und UX-Tiefe | ja | nein |
| Abhängig von Cookies / Consent | ja | nein |
Warum sich die blinden Flecken gegengleich ergänzen
Die beiden blinden Flecken liegen genau gegengleich. Was das Tracking durch Consent-Banner und Blocker verliert, fängt die Logsicht auf. Was den Logs an UX-Tiefe fehlt, liefert das Tracking. Erst zusammen ergeben sie ein belastbares Bild.
Keine einzelne Messmethode ist vollständig. Die ehrliche Frage lautet nicht «Tracking oder Logs», sondern «was sagt mir jede Quelle – und was verschweigt sie».
Genau darauf baue ich meine Analysen auf: Webanalyse für das Verhalten, Loganalyse für die vollständige Zugriffssicht – für KMU, die ihre Zahlen verstehen statt nur sammeln wollen.
Wie ihr beide Quellen gegeneinander abgleicht
Der Abgleich ist die eigentliche Arbeit – und er ist der Moment, in dem ihr aufhört, zwei Zahlen zu haben, und anfangt, eine Aussage zu haben. Er verlangt kein zusätzliches Werkzeug, nur Zugriff auf das Access-Log und Disziplin bei der Definition.
- Zeitraum und Zeitzone gleichziehen. Das Access-Log schreibt in der Zeitzone des Servers, euer Analytics-Tool rechnet in der Zeitzone der Property. Verschieben sich die Tagesgrenzen, entsteht eine Differenz, die nichts bedeutet – und ihr interpretiert eine Zeitzone als Consent-Gap. Nehmt mindestens eine volle Woche, dann fällt die Verschiebung an den Rändern kaum ins Gewicht.
- Dieselbe Kennzahl wählen. Seitenaufrufe gegen Seitenaufrufe. Nicht Sitzungen gegen Requests, nicht «Nutzer» gegen «IP-Adressen». Wer hier schludert, misst den Unterschied zweier Zählweisen und nennt ihn Erkenntnis.
- Das Log auf echte Seitenaufrufe reduzieren. Nur HTML-Dokumente, Statuscode 200 und 304. Bilder, Stylesheets, Schriften und Skripte fliegen raus – sonst zählt ihr jede Seite so oft, wie sie Dateien nachlädt.
- Bots abziehen. Der aufwendigste Schritt und der, an dem die Rechnung sonst kippt: Selbstdeklarierte Crawler per User-Agent, getarnte über das Verhalten – keine Assets nachgeladen, kein Referrer, gleichmässiger Takt.
- Eigenzugriffe abziehen, und zwar auf beiden Seiten. Eure IP, die der Agentur, das Uptime-Monitoring. Wenn ihr das nur im Tracking tut und im Log vergesst, erzeugt ihr euch selbst eine Lücke, die keine ist.
- Das Verhältnis bilden – und dann aufschlüsseln. Getrackte Seitenaufrufe geteilt durch bot- und eigenbereinigte Log-Seitenaufrufe ergibt eure Erfassungsquote. Der Erkenntnisgewinn liegt aber nicht in der Gesamtzahl, sondern in der Aufschlüsselung pro Seite und pro Kanal: Dort seht ihr, welche Bereiche eurer Website im Tracking systematisch untergehen.
- Die Fehlerseiten gegenlesen. Filtert im Log auf Statuscode 404 und 500. Das ist der Bereich, in dem das Tracking prinzipbedingt schweigt: Eine Seite, die einen Serverfehler wirft, lädt kein Analyse-Skript. Eine eigene 404-Seite mit eurem Seitentemplate lässt sich zwar messen, Serverfehler und nackte Fehlerseiten aber nicht – sie sind in der Webanalyse unsichtbar und stehen im Log in der ersten Zeile.
Zwei Fallstricke, an denen der Abgleich in der Praxis scheitert:
- Eine Single-Page-Anwendung dreht das Vorzeichen um. Wenn eure Website Seitenwechsel im Browser nachbildet, statt neue Dokumente vom Server zu holen, meldet das Tracking mehrere Seitenaufrufe, während das Log nur einen einzigen Dokumentabruf sieht. Das Tracking liegt dann über dem Log – nicht, weil Bots mitzählen, sondern weil die beiden Quellen verschiedene Ereignisse zählen. Wer das nicht weiss, sucht einen Fehler, den es nicht gibt.
- Logs sind oft schon gelöscht, wenn man sie braucht. Viele Hostings rotieren das Access-Log nach wenigen Tagen und werfen das Alte weg. Rückwirkend vergleichen könnt ihr dann nichts. Der Abgleich beginnt deshalb nicht mit der Auswertung, sondern mit der Frage, wie lange euer Hoster die Logs überhaupt aufbewahrt – und, falls nötig, mit einer Verlängerung, bevor die interessante Zeitreihe entsteht.
Die ehrliche Grenze dieser Methode: Ihr bekommt zwei Zahlen und ein Verhältnis, keine Wahrheit. Wenn Tracking und Log weit auseinanderliegen, wisst ihr, dass eure Erfassung lückenhaft ist – aber nicht, wer die fehlenden Besucher waren und was sie wollten. Diese Information gibt es nicht, und niemand kann sie euch verkaufen.
Häufige Fragen
Reicht für ein KMU nicht eine der beiden Methoden?
Für eine erste Orientierung ja. Sobald ihr aber Budget oder Inhalte nach den Zahlen ausrichtet, lohnt sich der Abgleich mindestens einmal: Er zeigt, wie viel eurer echten Besucher euer Analyse-Werkzeug überhaupt erfasst. Liegen beide Zahlen nahe beieinander, könnt ihr danach getrost beim Dashboard bleiben. Klaffen sie auseinander, wisst ihr, dass auch eure Kanalverteilung verzerrt ist.
Komme ich als KMU überhaupt an meine Server-Logfiles?
In der Regel ja – bei den meisten Hosting-Angeboten liegen die Zugriffsprotokolle (Access-Logs) im Kundenbereich zum Download bereit oder lassen sich anfordern. Fragt euren Hoster: «Wo finde ich die Access-Logs unserer Website, und wie viele Tage bewahrt ihr sie auf?» Die zweite Frage ist die wichtigere, denn viele Anbieter löschen nach wenigen Tagen – wer vergleichen will, muss das klären, bevor der interessante Zeitraum vorbei ist.
Kann ich den Abgleich selbst machen, oder brauche ich dafür eine Fachperson?
Die Grundidee ist einfach: echte Seitenaufrufe im Log gegen Seitenaufrufe im Analyse-Werkzeug, für dieselbe volle Woche. Aufwendig sind die Details – Bilder und Skripte aus dem Log herausfiltern, Maschinenzugriffe und eure eigenen Besuche abziehen. Für einen ersten Blick genügt es, wenn eure IT oder Agentur diese Zahl einmal für euch ermittelt; fragt nach der «Erfassungsquote», also getrackte geteilt durch bereinigte Log-Seitenaufrufe.
Spielt es eine Rolle, ob ich GA4 oder Matomo einsetze?
Für diese grundsätzliche Unterscheidung nicht. Google Analytics 4 (GA4) und Matomo sind beide JavaScript-Tracking und teilen denselben blinden Fleck: Sie sehen nur Besucher, die einwilligen und das Skript nicht blockieren. Das Logfile ergänzt beide gleichermassen – ein Werkzeugwechsel löst die Lücke nicht.
Brauche ich für Server-Logfiles eine Einwilligung nach dem Datenschutzgesetz?
Logfiles dienen in erster Linie dem Betrieb und der Sicherheit eurer Website und entstehen beim Hoster ohnehin, ohne Skript im Browser. Wie sie nach dem revidierten Datenschutzgesetz (revDSG) zu beurteilen sind, hängt vor allem von Speicherdauer und Behandlung der IP-Adressen ab. Klärt deshalb mit dem Hoster, wie lange die Logs liegen und ob IP-Adressen gekürzt werden, und erwähnt die Protokollierung in eurer Datenschutzerklärung.
Quellen
- Server-Logs: Apache Software Foundation. «Log Files – Apache HTTP Server Version 2.4». — Was ein Access-Log pro Zugriff festhält, inklusive Referrer und User-Agent als Selbstauskunft des Browsers.
- Automatische Ereignisse in GA4: Google. «Ereignisse für optimierte Analysen». — Wann GA4 einen Seitenaufruf zählt, auch bei Single-Page-Anwendungen ohne neuen Abruf beim Server.