Contribution to MMA Mobile Advertising Committees
DRAFT: FOR DISCUSSION
Considerations for In-Application Ad Format Standards for the Apple iPhone
Submitted by: Greystripe (edits from AdMob)
Key Point of Contact: Erica Chriss (Mike Mettler / Jason Spero)
Date: 29 July 2008 (August 5, 2008)
Title: -- DRAFT FOR DISCUSSION -- Considerations for In-Application Ad Format Standards for the Apple iPhone.
AdMob Comments on above.
Proposed Ad Formats 2
Click (Tap) Actions 4
Serving & Reporting 5
The Apple iPhone is an advanced mobile platform with a rapidly exploding user base that promises a wealth of marketing and advertising opportunities. In particular, Apple has revolutionized the market for downloadable content with the recent launch of the App Store. In the few weeks since launch, Apple has already delivered millions of applications, each of which could be considered a platform for marketing to end users.
Greystripe focuses on advertising within downloadable applications and submits this document for consideration in standardizing ad formats for the iPhone platform. These recommendations are based on our experience in working with application developers and in helping launch live applications on the App Store with live, monetized campaigns. While the iPhone is the primary target device, the same formats also apply to the iPod Touch and likely to other Apple devices in the future.
These standard proposals should address both in-application and web environments.
User experience is key to effective marketing and advertising. In particular, in-application advertisements should conform to the user experience native to the host application. Among the iPhone’s unique features is the option for applications to be presented in landscape or portrait orientations; while some applications support both orientations, others only support a single orientation. In-application and browser based ads should only be shown in orientations that are consistent with the host application. Ad servers should select from the following formats based on the supported orientations of the target host application.
Because the iPhone is not a storage-limited device (4 to 16GB), the following ad formats do not impose byte size constraints. The following formats also do not impose image encoding constraints; native image formats (JPG, GIF, PNG, TIFF) may be used as well as proprietary formats for richer, more interactive content.
The following ad formats are presented as interstitial ads, where each presentation is counted as an impression. Interstitial ads may be presented at any time within the application flow as deemed appropriate by the application developer, and multiple ads may be presented in succession. During interstitial ad display, application content should be paused; for example, when games present interstitials, game play should be paused until ad display is complete.
The full screen landscape ad format is 480 pixels wide by 320 pixels tall. These ads may be presented only in applications that support landscape orientation. Such ads should always be presented “upright”; if the device is flipped (including during ad presentation), the ad should also be flipped.
1.1.2Full Screen Portrait
The full screen portrait ad format is 320 pixels wide by 480 pixels tall. These ads may be presented only in applications that support portrait orientation and should always be presented upright.
1.1.3Full Screen Square
The square format is 320 by 320 pixels. This format is unique in that it can be presented in any application; as with other formats, these ads should always be presented upright.
Banner ad formats are presented alongside host application or web content. Banners should alwaysmay be presented either at the top or bottom of the anywhere on the screen and should be flush with the screen borderat the publisher or developer’s discretion, as long as the banners appear above the fold.; “s
Skyscraper” ads are not supported, as they would leave too little useable space for the host application content.
Applications may choose to insert a dividing area between the banner and application content, but this is application-specific and not considered part of the ad format. Banner ads are opaque (zero image transparency), such that the ad image does not blend with the application content. Unlike interstitial ads or traditional mobile web ads, banners within applications do not have natural user interactions which delineate impressions. On the mobile web, a banner impression is based on a page view; in contrast, applications do not generally have “pages” but rather provide interactive user experiences. For this reason, in-application banner impressions are counted based on time: banner ad locations should display each ad for 3015 seconds at minimum; after 3015 seconds, the current banner ad may be replaced with a new ad; the display of a banner ad counts as an impression. Publishers are free to display ads for longer than 15 seconds.
The banner portrait format is 320 pixels wide by 5248 pixels tall. This aspect ratio (6:1) is consistent with existing MMA banner formats size is consistent with Apple’s style guide for the Browser toolbar.
The height of 48 pixels represents 10% long edge of the iPhone screen..
The native iPhone List View is 48 pixel in height (edge to edge).
Apple is inconsistent with their use of the header height (Safari Web View 60 pixel vs. Native View 43 pixel ) – 48 pixel works well for both Web View and Native View. (see this illustrated in attached file)
The banner landscape format is 480 pixels wide by 4872 pixels tall. This aspect ratio (10:1) differs from existing MMA banner formats but provides a better user experience; preserves the aspect ratio of 320x48.using a traditional 6:1 aspect ratio would occupy a full 25% of the screen, leaving insufficient screen space for application content (since, unlike web pages, applications typically do not scroll content).
Click (Tap) Actions
At minimum, all ad formats should support basic user interactivity. While more interactive features may be provided via proprietary formats, the following are proposed for the base standard. Note that the iPhone does not allow non-native applications to run in the background; for example, a game cannot pause and launch the web browser and then arrange to be resumed once the browser is exited. Rather, most click actions require that the application exit. Because of this, the user should always be provided the option to confirm or cancel any action that requires application exit.
In web environments, users should not be required to confirm actions. The click to navigate is an understood and expected user experience.
For basic interactivity, tapping anywhere on an interstitial ad should display a pop-up menu using native iPhone look and feel. The menu should be displayed either in the center or at the bottom of the screen. Zero or more ad actions may be displayed, and each may have a custom label appropriate to the action. The last (bottom-most) menu option should be a clearly labelled option that allows the user to skip past the ad (in the US market, this should be labelled “Skip”).
Interstitial ads may optionally provide richer interactivity. In such case, tapping on the ad need not display a pop-up menu but may result in other ad changes (similar to online Flash ads). However, if a standard pop-up menu is not provided, then a portion of the visual ad should be clearly labelled that allows the user to tap to skip the ad. An example presentation that satisfies this requirement would be an ad that incorporates a clickable “Skip” button directly into the ad image.
Banners support only basic interactivity and a single action—tapping anywhere on the banner should invoke the action.
The iPhone provides standard mechanisms for launching various content, and these are all considered basic action types:
Web: launches the web browser
Call: initiates a phone call
Video: launches either the browser or the YouTube player to display video content
Audio: launches the browser to play audio content
Maps: launches Google Maps to display location-specific content, such as landmarks (store finder)
iTunes: launches the iTunes store
App Store: launches the App Store
Storyboard: transitions to a second interstitial ad (which itself may provide additional actions)
Serving & Reporting
Unlike mobile web content, applications may be used in disconnected environments (such as on an airplane). To support such use cases, ad units may be cached locally on the device and displayed even when network connectivity is not available. In such cases, impression counts should also be cached and reported at the earliest opportunity to the ad server.
Mobile Marketing Association Page of