ListenLog: Difference between revisions
No edit summary |
DrummondReed (talk | contribs) (→ListenLog Specifics: + link to ListenLog XDI page) |
||
Line 36: | Line 36: | ||
=== ListenLog Specifics === | === ListenLog Specifics === | ||
Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format. At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is a natural for consideration. | Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format (see the [[ListenLog XDI]] page for an example). At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is a natural for consideration. | ||
The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host). | The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host). | ||
A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits. | A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits. |
Revision as of 04:27, 27 February 2009
Background
ListenLog, or Listen Log is a form of Media Logging. It is required for PayChoice to work. PayChoice is a new business model for otherwise free media goods -- one that sharply reduces the frictions involved in paying for media. By increasing the number of people who pay for free media, PayChoice also helps stigmatize non-payment for those goods.
Logging of listening is required to answer all these common questions:
- What was that (program, segment, piece of music)?
- Who was that (host, guest)?
- Who produced that (program, segment, piece of music)?
- When and where did I listen to that?
- How often did I (listen to, watch or read) that in the past?
- Do I have a relationship with the source? (Such as membership, or past transactions.)
ListenLog is a simple utility that does nothing more than record listening data for the user. It will store it in a form that can be crunched in many ways and for many purposes -- all by the user's choice and at the user's discretion. It will be data that can go in any database or spreadsheet. It can also be shared in a selectively disclosed way. (See VRM Principles.) This will make possible a marketplace for third-party services that help both listeners and the institutions with which they relate. (Starting with stations, but also including program producers, artists and others.)
With ListenLog data, listeners can make fully informed choices about how they support streams, podcasts and on-demand sources of programming.
Listeners can also form better relationships with stations and program sources. Membership can come to mean far more than serving as a future target for pitches and billing.
Both Media Logging and PayChoice are brand new and still unproven. The former, and hopefully also the latter, are being pioneered with the Public Radio Tuner, which is currently being developed by [PRX] and other partners, including NPR and ProjectVRM at the [Berkman Center].
There are challenges posed both by the pioneering nature of the work and the limitations of the iPhone.
For example, the iPhone has a tiny memory for data and no persistent and user- (or program-) accessible data store on the host computer with which it syncs through iTunes. But iPhone does provide means for that data to be stored remotely, in a trusted "cloud." For this purpose, PRX has created ListenLog.org as a site/service for storing each user's data and making it available through standard web service interfaces.
Because this distances the user's data from the user's devices, and requires trust in PRX (or any host), questions of trust are naturally raised. These are the same issues raised by any cloud service, including Gmail and Amazon S3. Establishing trust mechanisms -- both technical and contractual -- are non-trivial. But they are also essential for laying the groundwork required for this new business model to work.
Overview
The VRM ListenLog is a proposed method for integrating simple user-driven functionality into an online audio player device or application. The ListenLog concept was devised in part for the Public Radio Tuner iPhone project, where it will likely be first introduced. The ListenLog is a consolidated and documented history of an individual's online listening activity. It is simply a recorded activity log, in a standard and open format, documenting an individual's listening actions through one (or more) online devices. The ListenLog is unique in that its aim is to give the user complete control over what to do with their listener activity data, including where the data lives, who to share it with, and how it can be used.
While tracking listener behavior data is not a new concept, the ListenLog is a novel approach to deploying early VRM functionality. While a simple activity log might not appear as the killer app, it succeeds by putting in place a small piece of user-driven infrastructure into a larger application - one with a promise of relatively wide distribution. Since this infrastructure component will write, store, and share listener activity in an open and standard format, we hope that such a log will become significantly more useful as other devices and tools leverage the standard to increase what an individual can do with their ListenLog data. This type of sideways approach holds the promise of planting the seeds of VRM onto lots of devices without requiring the primary application functionality (i.e. audio listening) be purely user-driven.
A user-driven activity log works well for an application that pulls together audio streams and files from a number of different sources. Of course, online audio providers (vendors in the VRM model) can already track and aggregate listening behavior data, but only for the audio they control. When the user acts as the sole point of integration, pulling together audio from multiple sources, their own consolidated log becomes uniquely powerful. Only when the listener is the point of integration does such an approach yield a new type of value.
ListenLog Specifics
Initially, the ListenLog will capture online audio stream and file listening behavior occurring through a specific application and device in a standard format (see the ListenLog XDI page for an example). At minimum, the log will capture audio stream/file identification, user agent, listen start time, listen duration and device location information. Extending this data to incorporate unique device IDs, audio meta data, rating (e.g. thumbs-up/down), referral, or other application behavior data is a natural for consideration.
The application supporting ListenLog recording capability will host the minimum of user-facing functionality. Specifically, the individual user will be able to choose a digital identity(s) with which to associate their listening data, and can also choose where the data is stored, as it will be dynamically written by the device application to any ListenLog standards compliant service provider (host).
A separate ListenLog Service interface, perhaps integrated with the ListenLog storage provider, will enable the user to choose if and how to share their ListenLog data, either anonymously or as associated with digital identities. For example, an individual may choose to share all data publicly and anonymously. All users selecting this option would, in aggregate, create a single, public "firehose" feed of all listening activity. It is our hope that third-party developers will offer user-driven functionality based on your ListenLog functionality, helping you share selected data conditionally with vendors for example, or providing agnostic recommendations based on your listening habits.