Disclaimer: für alle, die jetzt ein Déjà-vu haben: Ja, es gibt schon einen sehr ähnlichen Thread, nämlich den hier. Der läd aber zum Laden veralteter Informationen ein (was regelmäßig passiert) und der Post lässt sich nicht mehr anpassen. Deswegen jetzt ein Update
Wenn Du also auf der Suche nach Podcast Statistiken bist, hier gibt es ein paar Daten für Dich.
Konkret handelt es sich um einen sporadisch durchgeführten Web-Crawl des Apple Podcast Verzeichnisses.
Wann immer ich das mache erzeuge ich eine Reihe von json-Dateien und gelegentlich auch Excel Spreadsheets. All diese Informationen findet ihr in Zukunft zentral in diesem Verzeichnis.
Der Crawler ist in Python geschrieben und relativ hacky. Wer will findet ihn auf github.
Zu den einzelnen Dateien:
Ich teile die Ergebnisse in folgende Dateien auf:
data_all.json - alle Podcasts deren Feeds zum Zeitpunkt des Crawls erreichbar waren.
data_en.json - alle Podcasts, deren Feeds im Language Tag Englisch als Sprache ausgeben
data_de.json - alle Podcasts, deren Feeds im Language Tag Deutsch als Sprache ausgeben
data_all_20xx.json - alle Podcasts, deren Feeds im Jahr 20xx ein Update erfahren haben (also aktiv sind)
Außerdem konvertiere ich data_de.json und data_all_20xx.json in Excel Dateien mit der Endung xlsx. Wer will kann die mit Excel öffnen, allerdings solltet ihr Euch bewusst sein, dass insbesondere data_all_20xx mit mehreren hunderttausend Zeilen eigentlich außerhalb der Spec für Excel ist.
Ein paar weitere Disclaimer/Hinweise:
die Aufteilung via language Tag ist leider nicht 100% akkurat. Im Grunde kann da alles mögliche drin stehen und deswegen gibt es vereinzelte Fehler. Wenn mir Ungereimtheiten begegnen, behebe ich sie aber beim nächsten Crawl mag so manches wieder auftauchen und ich lebe mit dieser Unschärfe.
Startpunkt ist der Deutschsprachige Apple Podcasts Store wie er online steht. Was dort nicht durch Browsen gefunden werden kann steht auch nicht in meinem Dump.
Ich behalte nur die Einträge deren Feeds ich zum Zeitpunkt meines Crawls abrufen kann. Das sorgt garantiert für eine gewisse Fehlerquote, z.B. wenn mein Crawler vorbeikommt während der Server gerade updated o.ä. (ist tragisch, aber im Grunde angesichts hunderttausender Treffer auch einigermaßen egal )
die Grundannahme dieses Datendumps ist, dass fast alle Podcasts in Apple Podcasts gelistet sind. Damit sind Feeds die ausschließlich über die Webseite verteilt werden oder auch Soundcloud Podcasts die nie in Apple registriert wurden außen vor. Vielleicht gehe ich das in Zukunft irgendwann mal an, derzeit gibt es aber sicherlich Feeds, die hier nicht gefunden werden.
Trotzdem lehne ich mich einfach mal aus dem Fenster und behaupte diese Datenbasis ist mit Sicherheit gut genug um repräsentative Aussagen zu treffen. Die große Mehrzahl der Podcaster registrieren sich eben bei Apple, da das bisher der de-fakto Standard und Haupt-Verteilungsweg für Podcasts ist.
Es gibt Informationen in Apple Podcasts, die ich bisher nicht erfasse, etwa die Kommentare oder das durchschnittliche Ranking. Der Grund ist, dass dazu weitere Crawls notwendig werden und man ja eigentlich auch plötzlich alle Landesstores anpingen muss. Vielleicht spiele ich damit irgendwann mal rum, derzeit ist aber nichts geplant.
Jedesmal wenn ich einen neuen Dump ins Verzeichnis packe werde ich diesen Thread hier mit den Quick Highlights und ggf. speziellen Hinweisen anpingen. Wenn Du mit den Daten arbeiten willst wäre es nett wenn Du auf die Quelle hier hinweist. Außerdem wäre es toll wenn Du Erkenntnisse hier mit reinwirfst, so lernen wir alle Neues über unser Lieblingsmedium
Es gibt übrigens auch ein Limit für Beiträge hintereinander. Ansonsten hätte ich das noch in Ungelistete Podcasts untergebracht:
Ich habe mal id566623322 / SWR2 Feature also einem meiner Beispiele aus dem anderen Thread hinterhergeforscht. Der Podcast ist auch im neuen Dump nicht enthalten. Dabei hat der feed ein language-Tag mit ‘de’. Und es findet sich auch über das Verzeichnis auf Seite 33 in “Gesellschaft und Kultur” unter S. Aber mir ist dabei aufgefallen, dass diese Seite nur über “Weiter” zu erreichen ist. Könnte es sein, dass sie beim Auslesen der pagination durchrutscht? (Nebenbei gibt es auch noch eine gar nicht aus dem Interface zu erreichende Seite 34 mit einem einzelnen Podcast darauf. Keine Ahnung, was das zu bedeuten hat.)
Eben die Paginierung umgeschrieben und dabei auch dieses Rätsel gelöst
Stellt sich raus: iTunes zeigt immer den letzten Podcast der Kategorie sobald Du über das ende der Paginierung hinaus gehst. Deswegen sieht Seite 35 als Nachfolger der von Dir verlinkten 34 auch ganz genauso aus
Hm, aber in dem Fall der beiden Seiten, die ich verlinkt habe, ist der Podcast auf Seite 34“Sɛbɛnni Ni Taama” und bei mir taucht der auf Seite 33 nicht auf.
Für mich ist nur wichtig zu sehen, dass alle nachfolgenden Pages immer auf denselben und immer nur auf einen Podcast zu verweisen scheinen. Das nutze ich jetzt als Signal am Ende der Pages angelangt zu sein und gehe dann zum nächsten Startbuchstaben über.
Du könntest aber trotzdem recht haben und ‘Sɛ’ ist am Ende der Sortierung und damit der letzte Eintrag. Nur in der normalen Liste wird dieser Eintrag nicht gezeigt. Zunächst: Man kann anstatt einem Buchstaben auch Zeichenketten angeben. Bei mir ist der letzte Eintrag auf Seite 33 “Słucham Gadam”, wenn ich aber mit der Zeichenkette ‘Sł’ suche, bekommen ich zwei Einträge zurück. Der zweite “Słuchowisko. Pogadajmy o życiu” wird aber auf Seite 33 auch nicht eingezeigt.
Schließlich nochmal der Verweis, wenn man über dieses Webinterface alle Podcasts einsammeln will, muss man je Kategorie etliche Sonderzeichen durchgehen.
Ein paar sind in den jeweiligen Sprachen nur kleinere Ergänzungen zum Standardalphabet. Beispiele:
Besonders viel würde ich bei Chinesische Schriftzeichen (also chinesische Sprachen, Japanisch, teilweise Koreanisch, Vietnamesisch) erwarten 日, 中. Gerade hier könnte die Zahl der Podcasts mit der Beschränkung auf Standardalphabet plus ÄÖÜ sehr stark unterschätzt sein.
Ist natürlich erst relevant, wenn man seine Aufmerksamkeit auf das Verzeichnis in seiner Gesamtheit richtet. Aber die Zahl der IDs, auf die man unter Einbeziehung all dieser Sonderzeichen kommt (vermutlich Größenordnung 10³ also keine triviale Ausweitung des Aufwands), könnte man bestimmen, ohne dann auch die ganzen zugehörigen Feedinformationen einzusammeln.
Das ist ein Fass ohne Boden. Kennst du irgendwo eine Liste solcher Buchstaben oder hast einen Vorschlag wie man die generiert? Man müsste ja quasi für alle durch Apple unterstützen Länder erst die Sprachen und dann die nicht im Web interface aufgeführten Buchstaben ermitteln und dann selbige crawlen…
Bei den Alphabet- und Silbenschriften könnte man das mit Fleißarbeit auch noch händisch machen. Also zum Beispiel Russisch über Wikipedia (wo alle Alphabete/Silbenschriften/Logogramme irgendwo beschrieben sind) raussuchen und dann “АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЫЬЭЮЯ” wie “ÄÖÜ” hinzufügen. Allerdings gibt es schon im Kyrillischen durchaus Unterschiede. Das Kyrillisch, das Serbisch verwendet, ist nicht ganz identisch mit dem, das Russisch verwendet. Und spätestens bei Logogrammen wie eben Chinesische Schriftzeichen gehen zumindestens die am häufigsten verwendeten in die Hunderte. Es müsste aber eigentlich Python-Bibliotheken für die ganzen Unicode-Schriftzeichen geben über die man sich dann die Abfrage zusammen bauen kann.
Es gibt noch eine Möglichkeit: Man könnte einmal die komplette Unicode range gegen das Webinterface laufen lassen und behält jedes Zeichen, was nicht vom Verzeichnis auf die Sonderzeichen (#) gemappt wird, also andere Ergebnisse bzw. ein leeres Ergebnis zurückliefert. Da sollte man für die über 100.000 Zeichen aber großzügige Wartezeiten zwischen den Abfragen einfügen, denn das könnte wie ein Angriffsversuch aussehen. Ergänzung: Allerdings beim letzten Ansatz müsste man dann vermutlich hinterher doch wieder Sachen ausfiltern. Ich habe mal geguckt Chinesische Schriftzeichen in Unicode umfassen rund 90.000. Das jedesmal für jede Kategorie durchzuprüfen ohne auf die häufigsten Zeichen zu reduzieren, ist vermutlich nicht sinnvoll. In Unicode finden sich zudem die Schriften toter Sprachen, Hieroglyphen zum Beispiel, die eventuell nicht unter die Sonderzeichen fallen.
Insgesamt wäre es zu bevorzugen, wenn man über eine API alle IDs für Podcasts im System erhalten könnte. Alternativ vielleicht einfach mal einen bug report machen, dass die ganzen nicht-lateinischen Schriften nicht vollständig unter Sonderzeichen aufgelistet werden?
@dirkprimbs Eigentlich könntest du die Suche nach IDs und den Datenabruf komplett trennen. Also einfach eine Liste von IDs, die immer weiter gefüllt wird. Dann könnte man auch verschiedene Verfahren probieren um IDs zu finden, die nicht über das Standardalphabet / die Sonderzeichen erreichbar sind. Aufwendigere Verfahren nutzt man dann einfach seltener. Wie gesagt für die andere Alphabete oder Silbenschriften kann man den crawler modifizieren. Wenn du willst, könnte ich die entsprechenden Strings hier zusammenstellen.
Bei den chinesischen Schriftzeichen sind mir auch noch zwei andere weniger brute force-artige Ansätze eingefallen: Es gibt ja in den Kategorien jeweils eine Liste der beliebtesten Podcasts so auch in der japanischen und chinesischen Variante (Apple ist nur in Hongkong oder?). Deren Titel kann man einsammeln, nimmt die chinesischen Schriftzeichen, dort wo sie am Anfang eines Podcasts stehen, und beschränkt sich bei der Suche erstmal auf diese Zeichen. Da sollte man schonmal viele der häufigeren mit erschlagen. Zudem kann man auf der Seite dieser Podcasts, die IDs unter “Zuhörer haben auch Folgendes abonniert:” oder, wenn sie zu einer Sammlung gehören, diese IDs einsammeln, den Vorgang mit den neuen IDs wiederholen usw.
Ich muss da erst einmal wieder Zeit für finden. Ich schätze mal die Frage ist einfach wie wichtig mir ein korrektes Abbilden dieser Zeichenbereiche letztlich ist. Während ich noch bei kyrillisch und den verschiedenen Sonderzeichen Europäischer Länder in Versuchung bin zu ergänzen komme ich bei der Masse an asiatischen Schriften schnell in einen Bereich in dem wir von Grenznutzen sprechen. Selbst wenn ich die alle sammle kann ich tatsächlich mangels Sprachkenntnis kaum eine sinnvolle Aussage treffen außer der Gesamtzahl. Das ist spannend aber nicht unbedingt mein Fokus und mir vielleicht auch den Aufwand erst mal nicht wert.
Allerdings ist der Crawler ja genau deswegen veröffentlicht: Jeder darf ihn gerne nehmen und ergänzen. Ich freue mich dann über entsprechenden Rücklauf und Optimierungen
Hm, die haben da umfangreiche Angaben zu den Datenfeldern, auf die man Zugriff bekommen kann. Die Feed-URL scheint nicht dabei zu sein. Ich bin mir nicht sicher, ob das auch Podcasts umfasst.
Eine letzte Beobachtung für heute. Ich habe mal probeweise IDs über die Podcastseiten eingesammelt. Also einfach für rund 1000 IDs die Seite heruntergeladen und daraus IDs geerntet. Dabei habe ich 970 gefunden, die nicht in der Liste aller IDs aus dem Datensatz sind.
)
