Akamai Diversity
Home > August 2012

August 2012 Archives

Fresh Fish & Fresh Data

Your customers act in real-time--your data should, too.

Like many New Englanders, we hit the Cape Cod beaches last weekend--more specifically, the delightful town of Chatham, home of Chatham Pier Fish Market. Famished from our adventures under the summer sun, we went looking for a late lunch and discovered fresh-off-the-boat tuna sushi and the best lobster roll I've ever tasted.

As we dined in the shade at the picnic table, it hit me: this remarkably fresh fish, bought directly from the source, tasted immensely better than any canned or frozen fish you might find at the supermarket.

Fresh is always better.


Call me geeky, but this mantra applies to your online marketing decisions as well. If your data is stale, your marketing may leave a weird taste in your consumers' mouths and your decisions won't be accurate.

As marketers, we are witnessing an explosion of data and technological platforms, including new ways to collect, store, process, manage, analyze, send, integrate and activate first- and third-party data. With this proliferation, it's easy to get lost in the sea of data questions.

The main question you should be asking is: are you using fresh, canned, or frozen data?

Take the latest CEB study, whose title bluntly states that marketers are flunking the Big Data test. On the other hand, those who pass the data test are more likely to have the "ability to ask strategic questions based on data, and...focus on higher-order goals."

So, when it comes to the data that powers your online marketing campaigns, here are a few strategic questions that warrant consideration:
1.    How fresh is your data? How often is it scored for accuracy?
2.    What are the most important and actionable audience segments?
3.    How can you link your segments to the right creative and messaging?
4.    Are you seeking and finding the right second- and third-party data opportunities?
5.    How will you measure the effectiveness of each data set?

The savvy digital marketer is not only answering the questions above, but also setting clear goals for the data opportunities he or she elects to pursue.

So when you look at the options, be sure that your data is as fresh as my sushi roll was this past weekend. In this era of real-time, programmatic media buying, if your data sources are canned or frozen, your performance will surely be lackluster.

Avi Spivack is Product Marketing Strategist for Akamai
Last week, I touched on Cloud Gaming and one approach, Thin Client Game Streaming. Today, I'd like to delve into Fat Client Game Streaming.

Fat Client Game Streaming is another popular method of game streaming that overcomes the challenges of reducing the time to play. Businesses like The Happy Cloud, Spoon, and BitRaider have been early implementers of this approach. This method takes an existing game and essentially creates a new version of the client that can be progressively delivered and installed. When you start to play a game, you don't need every library and component, only a small subset. Much of the software is typically not needed until you make decisions in the game that require additional libraries and components. This approach essentially creates a probability table of what component and libraries you need to start, and a tree of next likely resources. A new shell is created for the software to enable the game to start running with a subset of resources which are loaded based on the probability table.
This allows the gamer to start playing in just a few minutes.The probability table determines the typical starting point in the game for players, and downloads the rest of the library components in the background while the player begins play.

The advantage to this model is that start up times are typically just a few minutes to begin play. After a player authenticates and selects a game, they do not need to wait to download and install the entire game.

Another advantage to this model is that it still allows for offline game play after the initial install is complete while playing. The thin client model does not allow offline gameplay, since a server in the cloud is doing the computations and rendering.

The other major advantage to this model is it does not require the developer to create a separate version of the game. This method involves taking existing gaming code and running it through a set of tools to create the new package that can be streamed. This process can take the course of a few hours to a hundred hours per game.  

The Future of Cloud Gaming Is...Still Cloudy

One of the most popular topics I have been encountering in the online game industry, and among connected device businesses, is the concept of cloud gaming or streaming games to consoles, PCs, smart phones, tablets and smart TVs. I'm also often asked how I define cloud gaming, and whether a fat client or thin client approach is better. Cloud gaming is a very broad term being used to define multiple use cases. At a high level, most people define cloud gaming as running some portion of an online game in the cloud.

Delivering games to users on the plethora of devices on the market today has its challenges, including the fact that users often have to wait an unreasonable time to start playing a game. Game software typically contains libraries and components that need to be downloaded and installed before a user can start playing. So if a person wants to try a new game, they may still need to wait an hour or more to download and install it, before they can play. This is very different from the user experience with online movies or TV shows, where users can quickly and easily watch clips to determine if they want to watch, rent, or purchase a video. Videos can also be transcoded fairly easily for viewing on many different connected device environments. This process is not as easy with game software, since porting code is much more involved and costly, and may not even port to certain devices due to processing, GPU or memory constraints.  

Offering games available across multiple devices also requires creating different versions of a game for various devices. Today, consumers can buy a song or movie and play it across multiple devices, and they want to do the same thing with their games.

Thin Client Game Streaming or Cloud Gaming?
Using a thin client is one popular approach that helps overcome the challenges of "time-to-play" and game porting. Businesses like OnLive, GaiKai (recently acquired by Sony) and Big Fish have been early implementers.  Thin client leverages a light-weight installable client to act as a interface for the gamer, and graphics are pre-rendered on servers in the network and transformed into a video stream to the end device. The thin client sends user information back to the game servers in the cloud, which are rendering the game environment.

Let's Give Users What They Want - Instant-on Applications

I have spent a lot of time investigating and writing about User Experience, especially in the world of mobile banking.  The conclusion is simple: users now expect instant performance, both on their desktop, and on their mobile device.  So why not give users what they want?  Let's give them instant-on mobile banking applications.
When I say "mobile banking applications", I mean any native Smartphone application used in the world of financial services.  This could be banking, brokerage and trading, insurance, investment advice, or others.  And my advice here applies to more than financial services - it applies to other areas as well, such as social media apps, commerce, media and entertainment, and gaming. In reality, instant-on should be applied to any app that you may use on your Smartphone.

Let me define what I mean by instant-on.  An instant-on application is one that immediately launches and displays the start screen, without any request/response over the WiFi or carrier connection.  This means that the startup is completely in the code of the application and Smartphone.  It is instant, in that the startup occurs entirely on the Smartphone.  Instant-on apps can launch in as little as under 100 milliseconds, vs. up to many seconds for apps that communicate back to a server upon startup. As I like to say, "It's only software, it will do anything we tell it to do."  Well, then why do developers tell their apps to "call the mother ship" just to launch?

Of the dozens of mobile apps that I have examined, less than  5% are instant-on.  For those apps that do make a request back to a web server, it's amazing to see what is being requested.  Sometimes it's a small configuration file, sometimes it's a lengthy disclaimer document (which does not even show up in the start screen), and other times is a huge waterfall, with over a dozen hostnames and dozens of objects.  In many cases, it has nothing to do with what is required for the start screen.

But perhaps most interesting (or puzzling, depending on how you look at this topic) is that this concept isn't new. Noted web performance evangelist Steve Souders lists "make fewer HTTP requests" as his number 1 rule for faster loading web sites. If we're doing it (or should be doing it) for "wired" web pages and applications, why aren't we doing it for mobile?

How to Examine Native Apps:
The first step to understand instant-on applications is to investigate the request/response flow from the app.  You can do this easily on a web page using tools such as httpwatch, but for native apps, it's not that simple.  To "sniff" a native app, you need to setup a network sniffer on your PC, and proxy your Smartphone through that PC.  You can then watch the requests from the native app, and the responses from the server back to the app.  It sounds difficult, but it's really quite simple. And once you have it setup, it takes only a few seconds to sniff a native mobile app.

I have detailed document that provides step-by-step instructions on how to sniff native apps, which I would be glad to share with you.  You can request a copy by posting a comment to the blog, or email me directly.  Just ask for the document "Taking the Mystery Out of Native Applications".

Of course, once launched, a banking app will require communications to a server, and there are many techniques that can be used to make those screens fast.  I have seen the good, the bad, and the ugly there as well.  But let's at least start off by giving users what they want, and make banking apps instant-on.

16 Days, Another Billion Streams Served

There is no singular sporting event that captures the world's attention quite like the Olympics.  And... there is enough data to show that the 2012 Olympic Games attracted the largest aggregate online audience ever for a sporting competition.

Of course, with an event that spans more than two weeks with hundreds of competitions from athletes from all corners of the globe, it is no wonder that total online viewership would break records.

Add the fact that there are more devices and means for consuming sports and entertainment than ever before - with the tablet increasingly finding a spot as a second screen while watching TV - and we can all comfortably surmise that the London Games were experienced by more people than any preceding Olympics in history.

On Akamai's global platform alone, we delivered more than one billion aggregate video views (a milestone we believed possible before the games started).  We saw a staggering increase in mobile video traffic for an online event.  And when all was said and done after the Closing Ceremonies in London, Akamai had delivered almost double the amount of total traffic for a one-time event over a record we set two years ago.

As was highlighted in yesterday's post, research into national broadband plans published around the world highlighted the lack of a definitive resource for such information.  As a resource for others interested in similar information, I compiled the results of my research into the chart below, which includes broadband plan targets for key countries around the world, as well as the average and average peak connection speeds for those countries as published in the Q1 2012 State of the Internet report.

We recently published the Q1 2012 State of the Internet report.  Since it was the start of a new volume (our 5th!), as the editor of the report, I took the opportunity to update the definitions of the terms "high broadband" and "broadband" as they are used within the report.  From 2008-2011, "high broadband" was defined as connections to Akamai at speeds of 5 Mbps or greater; starting in 2012, we are defining it as connections to Akamai at speeds of 10 Mbps or greater.  And from 2008-2011, "broadband" was defined as connections to Akamai at speeds of 2 Mbps or greater; starting in 2012, we are defining it as connections to Akamai at speeds of 4 Mbps or greater.  This update brings our definition of "broadband" into closer alignment with broadband plan speed targets in the United States, European Union, and China.

Ten years ago everyone evaluating DNS solutions was always concerned about performance. Broadband networks were getting faster, providers were serving more users, and web pages and applications increasingly stressed the DNS.  Viruses were a factor too as they could rapidly become the straw that broke the camel's back of a large ISP's DNS servers.  The last thing a provider needed was a bottleneck, so DNS resolution speed became more and more visible, and performance was everything.