Am Ende habe ich tatsächlich händisch alle Einträge in der Tabelle podlove_download_intent, die auf die Benutzerkennung „Overcast/1.0 Podcast Sync“ verwiesen, gelöscht.
Unter Podlove/Werkzeuge habe ich die Buttons unter „Tracking & Analyse“ gedrückt - keine Ahnung, ob das erforderlich war, denn eigentlich werden diese Prozesse ja automatisch irgendwann ausgelöst.
Dann habe ich die WordPress-.htaccess wie folgt ergäntz:
BrowserMatchNoCase "Overcast/1.0 Podcast Sync" badbots
Order Allow,Deny
Allow from ALL
Deny from env=badbots
überprüft, ob dieser Block auch wirklich funktioniert. Was er tut.
Damit scheint das Problem für mich vorerst gelöst … Bis Overcast und ähnlichen Anbietern was Neues einfällt.
Alternativlösung:
Einfach bot-Feld beim jeweiligen User-Agent in wp_podlove_useragent-Tabelle auf 1 setzen, dann wird der jeweilige Agent rausgerechnet.
Hallo zusammen,
Ich hab mir mal die Zeit genommen und einen Blick in die Datenbank hinter meiner Podlove-Instanz geworfen, nachdem ich über ca. 2 Jahre jetzt unerklärliche regelmäßige Downloads in den Analytics angezeigt bekomme, die immer nur die neueste Episode meines Podcasts betreffen.
Dabei habe ich diese Downloads eindeutig dem Useragent „Overcast/1.0 Podcast Sync (+http://overcast.fm/)“ zuordnen können. So werden durch das Crawling von Overcast der jeweils neuesten Episode alle 1-2 Tage ein bis zwei Downloads zugerechnet, ohne dass tatsächlich eine neue Hörerin dazu käme. Meine Downloadstatistiken werden so also in etwa wertlos, weil mittlerweile über 500 der dort erfassten 2100 Downloads auf diesen Crawler zurückgehen.
Gibt es eine nachhaltige Methode, die Benutzerkennung aus den Berechnungen von Podlove Analytics auszuschließen?
(Was passiert eigentlich, wenn ich von Hand die Einträge aus der _download_intent-Tabelle lösche? Werden die Analytics dann neu berechnet und korrigiert dargestellt? Für Euch getestet: Ja, das geht, die Statistiken können dann neu berechnet werden, sodass ich jetzt korrektere Download-Statistiken habe.)
Klar, die Downloads aus der podlove_download_intent rauszulöschen ist eine Option, aber halt auch eine gefährliche, da man sich damit die Statistik grillen kann im schlimmsten Fall.
Für die Erkennung der Apps nutzt der Publisher die Device Detector Lib von Matomo (früher bekannt als Piwik), da wird der User-Agent als Overcast iOS erkannt und nicht als Bot. Müsste man da den PR aufmachen. Sobald das da drin ist und der Publisher geupdatet wird, würden die Downloads aus den bereinigten Statistiken entfernt werden.
Ich durchforste mal meine Logs über die Festtage. Mal sehen was ich da so alles finde, was man bei der Gelegenheit auch gleich in die Lib einspeisen kann…
Ich habe gerade entdeckt, dass es ein weiteres störendes Muster gibt, diesmal aber leider mit einem eher weniger offensichtlichen Useragent-String:
„Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36“
Führt zu einem wöchentlichen Download:
Sieht ja eigentlich nach Chrome-Browser auf, ist aber für einen normalen Abruf viel zu regelmäßig. Wieder immer nur die aktuellste Episode.
Ich versuche das so zurückhaltend wie möglich zu formulieren, aber verlierst du dich hier nicht etwas? Bei den Downloadzahlen über diesen langen Zeitraum sind die Statistiken eh überschaubar aussagekräftig, und wenn ich verhindern wollte, dass ein automatisierter Download pro Woche meine Statistiken verfälscht, würde ich zuallererst mehr Episoden als eine pro Jahr veröffentlichen um damit die echten Downloads hochzutreiben (und meinen Podcast generell interessanter zu machen). Was bringt es an den Statistiken rumzuoptimieren, dadurch hört doch keine Person mehr zu?
Ab davon: Bricht der Overcast-Blocker irgendwas für Overcastnutzer?
Ich will ja nicht die Downloadzahlen hochtreiben sondern hätte gern halbwegs korrekte Messungen und will systematische Fehler aus den Statistiken raus haben. Ansonsten sind Statistiken ja mäßig nützlich.
Ja, wenn du ein paar 1000 Hörer*innen pro Folge hast, interessiert dich der Fehler vielleicht nicht mehr. Aber wenn das nicht dein Ziel ist und es geht um kleinere Mengen, ist der Fehler relativ halt bedeutender. Und trotz der geringen Zuhörer*innen-Zahl interessiert mich trotzdem der Verlauf der Downloads.
Wie auch immer:
Ich hab nach genauerem Blick in die Doku festgestellt, dass ich abgesehen von der .htaccess auch einfach das bot-Feld in wp_podlove_useragent auf 1 setzen, dann wird der jeweilige Agent rausgerechnet. Dann weiß ich das jetzt und kann das hier auch schließen.
