Crunching numbers for Analytics takes time, especially for popular podcasts with many downloads. The old system was written optimistically and “let’s-hope-we-finish-before-we-run-out-of-time”-ish. That was certainly good enough for podcasts with a few hundred downloads per episode, but more likely a gamble for popular shows.
To solve this issue in a scaleable way, we built what is known as “background processing” or “queues”. That way we can break big tasks into small chunks and process them step by step. You don’t really need to know about this, since the main effect is that calculating analytics should be a smoother experience (if you have ever had troubles in that regard) but if you are curious, have a look at the new “Tools” section, which lists running and recently finished jobs.
New Analytics Dashboard
“Downloads per Day” is a stacked bar chart now so you can see which episode is responsible for peaks
Downloads table now shows downloads in time segments starting from the moment of episode release for better comparability
Show total number of all downloads in Analytics Dashboard
New information under downloads table: age of the data and when the next refresh is due
MUCH better performance / page load times
New option to configure how many episodes per page should be shown
Podlove Web Player 2 Facelift
simplified, modernised look
responsive layout for mobile devices
fix: updated mediaelement library to fix volume bar display bug
Podigee Podcast Player
The Podigee Podcast Player is available as an alternative to the Podlove Web Players. It supports everything you can expect from a modern web player like chaptermarks. It is also embeddable.
New “Tools” Menu
A new maintenance section gathers tools like the “Repair” button in one place
There is a new section for analytics related maintenance
Import & Export is now in the “Tools” menu
Improved Logging Display
Logging is now in the “Support” menu
add filtering for different severities
hide “info” entries by default
improve readability of data sections
Other
add Emoji support for episode subtitle, summary and chapter marks (requires WordPress 4.2 or newer)
Web Player setttings moved from Expert Settings to Podcast Settings
When activating the plugin, add mp3 asset and feed to help users get over the most confusing part of the setup.
Post thumbnails can be used as episode covers (see settings in “Episode Assets”). This is the new default.
add contributors shortcode to default template (Many people activated contributors and then wondered why they were not displayed in the episode. Now the shortcode is part of the default template, but only if the contributors module is active.)
add unmistakable warning if curl is not available and provide actionable steps for a solution
change feed setting “Include HTML Content” default to “on”
remove log entries for beginning and ending asset validations
move feed protection into separate module
move debug log from Dashboard to Support page
add ptm_request parameter to redirected tracking URLs which contains a uuid
add option to enforce http or https in URLs inside feeds (enclosures, images) and the actual feed URLs; see Expert Settings > Website
improve tracking: ignore 1-byte requests
update user agent library (new/updated clients: Podcat, Downcast, iCatcher, BashPodder)
show total downloads per site in network dashboard
remove <itunes:keywords> from feed (it disappeared from the specification)
remove module: “Feed Validator”
update recommended image size to 3000x3000 pixel
add heartbeat to keep note of when tracking is active
shortcode_exists($shortcode_name) is now available in Twig templates
system report: add notice if ALTERNATE_WP_CRON is active
fix tracking export: keep httprange
fix compatibility with other plugins relying on Spyc library
fix {{ episode.duration.totalMilliseconds }}
fix image caching issue (invisible characters)
fix: When plugin requirements are not met, admin notices are now still shown once but the plugin is automatically deactivated after that. This avoids faulty setups.
Hallo, ein Kollege hat mich darauf gebracht, die Analytic-Zahlen zu vergleichen.
Was genau hat sich denn jetzt bei der Berechnung der Zahlen geändert.
Wenn ich auf meine Zahlen schaue, dann zeigt mir “Total Downloads” doch eine signifikante Änderung an.
Aus 374 Downloads in 2.3.18 sind 305 Downloads in 2.4.0 geworden.
Was stimmt denn da jetzt?
Und wie kommt es zu der Änderung?
Wir haben die Erkennung nicht zählenswürdiger Downloads verbessert. Es werden mehr Bots und ungültige Zugriffe als solche erkannt und von der Zählung ausgeschlossen. Viele Bots schauen regelmäßig vorbei, weshalb die Ratio bei dir um so kleiner ist, je älter die Episode.
Erstaunlich, was sich da alles auf der Download-Seite herumzutreiben scheint. Habe mir jetzt mal die user_agent-table angeschaut. Und da gibt’s wirklich welche, die keines oder ein Byte herunterladen? Für was für einen Zweck denn? Um zu sehen, ob der Download noch möglich ist?
Ich habe gerade nachgesehen, welche Clients die 0-1 Byte Requests erzeugen. SQL Query dazu:
SELECT
COUNT(*) cnt, ua.*
FROM
`wp_podlove_downloadintent` di
JOIN `wp_podlove_useragent` ua ON ua.id = di.user_agent_id
WHERE `httprange` = "bytes=0-1"
GROUP BY ua.id
ORDER BY cnt DESC
Die cnt Spalte zählt wie häufig die Anfrage von dem Client kam. Scheint vor allem Apple-Software zu sein.
Hm, interessant. Scheinen nur mobile-devices zu sein. Jedenfalls bei mir. Und dann nur Browser-Zugriffe oder iTunes (selten). Von daher vielleicht jemand, der eine Episoden-website in Safari oder Chrome aufruft und dieser client überprüft, ob ein Download verfügbar ist.
BTW, kann es sein, dass sich bei der Analyseberechnung ein Fehler eingeschlichen hat in 2.4. Also, dass meine Episoden heruntergeladen werden glaube ich ja, aber dass jede Episode zur Hälfte heute heruntergeladen wurde, gibt mir zu denken.
“1d” ist nicht “In den letzten 24 Stunden”, sondern “Am ersten Tag nach Episoden-Veröffentlichung”. Alle Zahlen sind relativ zur Episodenveröffentlichung, damit sind sie vergleichbar.
Ach so, na dann ergeben die Zahlen Sinn. Ist aber ein bißchen unglücklich, da das Diagramm, das sehr schön gemacht ist, sich wieder absolute Datumsangaben bezieht. Aber ich erkenne, dass man abwägen muss. Um möglichst fein granular Auskunft über die Downloads zu geben, muss man für jede Episode relativ mitwandern. Würde man das nur vom aktuellen Datum aus betrachten, wird es immer unscharfer, je weiter man zurückblickt. Vielen Dank für Deine Auskunft. Vielleicht wäre ein kleiner Hinweis auf die Bedeutung der Spalten sinnvoll. Aber jetzt werde ich das erstmal auf’s Produktivsystem aktualisieren.
das mit den Background Jobs ist ganz, ganz großes Tennis, vielen Dank! Ich hab jetzt gar nicht so genau geschaut, um wieviel Prozent die angegebenen Download Zahlen sich verringert haben, gefühlt schon eine Menge aber vielleicht weniger als 20%. Gutes Gefühl, jetzt näher an der Wahrheit zu sein, aber noch viel besseres Gefühl, die Analytics innerhalb von Sekunden angezeigt zu bekommen, und nicht erst nach Minuten
Hab grad auf 2.4.0 upgedatet, jetzt sind die ganzen alten Downloadzahlen weg…
Hab ich was falsch gemacht? Oder ist das normal?
Kann ich die Daten irgendwie wieder herstellen?
