Mobile Web Advertising - HTML5 Advertising - page 200

function activityHandler () {
var img = new Image ();
img.src = ' http://www.tracker.com/ping ' ;
}
</script>
</html>
You can see that an event listener has been added to the element of your choice and when tapped, we call
the activityHandler function. From within that function a new image object, img , is created and sourced to the
destination to be called. Now the browser will make a request to that source, and the receiving end will log an
interaction metric. (Just be sure to do this on the user's activity you wish to track; otherwise your reporting metrics will
be skewed.) Also, keep in mind that using this for mobile means another HTTP call, which could be skewed, based
on bandwidth constraints. If there isn't enough bandwidth, the request could fail to the third party, but the action will
still have taken place from within the creative.
Last, with mobile as in display advertising, the same “in/out” rule applies. If users are clicking or tapping to
engage with the ad in order to expand it, they'll more than likely need to click or tap to close the experience. This is
more or less set by publisher requirements, but keep this in mind in considering the overall user experience.
Optimization
Optimization is a crucial part of mobile development. Keeping a lightweight ad in the mobile ecosystem should be a
primary focus for any developer or designer, as it is extremely important for the varying network connections an end
user may face. As images and scripts are heavy over 3G connections, detect these constraints and offer users alternative
experiences. On Android devices 2.2 and higher, check the navigator.connection.type property; it allows detection of
WiFi from Ethernet, 2G, or 3G connections and adapts your ad accordingly. For Blackberry devices, check blackberry.
network to get similar information; on iOS ,unless the first-party ad server can provide it, wait until the API on network
information comes to that browser. See http://w3.org/TR/netinfo-api for more information on the network API.
In an ideal world, the best scenario would be to detect the current bandwidth of a user and provide alternative
information or graceful failovers. For example, if the user is not on WiFi or has a poor connection, offer a reduced
creative version with little to no imagery and dynamic content that relies on various HTTP requests. Connection
information will let ads really adapt to the user's device and viewing condition. Pair this with a responsive creative
design for the ad content, and you'll have an ad that can run on any screen in any condition—no problem! It's
essentially the holy grail of ad serving.
In addition, with mobile it's best to remove all heavy, unneeded external libraries ; use straight native JavaScript
whenever possible. Libraries provide great ease of use, but for this reason too many developers rely on them. Their
inclusion may not be warranted if the content is being targeted only to one operating system or device. A library
like jQuery gives amazingly consistent cross-browser experiences, but if you're using it just for its animation and
syntactical ease of use, you're killing end users with that extra weight. In fact, in one of its 2012 versions, jQuery sits
around 93 kilobytes minified and 34 kilobytes minified and gzipped. That's pretty large for a mobile user, especially
just for ad content. Always try to use naked JavaScript, minimize k-weight, reduce network downloads, and never
forget the normal methods you should be taking advantage of, such as minification of scripts and CSS files, as well as
gzipping your assets for the smallest transfer size.
Finally, try to keep your browser repaints very low. Repainting the layout of the DOM is a pretty expensive task for
mobile devices. As more animations and DOM manipulations occur, repaints could drastically decrease your user's
battery life.