|
Wednesday, April 30, 2003 |
|
So Apple's new music store sells songs for 99¢ per track. That sounds suspiciously like a micropayment (or at least a "minipayment") system to me. Lots of excellent insite into CC based payment systems deleted -- seriously, go read the article! [rentzsch.com: Tales from the Red Shed] I had been wondering the same thing since Apple launched the store-- how did the work out a reasonable mini/micropayment system. Having actually purchased a couple of items now, I have noted a significant delay-- upwards of 10 hours-- between purchase and arrival of the email "for your records" receipt. That delay may simply be due to the overwhelming purchase traffic through the store (let us all hope so!) or it may be because of some of the purchasing scenarios described in the aforementioned article. I have no idea. In the Fortune article it is mentioned that the record company takes an average of 65 cents per track sold. That leaves an average of 34 cents per track to cover expenses and make some money. Likely, a big expense is bandwidth and one of the best ways to eliminate rampant consumption of bandwidth is to limit the customer to one-download-per-purchased-item (as they currently do). However a 34 cent/song margin is large -- large enough to support a big chunk o' transaction charge being shipped off to the CC company. However, there is a another reasonable scenario under which Apple may be operating to support a micro/mini-payment based store. In particular, the credit card companies have long recognized that micro/mini-payments are a potentially huge market. Not only does the customer desire the convenience of being able to use a CC to make small goods/services purchases, but micropayments often lead to the customer decoupling the act of making a purcahse from the act of paying the bill. This has long been a powerful marketing ploy -- if you can successfully get the consumer to stop considering consuming your goods/services with paying a quantitative amount of money, there is less hesitation to consume. The credit card companies have been investing billions of dollars in building huge networks that can handle potentially 10s of billions+ transactions/day where every transaction must be cleared in a matter of seconds. (There was a really interesting article on all of this in a recent Forbes, but I can't find an URL.) Clearly, it would have been in Apple's best interests to have approached the credit card clearing companies with a proposal to work out a deal that would support the implementation of a micropayment based purchase/payment model. Any reduction in the extremely high transaction costs that are the tradition-- the very same costs that are designed to discourage people from making lots of small transactions-- would contribute greatly to Apple's profit margin on goods sold through the music store. Similarly, the launch of the Apple Music Store has the unique characteristics of making a really huge amount of media noise while being accessible only to a niche market [Macintosh owners with a US billing address]. At least initially. This provides an excellent opportunity for the companies involved to gauge the public's reaction without actually having to commit to a stupendously large potential market. If the reaction to the Mac specific store is good [and it seems to be], then the entrance into the much larger Windows (and others) markets can be done with the confidence that the micropayment model-- something that is very attractive, yet very scary, to the conservative consumer credit industry-- has been proven both from an implementation and a public-relations standpoint. I have no doubt that rolling out a Windows version of the Apple Music Store is rife with technical uncertainties that are way more difficult to deal with than on the Mac side, but that does not out weigh the potential business advantages to doing so. As well, choosing-- consciously or by circumstance-- not to address the insanely difficult/complex/political issues associated with distribution of music-by-wire into non-US markets has significant potential business advantages, as well. If the Apple Music Store is successful in its focused initial incarnation, it will provide a tremendous source of negotiating leverage when it comes time to open up new markets. Obviously, the Windows market in the US was already announced "before the end of the year" and is on the path to release. However, there are certainly still some legal & technical issues to be resolved. Will Apple continue to use their own DRM or will they integrate tightly with Microsoft's DRM APIs and policies? If they choose to go with the Microsoft based DRM, how much can they affect the provided rights prior to release? If the Mac/U.S. store is a rip-roaring success, said negotiations can be carried out with a result much more in Apple's favor. Likewise, solving the overseas distribution problem will be far easier if the interested parties-- media, religious, and political-- can see that profit is just a matter of implementation and not a question of whether or not anyone will buy the product. It will be very interesting to see how the Apple Music Store evolves. It is amazing that Apple was able to negotiate all of the different distribution rights and payment rights that must have been required for even the 200,000 songs that are in the store now. Of those albums for which only partial downloads are available or for which a number of songs can be bought only with the full album, I wonder how much of that decision was actually dictated by the rights/distribution deals that had been worked out? Slight digression: In particular, every unique performance of a song is an individual sound recording that may carry its own intellectual property characteristics that can be different than the other songs on the album. Every time a song is performed at a live show, that performance of that song is a new sound recording. Given guest musicians, union rules and venue, the set of property rights associated with a particular sound recording may be quite complex to resolve and achieving the rights to distribute might be prohibitively expensive. The ℗ symbol means "sound recording copyright" and implies that the particular performance of the particular song carries its own set of intellectual property rules that may be different than any other performance of that song. To further complicate matters, the song's lyrics and score may have different copyrights that affect the sound recording copyright. Playing live ain't all about jamming on stage with your closes friends-- if some random person hops on stage from the audience to play two notes on a harmonica and you suddenly might find yourself without the ability to actually sell a recording of that portion of the performance. (Yes, I did spend some time in the distribution end of the recording industry). Apple has certainly solved a bunch of problems that no other company had solved in a single package (a number of other products exist in this space-- and some have seen some success... it is way too early to tell how Apple's track record might compare). However, a lot has not been said. Historically, it will be interesting to see how the store contributes to the corporate balance sheet-- to see how successful the Music Store really is. Looking ahead, it will be fascinating to see how the success of the store is leveraged by Apple into more opportunities and used to open new markets.
Of course, Apple is not the first to make a foray into a digital delivery based media market. Nor will they be the last. How other companies leverage Apple's success-- be it fiscal or purely technical, in the end-- will make for some very interesting markets and business models in the coming years. |
|
``There are worse things in life than making a mockery of an online Boggle game.'' -- Josh Adler
And remember, kiddies: a CS education gives you power. |
|
Quite some time ago, Ben Holt and I wrote a useful little Python script that can parse the output of tcpflow (available in Fink as well as via just about every Linux package manager around) captured HTTP sessions and reconstitute them into actual requests and responses. We were motivated by the need to track down a handful of bugs related to Cookie handling in some WebObjects applications we were working on (turned out to be a bug in the Apache mod_cookie module, if I remember correctly) and the best way to do that is at the wire. Well, of course, if you have every captured every byte of a raw HTTP conversation, it is only slightly less painful than wading through the reams of raw data produced by simply capturing every bloody packet that goes across the pipe. Since most browsers are threaded, there was also the challenge of putting everything back into sequence. So, we gradually added some options to the script that would allow one to filter for particular headers, turn on/off dumping of the bodies, and output to indicate which request caused a particular response to be generated. In the end, this proved to be far easier to do than reconfiguring the machine to use some random logging/analysis proxy (which sucked at the time anyway) or otherwise disrupting our development environment. It is a total hack and completely dependent on the format of the output of tcpflow. It has proven to be extremely useful in many situations over the years. Recently, I wanted to capture the sequence of URLs passed from a web services client to a server.
So, this version of httpflow.py adds the '--terse' option which will cause httpflow to emit only the GET/POST/HEAD/<
Example captures of searching for "fried catfish" via Google (including loading www.google.com) follow.
Terse:
Default:
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/73 (KHTML, like Gecko) Safari/73
If-Modified-Since: Wed, 30 Apr 2003 04:44:52 GMT
Accept: */*
Accept-Language: en-us, ja;q=0.33, en;q=0.67
Cookie: PREF=***secret stuff deleted***
---- end header ----
--- begin header ---
From request: GET / HTTP/1.1
Source: 216.239.039.099 : 80 (-unknown-)
Destination: 192.168.001.070 : 55937 (-unknown-)
HTTP/1.1 304 Not Modified
Date: Wed, 30 Apr 2003 04:45:12 GMT
Content-Type: text/html
Server: GWS/2.0
Content-Length: 0
---- end header ----
--- begin header ---
Source: 192.168.001.070 : 55937 (-unknown-)
Destination: 216.239.039.099 : 80 (-unknown-)
GET /search?hl=en&ie=ISO-8859-1&q=fried+catfish&btnG=Google+Search HTTP/1.1
Host: www.google.com
Connection: keep-alive
Referer: http://www.google.com/
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/73 (KHTML, like Gecko) Safari/73
If-Modified-Since: Wed, 30 Apr 2003 04:44:59 GMT
Accept: */*
Accept-Language: en-us, ja;q=0.33, en;q=0.67
Cookie: PREF=
---- end header ----
--- begin header ---
From request: GET /search?hl=en&ie=ISO-8859-1&q=fried+catfish&btnG=Google+Search HTTP/1.1
Source: 216.239.039.099 : 80 (-unknown-)
Destination: 192.168.001.070 : 55937 (-unknown-)
HTTP/1.1 200 OK
Date: Wed, 30 Apr 2003 04:45:20 GMT
Cache-control: private
Content-Type:
Transfer-Encoding: chunked
Server: GWS/2.0
---- end header ----
Not pretty, but works well enough.... |
Last update: 1/5/04; 9:40:47 AM .
