Responsive web design is arguably the hottest topic in web design today, but how do you monetise responsive sites? Matthew Snyder and Etai Koren, co-founders of ResponsiveAds, present the biggest issues and come up with some solutions
With the explosive growth of smartphone devices and tablets, 2010 opened up a new decade and rebirth in thinking about multi-screen design, the web (HTML5/CSS3) and native mobile applications (the app). In the mobile world, the app became king and monetising it seemed to be a major new focus for brands, agencies and publishers as they embraced this new rich medium for creating compelling and innovative user design experiences.
A flurry of rich media mobile advertising platforms started to emerge, but quietly in the deep circles of the web design community the next big movement around a common architecture for a multi-screen viewable website based on the adaptive screen/fluid grid approach, called Responsive Web Design (RWD), took the community by storm.
By the end of 2011, according to Google Trends, search queries of RWD overtook searches for Mobile Web Design and Mobile Applications Design. By April 2012, RWD was over 2.5x greater and the trajectory by 2013 shows that RWD could be as much as 10x the other mediums. This astounding trend has begun to tell a unique story about the convergence of media and the power of the web vs silo’d mobile sites and apps.
However, the best method of monetising RWD sites via advertising is a new puzzle that needs to be addressed. Given that media buying strategies have been so specific in dedicated channels in the past, pulling all of the channels together in a fluid form has become a new disruption that both the publisher and advertiser have to truly embrace as part of the RWD movement.
In this article, we will share some of the issues and solutions related to the publisher perspective related to the challenges and opportunities to growth of this industry (part two will look specifically at the agency, brand and advertiser).Key issues with responsive advertising
The duality of the problem (both the publisher and advertiser)
One of the key critical issues around advertising on RWD sites is that it is not just a topic that needs to get resolved by the publisher alone. The advertiser needs to be aligned to this strategy or have a cross-screen mobile strategy in place. This is what makes responsive advertising so complex.
In some ways it resembles the “chicken or egg” situation. If a publisher puts a desktop ad (300x250) on a mobile view via the floating grid, even when a user clicks on the ad they will get a desktop landing page and potentially not a mobile one.
Despite the fact that the value of a mobile impression is different from a desktop one, how do you align both the buy-side and the sell-side simultaneously?
Mixing together the different standards, the value of the ad units are different
The industry Association, IAB (Interactive Advertising Bureau), covers the entire interactive channel advertising standard portfolio such as desktop, video and rich media, and mobile. In unison, the MMA (Mobile Marketing Association) is addressing the wide range and variety of mobile device advertising standards (from smartphones to feature phones, web, apps and rich media).
However, both associations have been only looking at advertising for dedicated channel delivery and fixed ad unit foot print sizes. Although there have been quite a few new ad units introduced in the last 12 months such as the IAB “Rising Star” formats, generally speaking there has not yet been the deep thinking on what happens when these channels merge.
How can one ad unit represent two different value propositions, sizes, shapes and even technologies (Flash vs HTML5)?
Outbound links must also work (the landing page responsive strategy)
When a website is designed “responsively” there is the critical issue of each view (desktop, tablet, smartphone, feature phone) being designed for that specific usage case and context.
As long as the content is rendered for each view, the UI/UX can be best aligned for each view. However, if there is an outbound link embedded in the content or a widget going off site, the context of that experience has now shifted to the design of that link landing page being desktop, mobile or tablet. Users can be experiencing the perfect smartphone view of a website and then click on a link to be taken to a site that has been designed for a desktop experience.
In a perfect world where everybody has content adaptive to a RWD approach or a 1-to-1 parity link matching strategy for their mobile site design, users can be taken to experiences that are optimised. This is a clearly the direction the industry is going, but we are still far away from the interconnection of media working smoothly from screen to screen.
Social media links from Twitter, Facebook and all of the other platforms have been clearly driving both in-bound marketing with out-bound link traffic thus making it imperative to publishers and advertisers to wake up to the context of link compatibility.
This process, defined by SMO (Social Media Optimisation) and SEO (Search Engine Optimisation) is not a silo’d design approach but must also incorporate clickable links cross-media.
Fortunately today, smartphones have full HTML browsers that can render those pages even through the user needs to squeeze, and zoom the content to view it.
Users have somewhat accepted this as part of the overall experience of a smartphone today, knowing that the browser can render full-fledged desktop designed websites. In theory, this is somewhat acceptable, unless the page contains elements like Flash in the design that is not supported at all, thus causing users to bounce off page pretty rapidly.
If there is a sign-up or purchase process on the page, the marketer can forget about this lead-gen process: the drop off rate could be a majority of that inbound traffic. As a lot of the desktop advertising industry has embraced Flash, a complete reversal of strategy is needed when we start to combine these mediums.
When the content is an ad that a user clicks on in the mobile context that has been shifted to a desktop experience without the landing page itself shifted to that experience, the brand or advertiser may be portrayed sub-optimal, giving the reverse effect of the conversion. The overall value of the campaign can be corrupted by a poor user experience on that outbound.
Not all campaigns are configured for automatic redirect to mobile-friendly landing pages and in many cases when media-buying occurs in blind ad networks (ad delivery target not know) the results can have a major negative affect for that marketer.
Moreover, as discussed above, the currency of an ad unit for a desktop experience is clearly different from the mobile or tablet impression.
Therefore, common sense tells us that shifting around ads in the fluid grid is clearly not the answer, but publishers are doing it as a stop gap solution today.
If an ad is sold for a particular media from the publisher to the advertiser, there needs to be an alignment between the publisher and advertiser and the context of where that impression is going to be made. Publishers that sell their own media are in a position to do this, but for publishers using ad networks to fill their inventory, this is impossible. If the ad is used in a different channel or view, the advertiser needs to be informed and align to that distribution strategy; thus making this complex.
Managing a single ad server for all the views is like saying “the separate mobile ad serving business is dead or only for apps”
Mobile dedicated solutions, networks and companies are not standing still. There is a lot of innovation in the mobile advertising front and in many ways mobile advertising is just beginning. The context of location, real-time placement, data, mobile relevant content and social media integration is just at the tip of the iceberg.
Publishers should be able to take advantage of the latest and greatest to best monetise mobile and not have to work with only a single ad serving solution. In many cases, large publishers have different teams for different channels. How do publishers mix and match ad servers and even ad networks to best suit their needs?
Rich media is not common for all platforms
Online advertising is still guided by heavily Flash ads whereas desktop and mobile are heavily weighted on HTML5 and mobile specific formats. This is changing very rapidly, but until this full conversion takes place, a mix and match of rich media is also especially needed.
This is also the case for video formats across many platforms. In the case of mobile, video may need to launch a separate player instead of playing video right in the ad unit itself, thus changing the video experience (besides the fact there is quite a bit of fragmentation in mobile between iOS, Android, Windows, and Blackberry).
Migrating one video format over to all of them in a web experience is quite difficult. That is why native apps also evolved to assure the best user experience for each different device for play-back video.
Many video ad networks and platforms have now extended mobile as part of the offer but to pull all of this into a mixed back of responsive advertising is definitely a challenge.
In order to address solutions to the responsive advertising problem you also need to look at the type of publisher involved.
There are mainly three types of publishers (besides all the aggregators and publisher networks) that leverage advertising as part of their business model. Each of these have a different approach to monetisation:
- Type A: Publishers sell their own inventory and have an ad server
- Type B: Publishers have an ad server, but use third-party network tags to fill inventory
- Type C: Publishers have no ad serving solution, but use third-party tags and ad networks for advertising in the site. These tend to be long-tail publishers or SMEs that can benefit greatly from a RWD site for SEO purposes and will embed a network like Google AdSense and/or Affiliate Network Ad types for desktop views
Case A: shifting ads around so that the same ads work on all views
As mentioned above, this seems to be what many publishers are doing today as a temporary solution even though we believe it really not the right solution.
Not only does it mix up the value of impressions the advertiser intended to buy potentially for a CPM (cost-per-thousand) currency, alignment on the outbound link may not be fully vetted with the advertiser. These problems are illustrated in the diagram below.
- For instance, in many RWD sites, the content gets pushed in mobile view below the fold, thus leaving the advertisement with different value of the impression in a new channel (mobile). Overall, the currency of an ad unit in mobile is clearly different from that on the desktop.
- If the advertiser has a mobile landing page, that should be aligned to the click-through process as well. When the ad is clicked, it should go to the right format and not to a desktop view.
When inventory is sold on a site or positioned on a site based on CPM- or impression-based sale, above the fold (in visible range on the page), where that impression is set is very important. When an ad placement is shifted around the site, the value of that placement needs to be qualified.
One solution for this is to sell ads on a CPC (cost-per-click) or a CPA (cost-per-action) basis. This way the impression sales cost does not matter, but the actual eCPMs (effective cost-per-thousand impressions) for the different views can be qualified to better establish one metric value: the value of your inventory across each screen.
This would solve the placement problem, but what about the problem of the landing pages? Google AdSense is an example of a good CPC solution, to have your ads aligned for different views, but you need to swap out the Google AdSense ad for ones that are contextually relevant for that view. This solution is geared toward publisher type B and C.
Another solution discussed in a recent article by Mark Boulton on Responsive Advertising was about selling all of the units as a complete package, as in the case of publisher type A. He states that it is not based on CPM per each ad unit but rather a kind of “sponsorship” for the spots across all of the channels and the aggregate CPM of all ads.
This may be a solution simplified for the publisher to look at all of the impressions cross-screen and the sum of the entire value of the campaign. This would solve the problem of the placement by establishing a price for the bundle, but again it potentially does not solve the problem of the landing page not optimised. The advertisers would need to be aligned with this sale and design strategy.
Case B: retrofitting your ad server
There is a way to approach the challenge of the disconnected context of the outbound page, by having the ad campaign also aligned, so that each channel is set up properly.
Many publishes are trying to use an ad server so that it only serves ads that were sold for the context of that view, but this is complicated and potentially challenging in the short term. Even though the creative and the footprint of the ad unit is the same based on the fixed size standards, the advertiser is going to need to recognise the different campaigns and pricing for the different views as well as conversion pages that are also designed for each of the different views. If the advertiser has a responsively designed landing page, this could solve that at least that problem.
Diagram IV shows a scenario where the fixed iframe of the ad units are shifted around, and each ad served is actually sold as a different ad (even though it is the same size), with each ad unit aligned for that specific channel (view) and associated landing page to go with that creative for each of the different views.
This would occur via a specialised targeting set-up and device detection. Each case would have its own pricing structure and set-up for delivering across all the different views. This is a complicated set-up, and could become an ad tag management nightmare for each page position when there is a change required. If it is done automatically by the ad server in the future this could definitely solve the problem.
Nevertheless, aligning different channels for each different ad is a solution that can possibly done with ad servers for type A, B publishers.
Rob Flaherty has posted an interesting article about how to use 24/7 Real Media’s Open AdStream (one of the major players in the first party ad serving space) in a responsive way. He proposes using jQuery to align the browser width for displaying the Open AdStream ad depending on the width.
This is a good solution for publishers that have access to the code coming from the ad server. Flaherty states that “there may be cases where the ad contents cannot be isolated from its deployment code”. Retrofitting your ad server can become a pain in the…. and will require technical knowledge as well as access to parts of the system you might not have access to. The only simple solution to retrofitting your ad server we believe is RAFT (Responsive Advertising Framework Technology), which is one of the patent-pending products of ResponsiveAds. We will discuss more about this Case E below.
Case D: publishers sourcing responsive ad unit (responsive stretch ads)
This is the case when a publisher sources ads that are completely made to be responsive. We refer to this ad type as Responsive Stretch and we will explain this approach a bit more in section Case E and a future follow-up to this article specifically geared toward the advertiser. Some good examples of Responsive Stretch ad designs are shown on CSS-Tricks' deals page. As you can see, they are basic ads but it is an example of a Responsive Stretch. We will have more about this subject in part two of this article.
Case E: a Flexible Responsive Ad Framework (eg Responsive Swap and Stretch ads)
In the same way that designers have approached RWD with different frameworks for development and laying out different designs for different views, another approach is to use a framework to manage ads direction and network party ad tags across the website.
This concept can give publishers the most freedom to set different positions for each different view and fill that inventory with flexibility for the right business model for those views. They can introduce advertisers that have created Responsive Stretch ads when they become available.
This method is actually good for all three publisher types (A, B, C). For instance, an online ad server for the desktop can be used for your own sold inventory or third-party network tags and then possibly a dedicated mobile ad server with mobile third-party network tags for the mobile views.
Mobile today is not just a smartphone view, but has several different feature phone formats as well. Mixing and matching different network tags for the desktop view and mobile ad networks for the mobile views can be established with this type of framework. This is what makes this opportunity so flexible. It can give the publisher the ability to pick and choose the best different platforms and monetisation vehicles for different views and have the right set-up and pricing for those different views.
When filling inventory by a framework there are two different types of configurations we found essential. We call them Responsive Swap and Responsive Stretch.
Responsive Swap is simply a different ad type “swapped” for each different view for a set-position on the site. This strategy takes the best from all the different channels and brings them together. In other words, with the rise of RWD and advertising, it is not the “death of the mobile ad networks” but an opportunity for them to combine more efficiently into a publisher's responsive web strategy.
For example, a leaderboard position for a publisher's site (as you can see in the diagram below), could have for each different view an optimum leaderboard size and design; the desktop could be 728x90, the tablet 468x60, the smartphone 300x50, and the feature phone 216x26. So there is no longer fixed size needed, but rather the concept of a leaderboard across sites.
Ad spots wouldn’t have to be shifted around the site, but can support fluid ad foot print sizes. The diagram shows different colours to represent each specific position sold a different creative, ad or third-party tags and which can be configured depending on the views. This way the publisher can have the different monetisation techniques that best suit each one of these views:
- It could be even Google AdSense ads across all the views, but for different views there is a different footprint for the sizes (Green, Purple, Blue, Red) - Publisher Type B, C
- A publisher might want to have a combination of Google AdSense ads across the site, but for the mobile views use a different ad network that pays more. (Blue and Red = Google AdSense, Purple and Green= Mobile ad networks (eg Millennium Media, Google/AdMob, InMobi, Jumptap, etc) or mobile ad optimisers (Smaato, Admarvel, etc) - Publisher Type B,C
- The publisher might have his own ad server, but have it configured only for desktop in the beginning because that is what they had been selling. They can gradually start to sell for mobile as they ramp up the process and set-up (Blue and Red = own sales, Purple and Green= Mobile ad networks) - Publisher Type A
Frameworks are powerful as they can give the publisher the ability to try many different configurations to best meet the needs of their target monetisation goals for their own case. They may want to keep their ad ops strategy and process the same for each channel until there is a catch-up, with the advertisers themselves having solutions for the different channels.
An example of a framework is our RAFT (Responsive Ad Framework Technology). RAFT gives publishers an easy framework to load different creatives or ad server tags based the fluid position they want it to appear on the page for each of the different views.
As RWD emerges so too will different frameworks to manage inventory and advertising across the different views. It is another approach to simplifying the ad serving experience.
This is a topic that has been quite active in the community about having ad creatives themselves stretch or adapt to any screen. This is critical to note that for Responsive Stretch ads there is a lot of complexity around the solution from three different perspectives:
- Business model
It is mainly a process for the agency and advertiser and we will approach this problem in part two of this article series.
The business model
For one ad to work across all screens there must be a methodology for managing or determining pricing for the ad for each different view if the model is CPM. This goes back to Case A, where existing ads were shifted around on the site.
Ad servers themselves have traditionally kept each creative and ad footprint as one ad type. To have the flexibility for an ad to have an adaptive-creative and footprint to change for each different view requires a completely different ad-serving approach.
Unless the landing page is also responsive or configured in a way to work for this morphing creative, then you're back to the same problem; having a different context for one view taking you to a landing page that is not optimised for that view.
The diagram below shows a concept of a Responsive Stretch ad for two different ad types. The first is a leaderboard that works across all screens. The leaderboard in this case is a 728x90 that changes to a 468x90 IAB configuration for tablets, to a 320x50/300x50 MMA configuration for smartphones and a 216x36 MMA configuration for a feature phone. The second type is a 300x250 rectangle IAB ad that changes to a 300x50 size so that it can stay above the fold and work on the feature and smart screens.
Nevertheless, for each of these Responsive Stretch ads, there is a responsive landing page associated with the ad. This is represented by the same colours red and yellow. In practice a publisher may want to just incorporate a Responsive Stretch creative, and just have one desktop landing page for the site as in the second diagram below. This is definitely not optimum (as discussed in Case A) for the advertiser and not recommended, but is possible to do with smartphones.
One can imagine how complex this is for the industry and the advertisers. They would not only need to create a dynamic HTML5 creative that would work on all screens, but have a landing page designed with RWD technics.
This clearly is the future of responsive advertising, but it might be a bit hard for brands and agencies to grasp immediately as there are a variety of different priorities on the table while the responsive site inventory ramps up and changes those priorities.
Type A publishers that manage their own ad server and ad sales are in a good position to work with their advertisers to deliver those assets needed to have a full-fledged responsive experience of Responsive Stretch ads for a responsive site.
Designing a Responsive Stretch ad has not really been defined by the industry. So it is “the wild west” for new innovative solutions using HTML5 and CSS3. It will require a lot of dedicated time with the agency or advertiser to get them up to speed in the process (thus cost).
Once standards are in place, this will make the education process much easier for the industry. Getting these solutions so that they are compatible with existing ad sever delivery configurations is not only a challenge, but getting the content to adapt so that for every possible view of the ad can still be approved by the brand and agency may be critical.
The production of a Responsive Stretch ad can quite complex and before jumping into the process, you need to understand the costs associated with the ad versus having different creatives used in a Responsive Swap scenario.
There is definitely an issue with matching this strategy to existing ad servers. Most ad servers were not designed to handle ad units that change size or configuration based on screen resolution or screen context; so an alternative retrofitting solution is required. Therefore, even with the Responsive Stretch, having a Responsive Ad Framework to manage this can work with existing ad servers for mobile, online, tablets or any other channel type.Conclusion
This article has presented different issues and some solutions for the advertising and monetisation opportunity, specifically for publishers that are embracing responsive sites. As responsive advertising is emerging there will be a variety of novel solutions introduced on both the publishing site and the advertiser side. We did not get too deep into the issues and solutions for the advertiser in this article and we are planning on doing a follow-up shortly.
Getting the basics of setting up ads that work for each different channel is definitely the first step in the process. Publishers should try to get the first step right by setting their basic goals and objectives, and then grow from there.
We believe using the mobile ad networks for the mobile views and the desktop ad networks for the online views with a framework is one of the best approaches for a website owner new to responsive web design. Once the publisher inventory is filled and there is money generated from the responsive property, there will be lot of exciting opportunities for cross-screen targeting, re-targeting and optimisation in the future to lift revenue. Therefore, it is critical in the first stage for the publisher to derive a strategy that includes both RWD and responsive advertising.
We have been approached by many publishers that want to move forward with a RWD site, but if they take that risk with responsive advertising, will they be able to sustain their existing revenue stream?
We believe it is critical for the publisher to understand that they need to understand that responsive advertising is only an extension to their existing desktop business model: a way to make further money from tablet and mobile views in combination with the existing desktop views, thus giving the net result of expanding their business.