„Wieviele Leute hören sich eigentlich euren Podcast an?“, fragt Nadine hier und wir antworten: „Das wüssten wir auch gerne!“
Das Auswerten der Podcasts ist nämlich nicht so einfach. Klar kann man sehen, dass das MP3 des gestrigen Podcasts 1.503 mal, das vergleichbare vom Vormonat (2.6.) 2.527 mal abgerufen wurde. Aber sind das komplette Downloads? Oder jeder angefangene Hörversuch?
Und was ist mit den Dateien, die irgendwo im Cache oder Proxy hängen? Als ich neulich einen Podcast ca. 15 Minuten nach dem ersten Upload ausbessern musste (Musikrätsel vergessen…), dauerte es mehrere Stunden bevor die neue Version bei iTunes zu hören war, ein Indiz dafür, dass iTunes offenbar zwischenspeichert. Gleiches ist von anderen Podcast-Portalen zu erwarten, Bloglines et al.
Kennt jemand eine Methode, mit der man die Podcast-Hörer verlässlich zählen kann?
1 – 2- 3 Durchzählen ! Gibt’s da nicht nicht solche Zähler wie bei Ebay ? Funktioniert das auch bei RSS Feeds ? Wie wären denn dann die Podcast Charts ermittelt ?
Die bei iTunes? Oder welche meinst du? Die meisten Seiten-Zähler funktionieren über ein JavaScript, eher schwierig bei ’nem MP3.
Komplette Downloads vs. abgebrochene ist einfach, Apache loggt normalerweise auch das übertragene Datenvolumen.
Dass du niemals ermitteln kannst, ob jemand eine Audiodatei komplett hört, wirst du nicht feststellen können, solange es runtergeladen wurde. Bei einem Stream könnte man das schon eher ermitteln.
Zu iTunes: iTunes cached lokal bei jedem Benutzer. Ich hatte auch etwas umgestellt in meinem Podcast Technikwürze und musste mir was einfallen lassen, dass iTunes die Folge neu runterlädt.
So funktioniert es: Rechten Mausklick auf eine Folge, dann „Original zeigen“. Man bekommt im Finder oder Expolorer den Ordner, wo die Folgen enthalten sind. Am besten den gesamten Oberordner löschen. Hat man das getan, bekommt man augenblicklich alle Folgen neu, ohne cache.
Technisch kann ich ziemlich wenig beitragen, aber mal einen verhältnismässig ernüchternden Erfahrungswert in die Runde werfen. Vor zwei Jahren, ungefähr, habe ich für einen Kunden konzeptionell eine Website betreut, die mit längeren Soundfiles gearbeitet hat (knapp unter einer Minute). Das war zwar nicht Podcasting, aber darauf angelegt, dass es bis zu Ende gehört werden sollte. Weil gestreamt wurde, konnten die Techies mit einigem Aufwand auslesen, wie lange zugehört wurde. Von 10 Hörern haben zwischen 4 und 5 bis zum Ende ausgehalten. Kann natürlich auch an meinen bocklosen Texten gelegen haben.
Wenn ich mir anschaue, wieviele Podcasts abonniert/heruntergeladen, aber ungehört von mir aus iTunes gelöscht werden, sind selbst „verlässliche“ Downloadzahlen nur ein Indiz für die obergrenze einer tatsächliche Hörquote.
Streaming ist aufgrund der Podcast-Natur ausgeschlossen.
Es gibt aber eine Möglichkeit, in .mov Dateien am Ende ein HTTP-POST Mechanismus zu implementieren – sowas in der Art macht ja auch Microsoft oder RealNetwork, um „Feedback“ zu bekommen.
Nur — auch hier glaube ich, macht das nicht viel Sinn. Was ist mit den ganzen Podcasts, die wirklich auf einem portablen Player oder Netzanbindung gehört werden“¦
Das alte Cache-Problem, gezählt kriegst Du es nie wirklich. Du kannst höchstens versuchen, mit etwas Logfile-Trickserei unique combinations anhand von Zugriffszeitraum, Browser-Version und IP-Adresse hinzukriegen.
Aber es werden immer Näherungswerte bleiben.
Das einzige, was man machen könnte – was aber nicht sonderlich praxistauglich ist -, ist den Podcast als Quicktime-Datei verpacken und mit SMIL ausstattet. Das SMIL könnte dann ein Bild laden, und das wiederum könnte man tracken. Aber dadurch wirds dann halt wieder proprietär – und das kann auch m. W. nach kein mobiler Player abspielen. Da könnte man höchstens mal drauf hoffen, daß das mal demnächst die iPods unterstützen.
Eine weitere Alternative wäre, die Datei mit einem No-Cache-Header auszuliefern und den Abruf für Proxies dynamisch aussehen lassen (also mit URL-Parametern). Am besten noch mit einem Redirect verbunden. Dadurch dürften die Messungen, wieviele ABRUFEN ggf. etwas genauer werden – wer tatsächlich hört, das weiß man nie so recht.
Aber ich habe gehört, daß im Radio Gewinnspiele ein tolles Instrument zur Reichweitenmessung sein sollen ;-)
zumindest die downloads direkt bei dir kannst du ja zaehlen. wenn im server-log der HTTP Error Code „200“ steht, wurde das file komplett heruntergeladen. abgebrochene downloads bekommen „206“. allerdings musst du davon wieder die rausrechnen, die download-manager verwendet haben. denn die holen das file stueckchenweise und erzeugen nur „206“. aber vielleicht haben die ja ’nen vernuenftigen USER_AGENT oder du musst die volumen aller „206“ der gleichen IP in einem zeitfenster addieren, um wieder einen echten download zu zaehlen.
pille
Registrierungszwang und Download nur von einer Quelle, die durch die eingabe der Login-Daten erreichbar ist.
Verlässlich aber verächtlich.
@Yves (Streaming ist aufgrund der Podcast-Natur ausgeschlossen):
Flash-Player auf die Seite, Podcast abspielen, Download geht weiter während der Podcast spielt = streaming.
Alle User zwingen, sich bei Last.fm anzumelden. Dann hier
http://www.last.fm/music/Spreeblick
nachschauen ;)
Das mit Streaming, Mov und Flash Dateien halte ich für keine so gute Idee. Man könnte damit zwar das Download- und Hörverhalten der User nachvollziehen, aber eine eigenständige MP3 Datei hat einen, wie ich finde, nicht unerheblichen Komfortvorteil für den Endverbraucher. Ich zum Beispiel lade mir die Datei runter und höre sie mir später gerne auf meinem MP3-Player an. Mit denn oben genannten Dateiformaten wäre das nicht mehr so einfach möglich.
Ich denke die Downloadzahlen haben schon eine gewisse Aussagekraft, denn auch wenn der User sich die MP3 nicht fertig anhört, dass er sie runtergeladen hat zeugt doch schon mal von seinem grundsätzlichen Interresse daran.
Das mit dem Gewinnspiel, wie von „Die Stimme der freien Welt“ angesprochen wäre ja mal einen Versuch wert.
Ich hab mich damit zwar noch nicht so auseinander gesetzt, aber ist Feedburner nicht relativ ordentlich, um die Zirkulation eines Feeds/Podcasts zu dokumentieren?
FB zählt auch nur die Zugriffe, nicht die „Verweildauer“.
lustige Diskussion…
Ich meine auch für TextBeiträge geben logfiles nur das erfolgreiche Ausliefern einer Seite an. Ob der Belieferte das dann auch gelesen und sogar noch verstanden hat, ist fraglich… Also ist es letztendlich beim PodCast ‚das Selbe‘.
Alles andere wäre schon wieder DRM. Digitales Reichweiten Management. Mit Zwangsregistrierung inkl. Überwachung. Bäh. Nee. Will ich nicht…
olli
Nee, es geht doch nicht darum, wer es nun wirklich *anhört*, das ist ja unmöglich. Aber die Zugriffe via iTunes und anderer Clients wären schon spannend.
Tja, dann würde Feedburner also doch reichen…
Und wozu der ganze Aufwand?
Langt das nicht, zu wissen, dass der viel gehoert wird oder nicht?
ich höre den podcast regelmässig und immer im player der im google reader drin ist… davon bekommt ihr sicher nirgendwo was mitgezählt…
André, die Zahlen wären spannend für eventuelle Werbekunden, aber ich finde es auch nicht uninteressant zu wissen, wieviele Leute zuhören (oder zumindest damit beginnen :)).
Zu den Downloadzahlen wurde nun ja schon viel gesagt. Was die Hörer angeht:
Ich für meinen Teil höre eigentlich immer bis zum Ende zu, und da es bei Euch selten langweilig wird, sogar so gut wie immer recht konzentriert. Allerdings höre ich selten einen Podcast am Tag des Erscheinens, weswegen ich leider keine Chance habe an Musikrätseln teilzunehmen.
Aber richtet doch einfach eine E-Mail-Adresse ein und bittet mal eine Woche lang in jedem Podcast die Hörer, dort eine leere E-Mail hinzuschicken, bei der im Betreff steht, ob sie’s gehört haben und ob sie bis zum Ende dabei geblieben sind. Kann mir gut vorstellen, daß sehr viele Spreeblick-Hörer da mitmachen würden.
Einfach mal eine Umfrage starten und auf rege Beteiligung hoffen. Dabei am besten im Podcast ankündigen.
Downloads zählen ist eigentlich gar nicht so schwer: Einfach doppelte Zugriffe von einer IP innerhalb eines gewissen Zeitraums herausfiltern, und sich überlegen wie man unvollständige Abrufe zählen will. Das ist dann natürlich immer noch nicht die Zahl der Hörer, ob jemand eine Datei heute und gestern zweimal heruntergeladen hat, oder drei verschiedene Personen hinter einem Router weiß man natürlich nicht, wird man aber auch kaum herausfinden.
iTunes cached Downloads im übrigen nicht (mehr), so zumindest behauptet ein Mitarbeiter bei FeedBurner. Das Listing im iTMS updated erst nach einer gewissen Zeit, das stimmt, aber solange die alte Datei nicht mehr auf dem Server ist sollten da auch keine Zugriffe mehr kommen. Und wie in den Kommentaren bereits erwähnt wurde ist es natürlich noch mal eine ganz andere Sache wenn die alte Version bereits heruntergeladen wurde. Dann hängt es natürlich vom jeweiligen Programm ab ob er die Aktualisierung erkennt und die neue Version holt (in der Regel wohl nicht).