Ich glaube, die Jetpack-Wordpress-Statistik lügt uns Blogger an.

Dummerweise gibt es keine Infos auf den Jetpackseiten, was genau die da tracken, nur was sie nicht tracken, nämlich einen selbst.

Nun habe ich noch die guten alten Webalizerauswertungen durchgesehen und konnte für einzelne Beiträge teilweise den zehnfachen Zugriff feststellen.

Beispiel:

Der Beitrag „QMMP & MP3 & Fedora 24“ wurde laut Jetpackstats gestern 18x aufgerufen. Es gibt aber alleine gestern in den Webstats 352x Aufrüfe der Landingpageurl für diesen Artikel.

Bei genauerer Analyse der Aufrufer, stammen viele von Google. Lassen wir die weg, sind es noch 212 Anfragen.
Werfen wir alle doppelten IPs raus, bleiben noch 112 unique IPs übrig.

Das sind 500% mehr Zugriffe, als Jetpack dem Blog zugestehen will. Und das war nur eine von zwanzig Landingpages an dem Tag.

Warum zählt Jetpack das nicht, weiß das wer ?

Wie kommt man an diese Zahlen auf die schnelle ran ?

Zunächst mal braucht man einen Webserver z.b. einen Apache httpd und den passenden VirtualHost Eintrag um die Logfiles zu schreiben:

    ServerName bloggt-in-braunschweig.de
    ServerAlias *.bloggt-in-braunschweig.de
    ErrorLog logs/error_log
    CustomLog domlogs/bloggt-in-braunschweig.de combined

Weil son Tag erst richtig ausgewertet werden kann, wenn er vorbei ist, macht man das einen Tag später, weswegen auf einem normalen Webserver die Logfiles schon weggepackt wurden, damit sie wenig Platz benötigen. Da das am Tag +1 zum eigentlich Datum geschieht, sieht die Zeile auf meinem Fedora Server so aus :

zgrep „13/Jul/2016“  bloggt-in-braunschweig.de.20160714.gz | grep  „GET /2016/07/13/qmmp-mp3-fedora-24“ | grep -v „google“ | awk ‚{print $1;}‘ | sort -u | wc –lines

Damit Ihr Euch das vorstellen könnt, hier eine Beispiellogzeile:

5.35.243.228 – – [13/Jul/2016:20:40:35 +0200] „GET /2016/07/13/qmmp-mp3-fedora-24/ HTTP/1.1″ 200 40382 „-“ „Friendica ‚Lily of the valley‘ 3.4.3-2-1191; https://friend.sraega.org“

Die interessanten Teile, habe ich hervorgehoben.

Der Befehl ‚zgrep „13/Jul/2016“ ‚ filtert uns nur Einträge von dem Tag aus dem mit GZIP gepackten Logfile.
Mit ‚grep  „GET /2016/07/13/qmmp-mp3-fedora-24“‚ filtern wir auf die Landingpage, d.h. die Aufrufe des Artikels, die geschehen sind, als er Startbeitrag auf der Startseite war und diese aufgerufen wurde, werden so nicht mitgezählt.
Das „grep -v google“ wirft den Googleboot raus, ziemlich penetranter kleiner Kerl übrigens, der kommt schon fast im 5 Minuten Takt an der Landingpage vorbei um zu schauen, ob die sich geändert hat.
AWK sollte man als Admin kennen, hier wird es benutzt um nur die IP, die als erstes in der Logzeile steht, auszufiltern.
„sort -u “ kickt die doppelten Einträge der IP raus.
„wc –lines“ zählt dann die übrig gebliebenen Zeilen, also das Ergebnis.

Und das Ergebnis war 112x .

Jetzt fragt man sich, was WordPress da eigentlich statistisch erfaßt und ohne in den Code schauen zu wollen, würde ich sagen: kompletten Schrott 🙁

Bestenfalls kann man an dem Ergebnis ablesen, wie Trends einzelnen Blogbeiträge so liegen, aber das wars schon.

Am Beispiel vom SuperTuxKart Beitrag von heute: 22x laut WordPress, 134x laut Apachelogfile (-google und doppelten)  (bis zu diesem Artikel) also auch wieder Faktor 6 ( 500% mehr ) Abweichung.

D.h. ab sofort geht mir die Statistik am …… vorbei 😀

Update: ein Plugin soll das Problem lösen, indem es den Job übernimmt. Ich hab es mal aktiviert. Also nicht wundern wenn es die nächsten Tage noch wenig anzeigt.