digitalmusic.org | Digital Music

For many startups analytics and reporting is a nice addition to their product suite, providing their own team with insight into user interaction with their product, and content creators with visibility in to how others are interacting with that content. But for music-focused startups tracking this has to be a fundamental consideration, with regular reporting being a requirement of the licensors. Here are some tips to help you get it right out of the gate.

Use standards & conventions

You’re not going to write your own OS, so what makes you think it’s OK to define your own field separator for a flat-file format? If you must use flat-files then use CSV, (not strictly a ‘standard’ but a very strong set of conventions.) For structured data use XML or JSON (preferably offer both.)

Use UTF-8. Use it everywhere so you aren’t munging non-latin characters in the metadata, and where applicable (i.e., XML) broadcast the fact that the encoding is UTF-8.

Use ISRC, ISWC, UPC/EAN and GRID where applicable. Consider using the DDEX ERN for content release notifications (if that’s the business you are in!) There are numerous other standards out there, so go look and use them, or at least be aware and inspired by them.

Store & report partner content identifiers

It’s best to use your own identifiers for content that you are managing, but store the licensor’s own content identifiers & include these in the reporting back to the licensor. This will make their lives much easier, making them more likely to be flexible elsewhere. It also allows you to speak their ‘language’ when there are operational issues.

Model sound recordings & rights correctly

A musical track generally consists of a sound recording that embeds a musical work. There are different licenses for each of these entities, (go ask your lawyer,) and you need to think of how you are going to model these in your database. In addition you need to model who you have licensed these from (and therefore who you’ll be reporting to and paying.) An ISRC is the commonly used identifier for a sound recording. The ISWC is sometimes available for a musical work, but unfortunately coverage is thin.

For each of the above there can (and likely will be) more than one interested party. For sound recording these include the label, the artist and the distributor. For the musical work these include the writers and the publishers. You will likely only need to provide reporting to one party (generally the distributor or label for sound recordings, and the publisher or publishing administrator for the musical work.) But these parties then need to turn around and report to the others in turn, so including things such as country of play in the reporting is absolutely essential.

If you are selling or streaming albums then keep in mind the fact that an individual track will often appear on multiple albums, and the licensor may be different depending on the album that the track was played or purchased on. Also be mindful that sound recordings are often licensed by different entities in different territories, so you will have one track that you need to pay party X for when played in Canada, and party Y for when played in the US. The same can be true for the underlying work.

Design with scaling in mind 

If you have any level of success then you will be seeing a lot of transactions. Youtube reports over 4bn views a day, and my estimates put SoundExchange listens at around 30bn a quarter*. Each listen needs to be reported to the correct parties – a sound recording licensor and a publisher. (If you are a non-interactive service then just to SoundExchange.)

Run your entire reporting and analytics product in the cloud so you can scale quickly without having to worry about hardware, power, rack space etc. Bake in good devops practices early, with automated builds and monitoring through your entire stack. Consider NoSQL solutions as core to your reporting technology mix.

Expose all of your transactions to your partners via web service. This will greatly decrease your operational overhead and keep your external interfaces simple and clear. When a partner insists on receiving data in flat files then just schedule a process to request them from the web service and send them to the partner. Eventually they will see the light and you can migrate them on to your web service infrastructure.

That said … 

Don’t over-engineer. This is the fastest evolving piece of an ever evolving industry. Things will change, whether because of the regulatory environment, new business models or the creative destruction of what was once the big four. Things will change, and you can take those opportunities to refactor.

Those are just some quick thoughts, and just the tip of the iceberg. Join us at the San Francisco Music Startup Academy if you’d like to discuss these topics with me and other industry veterans.

* $88m paid out in Q3 2011, at $0.029 per listener hour = approx. 3bn listener hours. 10 songs per hour = 30bn listens.

Written by Gregor Dodson, Dir., Product Management at IODA. Gregor is co-presenter of the ‘Getting Under The Hood: Music Operations For CTOs and Developers’ session at digitalmusic.org’s Music Startup Academy event set to take place in San Francisco on February 14. For more information, visit http://sf-musicstartupacademy.eventbrite.com/