In the rVibe service, there is a strong data and data-mining component, around the music, the people who are buying/using music and the intersection of people and music. Clearly, data around who is using/buying what/how/from whom has pretty major implications for a variety of things (marketing, recommendations, metrics, viral patterning, technology, privacy, customer experience, etc) and rVibe is not the only service where this is important; there are lots of companies attempting to leverage that for a variety of reasons (ie: Mog, Last.fm, Goombah and others). Data and data relationships also have implications for monetizing music downloads. However there are significant challenges in the many-to-many relationships inherent in the music service space, and in the consistently of data within each data type (music, aggregates (playlists, albums, tag lists) and people and their lists). And this becomes particularly complicated around the social-networking and music and commerce. What a system has to contend with is inconsistent data coming from many sources with multiple references to the data and multiple uses. For instance, what happens when someone browses my collection (data I generated), makes a recommendation to a third person for a track they have, that I also have (data they generated) that person then wants to purchase and download? And do that such that the person gets the right file, legally and the content owner gets remunerated (and in our case the referrer and I both receive rewards)? If you’re not careful and build in a robust data management process from the begining, the result is in a messy and inaccurate consumer experience. Hence why most companies shy away from a many to many model for music distribution and social networking from a commerce standpoint (rVibe model). It’s much easier to simply display available content with gold data and permit purchase and download (iTunes model). Last.fm or Goombah, as social networking based music services might eventually offer a way to purchase music from user generated data (not content), but they could only do so from a centralized source (ie: backend server environment) without significant development. They also would have difficulty with any content not from a major content provider (read: user generated content). And that’s just from a technical standpoint, let alone from branding standpoint. Snocap is working on acting as that central clearing house, but you still have data issues in the social networking standpoint and the need for a retail front end. In order to make it work, you have to build your data structures from the beginning with the intent of capturing the many-to-many relationships between people-to-music-to-people-to-music with commerce rules, built in to the content controls (and identification). It’s not just enough to track the relationships, you have to identify the business rules. You also have to have a degree of trust in the meta-data for the music you want to monetize. So - it’s one thing to say “Braydon is listening to Bleecker Street by Jonatha Brooke”, it’s another to say “Braydon is listening to Bleecker Street by Jonatha Brooke, click here to download it (from him and his friends).” And that captures one of multi-layered technical barriers to entry in creating a social-networking based music service (data, permissions, transport, performance, education). But we’re almost there, so I am pretty excited about it. And it’s great to be at the forefront of the shift from the store-front-model for sales to the network-model for sales.

Originally published on WordPress on January 11, 2007. Migrated to this blog on May 29, 2025.