There’s been a flurry of interest in rich media across the online advertising community in recent weeks. In fact, I’ve also been in close contact with some of the individuals at major portals, networks, and sites responsible for setting guidelines for the placement of rich media within their sites. But take a look, sometimes the web is a not-so-brave new world when it comes to rich media.
You can’t really blame the sites for their concern. We’ve all seen technologies foisted on us, claiming a revolutionary approach that will change the way we use the Internet. Frequently these approaches were “not quite ready for prime-time,” and that has made some sites gun-shy.
People in decision-making positions need to look at the problem from a clear vantage point. Techniques such as choosing an intelligent file loading order, keeping the code very tight, and where appropriate, using streaming media, can make big differences in the way these technologies work. Intelligent Java coding and server-side enhancements can go a long way toward speeding things up, too.
In rare cases, I’ve seen file size limits as low as 8k for banners. This seems a bit excessive. Even for a search engine, 12k is much more reasonable. There are two main reasons that sites impose file size limits: 1) user experience, and 2) impact on advertisement impressions being properly registered.
Most rich media companies are far more concerned with user experience than any individual site could imagine. For us, it’s everything. If users complain about us, then we might get the axe from the web sites. Every company uses its own methods to load more in less time, and mainly these invalidate the traditional method of applying file size limits to rich media. There isn’t a cookie-cutter model that we can all be fit into, but if the ad doesn’t load fast and wow the user, there’s not much point — for any of us.
The search engines have the biggest concerns over the effect of rich media on impression counting. If the ad loads more slowly than the content of the search page, the user may click on the first link before the ad impression registers. On most other kinds of sites, a low file size limit isn’t critical – a 15 or 20k traditional banner ad isn’t a big deal. But again, it’s not all driven by file size. There are many factors that go into the speed of loading an ad – rich media or not.
If the technology is streaming (truly streaming), then file size doesn’t matter at all. There should be no limit for true streaming media. I say true streaming media because in the past, some technologies have claimed to be streaming but use the term vaguely. I would define “truly” streaming media as media that pre-loads enough data so that the entire download process doesn’t overload a slow Internet connection. The efficacy of streaming media should be assessed on a per-technology basis.
For true streaming media technology there is no reason to apply file size limits. In theory, it just doesn’t matter. Certainly it would be ludicrous to apply a file size limit to a live radio broadcast or video broadcast. How could this be quantified?
Then there’s the issue of the expanding banner. We at BlueStreak.com have our E*Banner technology that allows us to expand any ad to any size. Narrative has its Enliven technology that has an expansion component as well. I’m sure we’ll see other companies come up with expansion methods over time. How do sites set file size limits for a banner that expands — basically loading more content based on time and user interaction?
Like I said earlier, a 15 or 20k download is no big deal for most sites, even though the trend seems to be moving toward highly conservative smaller file size requirements. By breaking that file into two parts (in the case of our E*Banner, a small Java Applet and a similarly sized graphic), the user experience is impacted less, since the page load will not be negatively impacted by a longer wait.
Once the page itself has loaded, the site should not have any issues with extra data being loaded to improve the ad experience. It just doesn’t impact their site in any way, and it improves “stickiness” while the user explores this expanded ad experience.
That deals with the initial file size issue, but what about the expanded space? How should these file size issues address the expanded space? You really need to think of these expanding ads as miniature web sites. Expanding the ad is the equivalent of going to a new page in a browser. In order to have a fair comparison, let’s look at the front pages of some of the major web sites.
If I go to the first page of Disney.go.com, I get an HTML file that is 46k and graphics that total 57.9k. Just for a simple (the entry page, no less) web page, we’re looking at over 100k. The first page of Infoseek.com is 36k just for the HTML and about 10k for the graphics. Lycos is slimmer at 19.4k for HTML and 7.7k for graphics. MSNBC is 24k for the HTML, but 48k of graphics. AOL.com’s welcome page is 50.5k for HTML, and 19.1k for graphics.
None of these sizes are unreasonable for the expanded space of an expanding banner. It’s mainly an issue of bang-for-the-buck. Are 5 extra kilobytes worth an extra 0.5 percent click-through? What about a 5 percent improvement in conversion? That’s up to the advertiser and site to come to terms with.
The expanded page is loaded at the specific request of the user. If the user doesn’t want to wait, then they are able to move somewhere else. All expanding technologies are not going to work exactly the same way since every technology has a slightly different purpose–some focus on transactions, some of branding, some on games. But whatever the focus, the user experience is the only issue; that should be addressed by utilizing appropriate solutions to varying needs.
Bottom line: Advertisers will continue to request rich media solutions, and web sites will continue to feel the pressure of dollars pulling in that direction. Traditional banner ad requirements do not and cannot address rich media technologies. The companies developing these solutions employ numerous techniques to break beyond the banner that (in many cases) mitigate the needs for the stringent requirements placed on traditional banners.