What kind of data do you need to cut a swathe through all the commentators and tell you whether music download services are really going to spell the end of the album? Or whether on-demand features will change the relationship between listening to new music and owning it?
Notching up each extra zero on the end of the iTunes Music Store sales figures only gives you an impression of aggregate growth of this particular kind of service, the rate of growth, and market share relative to comparable services. This data will tell you that, in the next few years, more people are going to be downloading music, and the relative success of different services will wax and wane — which is not news really.
So I did some no-budget research and collected some data, based on the Last.FM service, the results of which ask more questions than they answer, but this process clarifies what further data would be useful.
I focused on Last.FM for several reasons. Initially I was interested in it because of my instinct that its 'radio' model will be more relevant in the long term (10+ years) than downloads. This in turn led me to some follow-up questions and reservations about patterns of use of online streaming services. But the clincher was a practical reason: unlike many online services, Last.FM makes some individual user data publicly available.
To recap: Last.FM provides users with an MP3 stream of tracks from artists and albums that it thinks those individual users will like. It builds a profile of each listener by (a) inviting them to specify favourite albums, and (b) monitoring how they react to the tracks they are played (each listener can say whether they 'love' each track, want to 'skip' it this time, 'ban' it from their playlist for ever, or they can do nothing and just neutrally listen). After a user has listened to around a hundred tracks, the system reckons it has a good enough understanding of their preferences to match them to other 'neighbour' listeners with similar preferences. Last.FM will then play you tracks favoured by your neighbours — for which there is no charge — or it will play you only tracks from your personal playlist — for which you must make a financial donation. Probably the major way the service generates revenue is via its affiliate relationships with the likes of Amazon: if you like a track so much that you click on the icon to buy it, Last.FM takes a cut from the merchandiser. Last.FM is a legal service registered with the MCPS/PRS.
One of the benefits of this kind of service, by comparison with stockpiling masses of tracks on your iPod and either creating a playlist or randomising the sequence, is that users can control how much control they have over what they hear, within a broad spectrum of options: your own playlist, a close neighbour, a slightly more distant neighbour and so-on up to totally random (and Last.FM has more tracks than the biggest iPod). But I digress.
You can see the basic details of each user profile on Last.FM: here's mine. These include when the user registered, when they last used the service, and how many songs they have in their profile. This provides very rough data about usage patterns for the service.
Back in February and March (the site has been redeveloped since then) I collected this data for over a hundred Last.FM users. These users were either 'neighbours' of my own profile, or neighbours or neighbours — not a truly random sample, but as reasonable as I could do. In nearly 30 cases the date of last use was not available on the site, so I could not calculate the number of days the users concerned had been 'active' on Last.FM and I ignored their data: this left 83 users with usable data. This is possibly not a large enough sample to be sure of being fully representative, but any macroscopic trends should be apparent in this data.
I was interested in what proportion of Last.FM users keep using the service over a significant amount of time and how the number of songs on a profile related to length of use of the service. For example, my data show 14 out of 83 users (i.e. 1 in 6) did not come back after the day they first registered. By the standards of many web sites, that's probably quite a low proportion or early leavers (and the data may make it seem lower than it is in reality for some of these users may yet return). It's one thing for sites to be 'sticky' in keeping users engaged for longer on a first visit, but more challenging to get them to come back another day.
There is still a strong trend for the majority of users to listen to Last.FM for a few days and then disappear. The median length of time between date of registration and date of last track heard was 11 days in my sample. Click on the thumbnail chart, right, to see the full scatter diagram of all the data (based on 83 users).
When I was collecting the data, I thought maybe some nice distribution would emerge (like the Zipf distribution for web site popularity). The picture is a lot more messy than that — partly because there are two ways users can bump up the number of songs in their profile. There's the gradual process of actually listening to them all; and then there's the option to prime the system with your preferences by searching for tracks or albums and adding them to your profile manually.
To zoom in on the main cluster of data, I cut out the 'outlying' data (people who had been listening for more than six months, or had more than 4,000 tracks in their profile), and you can see this subset of data in the diagram on the right (based on 58 users, click on thumbnail to open full-size diagram in new window).
The messiness of the data is interesting because it suggests there's not just one trend in usage, but several things going on at once 'behind' the figures.
It's clear that there's one group, clustered up the Y axis, who register and straight away add a large number of tracks to their profile manually (it's unlikely that they're listening to hundreds — or in one case 7,600 — on one day). It seems that some of them quickly lose interest and don't keep coming back. What these data cannot show is how many of people shown to the right of the diagram started out showing this behaviour and then became long-term users.
There's a smaller and less clearly defined group of users scattered along the X axis. The data are again very limited because they don't tell us whether someone who's got 800 tracks on their profile, accumulated over 100 days, added these tracks in 80 listening sessions or 8 (or possibly only two). But it seems fair to speculate that at least some of this second group are using Last.FM in quite a different way from the first: they are allowing their profile to develop organically by listening to tracks rather than adding them manually.
It might be useful to collect much more data and see if any clearer patterns emerge among the 50% of users who keep listening to Last.FM after 11 days. That would take more time than I've been able to give it so far.
So this amateur research doesn't tell us much that can be converted into confident projections of music listening habits and emerging markets. But it helps suggest and clarify what other data might be useful for these purposes.
On the quantitative side, it would be useful to analyse session data:
More useful still would be some more in-depth qualitative research, which might map onto the quantitative patterns, showing how Last.FM usage fits into the wider ecology of users' listening and buying habits.
The answers to these questions clearly affect the long-term viability of such services.
Service providers will be able to collect and analyse the extra quantitative data themselves. Answering the latter, qualitative questions will require interviews and ethnographic techniques to get under the skin of the emerging digital music listeners. In return it will mean that we don't have to rely on the speculations of scaremongering pundits about untested hypotheses-du-jour about why new technology A spells the end for format B or intermediary C.Posted by David Jennings in section(s) Future of Music, Ideas and Essays, Music and Multimedia, Radio, Social Software on 28 July 02004 | TrackBack