EmediateAd and responsive web design

Responsive design is a web design strategy where a web page adjusts its content to the screen size of the device it is viewed on. By doing this, developers only need to make one web page instead of having 2 or 3 versions of the same page (and maybe even some apps). This can potentially save time and costs. A challenge when shifting to a responsive web design is how to handle the ads on a webpage. Some ads may only be viewable on large screens while others only look good on small screens.

This paper will show you different ways of handling ads on a web page using responsive web design with EmediateAd and describes the pros and cons of each strategy. The two strategies involve either calling in Content units for specific screen sizes or to use targeting to determine screen size.

Strategy 1: The many content units way

One approach can be to call in various content units on the page based on the screen width of the visiting device. This will ensure that the best suitable ads will be shown on each visiting device. To make this work, some placements, such as the top banner, may need to be handled by more than one content unit. Which content unit to be called must be determined by a script on the web page before loading the page. Some devices, such as smartphones and tablets, can change view when tilted. If the device can handle larger ads when tilted, the content units containing these ads can also be called in the initial page load. By doing that, ads will look optimal on a device able to handle both portrait and landscape views.

This strategy can be used solely on mobile devices by using the information available in a browser’s user agent. So if a mobile OS is recognized, content units for screens with widths ranging between the width and height of the screen of the visiting device could be called. It will, however, disturb the forecast and impression count as content units and campaigns may be called but not shown. Alternatively, one content unit can be called per page load. Stretching and shrinking can then be used to ensure that e.g. top banners cover the entire width of the screen of the viewing device.

Figure 1. Example of content units to be shown based on screen width of the visiting device. The different colors represent different placements (blue = top banner).

Pros:

  • No additional Targeting needed
  • Easier to handle in EmediateAd
  • Easier to find competing campaigns in the same size
  • Most detailed reporting of the two strategies
  • Minimizes risk of booking campaigns with wrong dimensions on wrong content units (e.g. mobile campaigns on desktop version of site)

Cons:

  • Requires some on site logic to determine which content units to be loaded
  • The forecast on impressions may not be completely trustworthy if more content units are called for tilt-able devices
  • Site takeovers will be a challenge

Avoid pre-loading unused Content Units by using friendly iframes

For friendly iframes it is not necessary to pre-load ads for different orientations, as they can always be loaded asynchronously when the user is flipping the device. Using this approach it can be helpful to set up CUs with CU keys that contains the identifier of the “screen mode” / “profile”.

In the example below we assume that we have two sections for the “News” part of a site - “Landscape” and “Portrait”, used for different screen orientaion.

Section: name = MySite_News_Landscape
   CU: cuKey = MySite_News_Landscape_TopBanner
   CU: cuKey = MySite_News_Landscape_LeftBanner
Section: name = MySite_News_Portrait
   CU: cuKey = MySite_News_Portrait_TopBanner
   CU: cuKey = MySite_News_Portrait_LeftBanner

See demo here

<html>
<head>
<script type="text/javascript" src="//stage.emediate.eu/EAS_tag.1.0.js"></script>
<script type="text/javascript" src="//code.jquery.com/jquery-1.11.3.min.js"></script>
<script type="text/javascript">

/**
 * Detect the "profile" of the page, in the simplified example below, we assume
 * our page support two "modes" - "Landscape" and "Portrait"
 */
function detectPageProfile()
{
   var w = $(window).width();
   var h = $(window).height();
   if(w > h) {
      return "Landscape";
   } else {
      return "Portrait";
   }
};

/** This function will load ads in the <div> elements marked with the "data-cuKey"
 *  attribute. Inside that <div> there will be other divs containing the friendly
 *  iframes - as the page profile changes. (this will most of time be only one - or two
 *  for users flippling around with their devices)
 *  After the device orientation has changed, the HTML might look like this:
 * 
 *  <div data-cukey="LeftBanner">
 *     <div id="MySite_News_Portrait_LeftBanner" div-for-profile="Portrait" style="width: 200px; height: 400px; display: none;">...</div>
 *     <div id="MySite_News_Landscape_LeftBanner" div-for-profile="Landscape" style="width: 300px; height: 200px; display: block;">...</div>
 *  </div>
 *   
 *  The situation above will happen when the "Landscape" profile is the current one (visible),
 *  but "Portrait" (now invisible) has been used before. The reason for preserving the "Portrait" ad
 *  is that the user might be about to flip the device again, and we don't want to reload any ad.
 */
function reloadFifs()
{
   var profile = detectPageProfile();
   if(window.currentPageProfile == profile) {
      return; // nothing to do, we have loaded the ads and the screen orientation is the same
   }
   window.currentPageProfile = profile;
   $("div[data-cuKey]").each(function(){ // for every "data-cuKey" marked <div> we've created
      var found = false;
      $(this).find("div[div-for-profile]").each(function(){
         if($(this).attr("div-for-profile") == profile) {
            found = true; // We have already loaded an ad for this profile, so we should NOT load it again.
            $(this).show();
         } else {
            $(this).hide(); // Hide the ad as it is not for the current profile, but keep it for possible later use.
         }
      });
      if(found) {
         return; // We're reusing an ad that has already been loaded (user flips back to previous orientation)
      }
      // In this example we assume that the CUs are having cu-keys like "MySite_News_Landscape_TopBanner", "MySite_News_Portrait_TopBanner", etc
      var cuKey = "MySite_News_" + profile + "_" + $(this).attr("data-cuKey");
      $(this).append("<div id='" + cuKey + "' div-for-profile='" + profile + "'></div>");

      // Now, let's load the ad using the cu_key= parameter instead of cu=
      EAS_load_fif(cuKey, "/EAS_fif.html", "//stage.emediate.eu/eas?cre=mu;js=y;pageviewid=;target=_blank&cu_key=" + cuKey, 0, 0);
   });
}

$(document).ready(function() {
   reloadFifs();
   // Periodic checks for changes of orientation as 'deviceorientation' events, etc, are not supported by all browsers
   setInterval(reloadFifs, 500);
});
</script>
</head>

<body>
<h3> <- Change width of windows to switch between landscape/portrait CUs -> </h3>
"Top-banner":
<div data-cuKey="TopBanner"></div>

"Left-banner":
<div data-cuKey="LeftBanner"></div>

</body>
</html>

Strategy 2: Use targeting to distinguish site layouts

Another strategy is to keep the same content units on the web page, regardless of screen size, and use a targeting parameter such as categories or custom targeting to determine which campaigns that are qualified to be shown on the page on a device with a specific width.

A script on the web page side will be needed to determine the screen size of the visiting device/browser and inject a targeting value into the content units on the web page. If using custom targeting, the value can be the screen width by using a number range parameter. One can also use categories or custom targeting multiple choice lists and inject values for the different break points there will be on the responsive site. Those values can then be translated to e.g. “Mobile”, “Tablet portrait”, “Tablet Horizontal” and “Desktop” in the interface.

If you use this strategy, you must use “Any Dimension” on all campaigns that are booked on content units but don't match the original content unit size. “Any Dimension” will make use of a campaign's size when the campaign is selected, regardless of the size of the content unit it is delivered on.

Pros:

  • Simpler content unit structure
  • Less implementation work on the web page

Cons:

  • Requires targeting (keyword, category or custom) til deliver ads
  • Lesser detailed reporting than in strategy 1
  • Less accurate forecast as the numbers on a given screen size will be based on sample rates
  • Bigger risk of booking campaigns or creatives with incorrect targeting, leading to ads being shown in the wrong situations (e.g. mobile campaigns on desktop site)

What to remember when showing ads in a responsive design:

  • Mobile first – have campaign material for small screen devices
  • Have creatives in several sizes (e.g. 930×180, 728×90, 320×80)
  • Consider using shrinking/stretching of creatives if necessary (e.g. set width in image content unit tags to percentage instead of pixels and height to “auto”)
  • Book a total number of impressions/clicks rather than a specific number for each size
  • Have fallback images for devices incompatible with flash (e.g. iOS and OS X devices)
If you use composed javascript on your responsive web page, you should only include the content units in the init call that can be shown on the width of the pageload, as impressions will be counted on content units and found campaigns in the init call.
Cxense © 2012 | Support