Hallo,
kurze Frage: Warum habe ich mit der PHP-Tracking-Api deutlich mehr Besucher/Seitenaufrufe als mit dem Standard JavaScript-Code?
Wie könnte ich das ggf. angleichen?
Danke & Viele Grüße
Olli
Hallo,
Ich habe nicht so viel Erfahrung mit der PHP-Tracking API, aber das sind ein paar Gründe die mir spontan einfallen:
Prinzipiell trackt die PHP API jeden aufruf auf https://yoursite.example/index.php während das JS-Tracking jeden Browser der die Webseite aufruft und das JS ausführt.
- Adblocker blockieren
/piwik.jsaber erkennen natürlich nicht das PHP Tracking - Hast du Do-Not-Track in PHP implementiert. (Oder macht die Library das?)
- Dasselbe gibt für das Opt-Out Cookie
- Die meisten Bots und Crawler führen den Piwik Tracking Code nicht aus, aber doch den PHP code. (Aber User Agents die als Bot erkannt werden, werden von Piwik glaube ich ignoriert)
Falls noch jemanden ein Unterschied einfällt, bitte dazuschreiben.
1 Like
Mit PHP wird schon auf dem Server getrackt. Also ein request genügt. Ob der Visitor dann wirklich die Webseite in seinen Browser bekommt, ist ein Schritt danach. Es genügt also auch ein Kommandozeilen-request mit curl oder HEAD oder ähnlich.
Mit Javascript wird erst im Browser des Visitors getrackt. Also die Website-Daten müssen erst übermittelt werden.
Was der Visitor alles blockt weißt du nie. Nicht wenige blocken Javascript allgemein.
Bots führen im allgemeinen kein Javascript aus.
Vielleicht würde das Image-Tracking weiterhelfen.
1 Like
Vielen Dank für Eure Antworten.
Also ist das JavaScript Tracking die bessere, genauere Variante?
Das Image Tracking werde ich mir auch nochmal anschauen…
Hallo,
Bedenke, dass das Image Tracking das mit Abstand ungenaueste ist und eigentlich nur als fallback für Browser mit deaktivierten JavaScript gedacht ist
https://forum.matomo.org/t/tracking-pixel-and-javascript/26651/5
@Olli Also ist das JavaScript Tracking die bessere, genauere Variante?
Das kann man so nicht sagen, denke ich:
Wie schon erwähnt, läuft der Javascript Tracker zu einem späteren Zeitpunkt als der php-Tracker, und setzt einen Browser als Umgebung voraus, der Javascript ausführt - dass es also zu unterschiedlichen Ergebnissen kommt ist nicht verwunderlich, welche Daten die “besseren” sind kann man deshalb aber nur sagen, wenn klarer ist, was der Zweck der Auswertung sein soll.
Willst Du zum Beispiel einen Überblick bekommen, welche Seiten/Scripts die meisten realen “hits” abbekommen, um heraus zu finden, was Deinen Server zum Glühen bringt, ist (wenn du keine Server logs auswerten willst) in jedem Fall das php-Tracking zu bevorzugen, bei dem mehr von der tatsächlichen Serverlast zu sehen ist.
Geht es Dir mehr darum, das Nutzerverhalten zu beobachten ist die “vorgefilterte” Datensammlung des JS-trackers zu bevorzugen.
Ich habe jedoch durchaus Situationen erlebt, in denen regelmässige Nutzer meiner Seite so schnell zu den Ihnen vertrauten Navigations-schritten clicken, dass sie den JS-tracker abhängen (es fehlen dann einzelne Seitenaufrufe in der Statistik, und Du fragst Dich, wie der Nutzer von A nach C gekommen sein soll, weil Seite B nicht lange genug offen war, um getrackt zu werden).
@Lukas Adblocker blockieren /piwik.js aber erkennen natürlich nicht das PHP Tracking
Dem kann man ausweichen, in dem man die piwik.js schlicht umbenennt (getestet mit ABP).
Das Umbenennen muss man dann zwar im Updatefall händisch machen, bei der weiten Verbreitung von adblockern würde ich das aber empfehlen, weil dem JS-tracker sonst ein recht großer Teil Traffic fehlen würde.
@Lukas User Agents die als Bot erkannt werden, werden von Piwik […im php tracking…] glaube ich ignoriert
Glaube ich auch, aber es wäre schon schön, wenn wir das irgendwie nochmal verifizieren könnten, da es ja einen großen Unterschied macht.
Alles was @MrSnuts zum PHP tracking sagt, gilt gleichermaßen für LogAnalytics, da man da die selben Benutzer erwischen sollte.
Dafür gibt es übrigens in Matomo eine out-of-the-box Lösung:
https://github.com/matomo-org/matomo/tree/3.x-dev/js
Man kann direkt https://definitly-not-matomo.example/js/ verwenden.
Aber einfach umbenennen reicht nicht mehr, denn in EasyPrivacy werden auch die GET parametemr mit denen die Daten zurückgeschickt werden, blockiert.
Ich habe die (umbenannte) piwik.js auf einem CDN gehostet, ich fürchte, dafür hilft die Lösung nicht.
Habe gerade nochmal getestet,
Ein frisch installiertes AdBlock in Chrome blockt die GET-Parameter bei mir nicht, ist aber wahrscheinlich eine Frage der Zeit bis die das implementieren, darum Danke für den Tip.