Practical Points in Content Monetization

Over the last three weeks I’ve been developing an application note on multi-screen video based on the open-source Java framework I launched three years ago.  One of the steps along the way was to send the note to operators for comment, and the results that I’ve gotten from that process have been very interesting.  What I think they do is to lay out the way operators today are looking at content monetization and the service layer.

The hottest issue in the service layer, based on the number of comments on the topic, was the issue of FEDERATION AND SERVICE EXCHANGES.  “Federation” is the term that’s most often used to describe formal asset-sharing agreements that are functionally supersets of traditional peering or interconnect.  I say “functionally supersets” because the main focus of Federation is the sharing of service logic components or other things not directly linked to connection.  The most common example is the sharing of caching/CDN assets in mobile services.  Operators believe that as they build higher on the “experience stack” of network services they’ll need to cooperate across provider boundaries there just as they do today at the lower layers.

Service exchanges are a little more complicated.  Some operators, and some other players in the market, are interested in creating what might be called “feature repositories” where operators go to access stuff they need for their services, most often when an operator’s customer has roamed in some way into another operator’s service geography.  The concept of an exchange is more flexible than that of formal bilateral federation because it involves an operator making what might be considered an “open offer” for cooperation that can be taken up as needed.  This might be a formal service or it might be simply a convenient publishing- or meeting-point for available offers, a kind of “registry”.

Another interesting point was the fact that operators do see the CDN as the foundation of content monetization even though the majority of them don’t see selling CDN services in competition with current CDN giants as their primary monetization track.  Most operators have run through the functional maps of a content layer, and have concluded that CDNs fill in a lot of the boxes.  I think this is interesting because the commercial CDN space isn’t exactly flying high, and there’s been some consolidation among startup CDN players over the last couple of years.  Played correctly, I think the comments indicate that the CDN is a hot property for a vendor.

CDNs are also perhaps the most critical test bed for “asset exposure”, or the abstracting of features into something that can be composed dynamically into services.  When you look at how a flexible service can be built for content delivery, you realize that some of the elements are common to other services, and so how CDN assets are made more generally available may be one of the first exercises of flexible asset management for operators.

I was also very interested in noting that while the operators did universally want to understand how to link network transport/connection behavior to content delivery and did want to manage service assets via OSS/BSS, neither of these two issues was a major focus for comments.  I think operators realize that you first have to produce a conception of a content service that will sell and be profitable, and then tune it to leverage current assets.  Neither network handling nor OSS/BSS integration are features of OTT video, so they are by definition not mandatory elements in the service.  They may be DIFFERENTIABLE elements, but you can differentiate your solution only if you have one to differentiate!


Leave a Reply