🕵️‍♂️ Matomo trackt nicht?!

Wie mich „Do Not Track“ einen ganzen Tag Debugging gekostet hat 🐛📉

Mein Matomo-Tracking funktionierte technisch die ganze Zeit — nur mein Browser hat mich erfolgreich davor geschützt.

Eine Debugging-Odyssee zwischen WordPress, Complianz, Mixed Content, _paq, 204-Responses, Inkognito-Modus und einer Datenschutzeinstellung, die die meisten Websites einfach ignorieren.

Was wie ein kaputtes Analytics-Setup aussah, entpuppte sich am Ende als Lektion über moderne Browser-Privacy, Entwickler-Fehlannahmen und respektvollen Umgang mit Nutzerdaten.

---

🧩 Der Anfang: „Ach, das fix ich schnell“

Eigentlich wollte ich nur etwas völlig anderes testen.

Ich hatte angefangen, mich intensiver mit meinem WordPress-Setup auseinanderzusetzen:

• eigenes Theme,
• eigene Plugins,
• lokale Fonts,
• Performance,
• Tracking,
• Datenschutz.

Also dachte ich:

„Komm, Matomo baust du jetzt sauber selbst ein.“

Selbst gehostet.
Keine externen Tracker.
Kein Google Analytics.
Privacy-first.

Ein kleines Tracking-Snippet in meinem eigenen Developer-Plugin. Fertig.

Oder zumindest dachte ich das.

---

🚨 Die erste Fehlermeldung

Dann plötzlich in der Browser-Konsole:

Mixed Content:
The page at 'https://fullstackdevelopment.de/...'
was loaded over HTTPS,
but requested an insecure script
'http://matomo.clubitsolutions.de/matomo.js'

Klassiker.

Also dachte ich:

„Ok, irgendwo steht noch HTTP statt HTTPS.“

Eine kleine Konfigurationssache.
5 Minuten maximal.

Spoiler:
Es wurden viele Stunden.

---

🔍 Das Rabbit Hole beginnt

Erst sah alles logisch aus.

Complianz hatte tatsächlich noch irgendwo eine alte HTTP-URL gespeichert.
Korrigiert.

Reload.

Keine Fehlermeldung mehr.

Aber:

• keine Besucher,
• keine Live-Visits,
• keine Daten.

---

🧠 Und jetzt wurde es seltsam

Denn technisch sah plötzlich alles korrekt aus.

Im Netzwerk-Tab:

matomo.js → 200 OK
matomo.php → 204 No Response

Der Tracker wurde geladen.
Die Requests gingen raus.

Aber Matomo zeigte trotzdem:

0 Besucher.

---

🔬 Also begann die echte Fehlersuche

Und wie das so ist:
Sobald man anfängt zu debuggen, findet man plötzlich überall Dinge, die „verdächtig“ aussehen.

---

🧱 Verdächtiger #1: Complianz

Vielleicht blockiert das Cookie-Banner mein Tracking?

Also:

• Complianz deaktiviert
• eigenes Tracking-Snippet
• WordPress-Plugin rausgeworfen

Keine Änderung.

---

🧱 Verdächtiger #2: Connect Matomo Plugin

Dann fiel mir auf:
Das Plugin erzeugte teilweise seltsamen Code.

Außerdem:

• jQuery-Fehler
• kaputte Admin-Bar Widgets
• „Configure Matomo“
• Besucherzahlen verschwanden

Also:
Plugin deaktiviert.

Eigenes Snippet geschrieben.

---

🧱 Verdächtiger #3: Mein JavaScript

Vielleicht wird _paq falsch initialisiert?

Also begann ich, direkt in der Konsole zu analysieren:

console.log(window._paq)

Oder:

typeof window._paq.push

Oder:

document.querySelectorAll('script')

Oder:

• async-Probleme,
• DOMContentLoaded,
• Footer Hooks,
• Race Conditions,
• Reihenfolge der Initialisierung.

---

🌀 Die Debugging-Spirale

Irgendwann fühlte sich das ungefähr so an:

Matomo kaputt?
    ↓
Mixed Content?
    ↓
Complianz?
    ↓
CORS?
    ↓
Cookies?
    ↓
_paq kaputt?
    ↓
async?
    ↓
jQuery?!
    ↓
Plugin-Konflikt?
    ↓
WordPress Hook?
    ↓
FastCGI?
    ↓
Plesk?
    ↓
Apache?
    ↓
Browser?!

---

🤯 Der Punkt, an dem man anfängt, allem zu misstrauen

Irgendwann hatte ich:

• Cookies analysiert,
• Requests verglichen,
• CORS überprüft,
• Site-IDs kontrolliert,
• die Datenbank geprüft,
• Tracking-Codes direkt aus Matomo kopiert,
• mehrere Browser getestet,
• sogar überlegt, ob FastCGI irgendetwas cached.

Und das Verrückte war:

Technisch sah alles richtig aus.

---

📉 Das perfide Detail

matomo.php lieferte:

204 No Response

Und das ist eigentlich korrekt.

Denn:

• Der Request wurde akzeptiert.
• Der Tracker funktionierte.
• Keine Fehlermeldung.

Aber trotzdem:

keine Besucher.

Das ist die Sorte Fehler, die einen langsam wahnsinnig macht.

---

🕵️‍♂️ Die eigentliche Ursache

Am Ende lag die Lösung nicht:

• in WordPress,
• nicht in Matomo,
• nicht in Complianz,
• nicht in JavaScript,
• nicht im Server.

Sondern in meinem Browser.

Genauer gesagt:

🛡️ „Do Not Track“

Ich hatte die Funktion selbst irgendwann aktiviert — und komplett vergessen.

Und das Ironische daran:

Das System funktionierte die ganze Zeit korrekt.

Mein Browser hat einfach genau das getan, was ich ihm irgendwann erlaubt hatte:

mich nicht zu tracken.

---

🤦‍♂️ Warum das so verwirrend war

Der eigentliche Mindfuck war:

Viele Webseiten ignorieren „Do Not Track“ schlicht komplett.

Deshalb war ich unbewusst davon ausgegangen:

„Das macht heutzutage eh niemand mehr.“

Aber:

• Complianz respektierte DNT.
• Mein eigenes Setup respektierte DNT.
• Matomo respektierte DNT.

Und dadurch funktionierte plötzlich alles „zu korrekt“.

---

🧪 Warum Inkognito die Sache noch schlimmer machte

Natürlich habe ich auch im Inkognito-Modus getestet.

Großer Fehler.

Denn moderne Browser behandeln Inkognito längst nicht mehr als:

„saubere Umgebung“

Sondern eher als:

„Privacy-Hardcore-Modus“

Je nach Browser bedeutet das:

• aggressives Tracker-Blocking,
• Storage-Einschränkungen,
• Anti-Fingerprinting,
• Third-Party-Blocking,
• zusätzliche Datenschutzmechanismen.

Mit anderen Worten:
Ich testete irgendwann nicht mehr:

„funktioniert mein Tracking?“

sondern:

„überlebt mein Tracking moderne Privacy-Features?“

Das sind zwei völlig unterschiedliche Fragen.

---

⚖️ Die ethische Frage

Und ehrlich gesagt:

Ich finde es eigentlich gut.

Wenn Nutzer explizit sagen:

„Bitte track mich nicht.“

…dann sollte man das respektieren.

Gerade deshalb möchte ich bei meinem eigenen Blog:

• lokale Fonts,
• minimale externe Requests,
• selbst gehostetes Matomo,
• möglichst wenig Tracking,
• und Respekt vor Browser-Privacy.

Denn moderne Webentwicklung besteht nicht nur aus:

• Performance,
• SEO,
• Analytics,
• Conversion Rates.

Sondern auch aus:

Vertrauen.

---

🧠 Was ich aus dem Ganzen gelernt habe

🔹 204 bedeutet nicht „kaputt“

Sondern oft:

„Request erfolgreich verarbeitet.“

---

🔹 Inkognito ist kein neutraler Testmodus

Moderne Browser sind aggressiver geworden.
Und das ist meistens gut.

---

🔹 Plugin-Fehler können echte Probleme verschleiern

Ich hatte tatsächlich:

• Mixed Content,
• ein kaputtes Plugin-Widget,
• jQuery-Fehler,
• und DNT gleichzeitig.

Dadurch wirkte alles komplett kaputt.

---

🔹 Browser können Entwickler erfolgreich verwirren

Vor allem dann, wenn sie korrekt funktionieren.

---

🧩 Mein finales Setup

Am Ende blieb:

✅ selbst gehostetes Matomo
✅ kleines eigenes Tracking-Snippet
✅ kein schweres Plugin-Chaos
✅ DNT respektieren
✅ lokale Assets
✅ weniger externe Abhängigkeiten

Und ehrlich:
Das fühlt sich deutlich sauberer an.

---

💬 Fazit

Am Ende war nicht mein Tracking kaputt.

Mein Browser hat einfach genau das getan, was ich ihm irgendwann selbst gesagt hatte.

Und vielleicht ist das manchmal sogar die bessere Art von Software.