Gestiegener Traffic - Podlove Statistik weicht von Server-Statistik ab

Hallo zusammen,

seit Dezember habe ich - für meine Verhältnisse - extrem gestiegenen Traffic auf meinem Projekt unter dem auch der Podcast läuft.

Die Statistiken für Dezember Episode in den Podlove Statistiken sagt: 88 Aufrufe. Schaue ich mir meine Server-Statistik an, dann steht dort bei der m4a-Datei ein Wert von >540 Aufrufe. Diese Datei ist auch für den Grossteil des Traffics verantwortlich. (allein in den 5 Tage im Januar schon wieder >1GB Traffic allein durch diese Datei, aber kauf Aufrufe laut Podlove Statistik)

Fragen:

  1. Wie wird der Aufruf innerhalb Podlove erfasst? Wird hier alles gezählt, was diese Datei auf dem Server aufruft? Wenn ja, woher kommt die Differenz?

  2. Hat jemand eine Idee, wie ich herausfinde, woher exakt diese Zugriffe auf die m4a-Datei stammen? Würde gern die Quelle finde um den Traffic zu reduzieren/zu prüfen inwieweit das alles korrekt läuft.

Danke bereits vorab.

Der Publisher macht Frontend Analytics vor dem Download und reagiert auf die erste Anfrage, zählt dann Redirects und leitet einmalig an den Server weiter. Wie oft die weitergereichte URL dann tatsächlich geladen wird (keinmal, einmal, mehrmals) weiß er dann nicht. Daher kann es zu Diskrepanzen kommen.

Die Quelle der Downloads kannst du letztlich dem Web Server Logfile des Servers entnehmen. Dort müsstest Du auch gut unterscheiden können, was die ursprüngliche Quelle des Zugriffs war (ptm_source), weil der Publisher dem Redirect noch diverse Tracking-Parameter hinzufügt.

Dazu gehört seit Neuestem übringens auch eine ID, die für jeden Redirect erzeugt wird (ptm_request). Wenn also eine URL im Backend mehrfach geladen wird, sollten sich die Zugriffe anhand dieses Wertes erkennen lassen.

Danke Timm für die Rückmeldung.

Ok, aber in diesem Ausmass (88 zu >540) ist doch recht ungewöhnlich, oder?

Das passiert aber nur, wenn der Abruf über den Player oder den Feed erfolgt, oder? Ich habe den dumpfen Verdacht, dass die .m4a irgendwo/irgendwie direkt aufgerufen wird. Das wird durch den Publisher doch nicht registriert, oder?

Mag sein. Aber bevor wir nicht ins Log geschaut haben schwierig zu beantworten. Weiß der Geier, was da bei Dir aufschlägt. Welches Tool generiert denn die Zahl “540” auf Basis wovon?

Nun, die URL muss ja zunächst einmal irgendwo generiert und bereitgestellt werden. Wenn die nackten URLs nicht auf der Website oder im Feed stehen, woher sollten sie kommen?

Du müsstest schon mal Deine Website nennen und auch mal in Deine Logs schauen, sonst stochere ich da im Dunkeln.

Ein blödes Auswertungstool könnte sich z.B. von iPhones verwirren lassen: die laden nämlich alles in Häppchen. Wenn Dein Tool jedes Häppchen zählt wird aus 88 schnell 540.

Das sind die Stats die mein Managed-Server mitbringt (nennt sich AWStats). Hab beim Hoster schon angefragt, ob die mir noch mehr Daten/Infos geben können und warte derzeit auf eine Rückmeldung.

Sorry, hatte ich vollkommen vergessen zu nennen. Es geht um diese Episode: http://lex-blog.de/2016/12/17/sus003-luisa-todisco/

Bei den anderen bisherigen Episoden gibt es auch Differenzen, aber diese sind bisher deutlich geringer. Zumindest war dies bis Dezember so. In den bisherigen 5 Tagen im Januar tendieren sie auch so langsam in eine ähnliche Grössenordnung laut der Serverstatistik.

Das stimmt und gibt mir gerade zu denken. Ich nahm bisher an, dass der Link zum Speicherort auf meinem Server über den Downloadweg im Webplayer sichtbar ist, aber dort steht ein andere, nämlich die, welche über den Publisher generiert wird. Am Ende wird ja aber schon die Datei angesprochen und evtl. wertet die interne Serverstatistik das auch nur so aus!? Das weiss ich leider nicht. :frowning:

Das kann ich natürlich leider nicht ausschliessen. Dann sollte sich das aber auch bei den anderen Episoden an sich zeigen, die bisher ca. doppelt so viele Abrufe haben wie die Episode 3 (laut Podlove Statistik).

Grundproblem - und deswegen bin ich überhaupt drauf aufmerksam geworden - ist eben der Anstieg des Traffics im Sinne von GB. Bisher waren es so 1-2, lass es mal 3GB im Monat gewesen sein (dort laufen meine 2 grössten Projekte - Blog & Community). In den letzten 5 Tage kamen nun schon >30GB zusammen. Nicht alles die .m4a-Dateien, aber zusammen schon ein grösserer Anteil daran. Selbst wenn das iPhone in Stückchen lädt, lädt es dadurch ja nicht mehr als die Stückchen zusammen an Dateigrösse haben, oder?

Sorry wenn ich hier vielleicht auch einfach das Big Picture nicht sehe, Dinge missverstehe, mich verwirren lasse oder mich verwirrt ausdrücke. Ich bin kein Programmierer und kann Server auch nicht über ne Shell bedienen etc (deswegen ja auch Managed Server). Ich hab schon gutes technisches Verständnis, aber mein Fachbereich und meine Skills liegen diesbezüglich in anderen Bereichen… :frowning: Daher meine Anfrage hier. Wenn noch Infos fehlen, einfach sagen. Mehr als die Webstatistik des Server und die Podlove-Stats habe ich aktuell leider nicht.

Ein durchgedrehter Client kann da schon die Erklärung sein. daher würde ich tendenziell den Frontend Stats mehr Glauben schenken was die tatsächliche Nachfrage betrifft. Was den gestiegenen Traffic betrifft kann nur ein Admin Licht ins Dunkel bringen.

Heißt das, dass quasi jeder Feed individuell ist und jeder Feed andere Links enthält?

Wenn ja, kommt dann bei jedem neuen Feeddownload auch immer ein neuer Link?

Wenn die Analytics angeschaltet sind, ist das so, ja. Man kann in den Analytics ja immer genau nachschlagen, über welche Quelle (Webseiten, Feed) und im Detail noch wo genau (Wo auf der Website, welcher Feed) das lief.

Jedes mal wenn die Download-URL im Feed neu evaluiert wird, wird ein neuer Link auf die Zieldatei erzeugt. Der unterscheidet sich dann immer im Parameter ptm_request, die anderen bleiben konstant.

Der Redirect ist ein permantenter Redirect ( 301 Moved), d.h. ein korrekt programmierter Client sollte die URL nehmen und nicht noch einmal auflösen (da die Weiterleitung “permanent” ist). Machen sicherlich manche Clients nicht (z.B. bei einem Re-Download), da haben wir aber keine konkreten Recherchen durchgeführt.

2 „Gefällt mir“

Dazu nochmal ein (hoffentliches finales) Statement:
ganz klar woher die enorme Anstieg des Traffics kam, konnten wir nicht herausfinden. Aber es wurden verschiedene Verzeichnisse für Bots blockiert und seit Februar hat es sich wieder stabilisiert und der Datentraffic ist wieder auf einem normalen Niveau, wie es auch bis November ungefähr war.

Danke für die Rückmeldungen. Für mich ist das aktuell erstmal abgehakt.