During the process of developing the specification for SafeFrame 1.0, many questions have been asked about the technology, implementation, and benefits of the solution. We have compiled a list of answers for the most common of these questions for you in the hopes that we can address most of your questions here and have time to address any additional questions you may have.
Q. Does SafeFrame support contextual display advertising?
A. Programmatically served ads can take advantage of features for passing meta data through the SafeFrame API. Publishers and ad technology partners and vendors should discuss the appropriate metadata needed to accommodate programmatic ad serving such as contextual display advertising.
Q. SafeFrame seems to be a solution for small business publishers, not one as big and complex as ours.
A. SafeFrame is already being implemented by large publishers such as Yahoo! and Microsoft, the two companies represented by the co-chairs in the SafeFrame Working Group. While full implementation and adoption will take time, the benefits of SafeFrame are being realized throughout the industry.
Q. How does SafeFrame benefit the buy-side?
A. SafeFrame benefits the buy-side in at least three ways. First, it enables advertising technology providers to standardize ad code, reducing operational costs and increasing cross-platform delivery as adoption increases. Second, it breaks the iframe "barrier," enabling data collection where none was available before and ad expansion. Third, it unleashes creative potential by allowing ad developers to focus on content rather than the technical barriers for ads served into iframes.
Q. We update our page in a live environment throughout the day. Will SafeFrame interfere with our ability to implement live updates?
A. No. SafeFrame doesn't interfere with live updates and may even offer an alternative to making such updates easier to manage. While SafeFrame was designed as a solution for improving iframe implementations, it also offers a viable option for moving inline ad content (or other content) to a SafeFrame "sandbox." While external content providers and technology vendors may have to make adjustments for serving their content into a SafeFrame instead of directly onto the page, SafeFrame offers a way to contain the content that won't be updated, simplifying access to core page content where updates are made.
Q. Implementing a SafeFrame on my site is no small task. How can we justify the expense?
A. Publishers' revenue potential is limited for inventory restricted to iframes. Using a SafeFrame, publishers can support valuable interactive media in SafeFrame's API-enabled iframe.
Among several other benefits that offer publisher page protection, transparency, and control, moving ads from being served inline to being served into a SafeFrame, publishers can also measure page load performance separately from ad load performance, which can't be done effectively for ads served within the page. Better load performance data means better analysis and the potential for improved performance and efficiency.
Q. Is a SafeFrame the same thing as an iframe?
A. No. SafeFrame uses an iframe, but implements it in a neutral secondary domain between publisher page content and a server that provides content, such as ads, from an external source. Unlike an iframe, SafeFrame also offers an API that allows external content to communicate with page content where the SafeFrame is rendered. This communication enables data collection and rich functionality such as ad expansion, all while providing a foundation for security, transparency, and control.
Q. Are SafeFrames the same thing as Friendly Iframes?
Q. Why should I implement SafeFrames instead of just using Cross Origin Resource Sharing (CORS)?
A. Cross Origin Resource Sharing (CORS) is a mechanism used to enable cross-origin HTTP requests. It manages whether content from one domain can make requests to another domain, which is useful for trusted rich media content that needs to request content from other domains. However, CORS cannot manage interactions between content in different domains and has no control over what cross-domain content can access. In contrast, SafeFrame uses an iframe and an API to enable rich interaction between the content on two different domains while allowing one domain (the host) to control access to its data by content on the other domain.
Q. How does SafeFrame support viewable impression data?
A. SafeFrame offers metrics for width and height of both the browser window and the SafeFrame boundaries, allowing for an in-view percentage metric. Duration can also be calculated for how long the SafeFrame is in-view at a select percentage value. These metrics apply when the ad is in a static state or in expanded mode, and can be used to determine viewability based on criteria set by involved parties. However, SafeFrame data does not report "viewability." Reporting databases that use SafeFrame data must report on viewability derived from metric data.
Q. Does SafeFrame incorporate the 3MS Viewability standard?
A. The Making Measurements Make Sense (3MS) initiative is currently in the process of developing, testing, and establishing a viewable impression standard. Even when a standard is established, it will take widespread adoption and long-term exposure to the industry before the standard is stable enough to incorporate into SafeFrame. However, SafeFrame does offer the data necessary to determine viewability based on mutual agreement between parties.
For example, SafeFrame offers metrics for in-view percentage and the ability to calculate duration. The viewable impression criteria for how much and how long the SafeFrame content must be in view is up to the parties involved and should take 3MS recommendations into consideration.
Q. If SafeFrame doesn't measure viewability, how will we sort out what's viewable and what's not?
A. Until a standard for viewability is developed and tested throughout the digital advertising marketplace, we encourage buyer and seller parties to negotiate on what constitutes a viewable impression. SafeFrame offers data that iframes can’t, such as identifying how much of the SafeFrame content is in view, but how much of that is required to count as “viewable” is dependent on the parties involved and how their reporting systems report the data.
Q. On the buy-side, do I have to use viewability data in SafeFrame if all I want is standard impression data?
A. No. Taking advantage of viewability features in SafeFrame, as with all features in SafeFrame, are optional for buy-side content providers. However, the publisher hosting the SafeFrame is required to provide available geometric data if requested.
Q. Does SafeFrame affect page load performance?
A. SafeFrame actually improves page load performance. SafeFrame is implemented on a secondary domain that's hosted by a content delivery network (CDN) designed for improved performance. Additionally, "sandboxing" external content in a secondary domain, as SafeFrame does, enables external content to load asynchronously to the page content, reducing the processing load. An added benefit of loading external content in a SafeFrame is that page load and external content load can be measured separately, establishing better data for page load analysis.
Q. Does SafeFrame limit my ability to collect data?
A. Ads served into a standard iframe have no access to any data on the hosted webpage. With this restriction, an ad may not be able to collect data beyond a simple impression. Serving the ad into a SafeFrame instead, enables not only data collection such as geometric data that can help determine viewability, but also enables rich interactions such as active click and rollover areas as well as ad expansion. Additional data can also be shared using metadata tags.
Q. How can I trust the integrity of data that's offered by the publisher instead of by direct access?
A. An ad served into a standard iframe has no access of any kind to publisher data, so when the ad is served instead into a SafeFrame, any data offered is insight that was unavailable in a standard iframe. The data that the publisher shares to an ad in SafeFrames is mostly geometric data that the publisher needs for proper execution of the served content while maintaining smooth page operation. The publisher has no incentive to provide false data, and in fact, must provide accurate data in order for things to work right. In addition, as with other data integrity issues, publishers can be audited to ensure they are capable of and responsible for providing accurate data.
Q. Can I still set and read cookie data from a SafeFrame?
A. Cookies can be set and read in the secondary domain where the SafeFrame operates, but SafeFrame also offers an option for setting and reading cookies in the publisher page. The SafeFrame host is given control over whether cookie-reading and writing is supported and if supported, the host decides on when and where cookie-reading and writing is allowed. On secure pages where sensitive user data may be stored in cookies, the publisher can and should deny this access.
Q. Does SafeFrame increase impression discrepancies?
A. SafeFrame doesn't report impressions. It does provide data that reporting systems can use to report impressions and other data, but how those systems use the data is what causes discrepancies. Also, with an incorrect implementation of SafeFrame or an incorrect reporting system interface, discrepancies are possible. Testing is vital for proper implementation and reporting.
Q. Is SafeFrame secure?
A. While SafeFrame opens a line of communication between content served into its API-enabled iframe, the publisher controls what is shared and generally only shares the geometric information used to display ad content and execute functions like ad expansion.
SafeFrame establishes a foundation for more secure and transparent transactions between ad content and page content, but as with any technology, measures should be taken to ensure the necessary level of security for your organization.
In models were interactive content is served directly on the publisher's page instead of into an iframe or a SafeFrame, security is an issue. SafeFrame offers an alternative for moving that content off the page and into its API-enabled iframe. Most rich, interactive content will maintain its functionality by using the API in a SafeFrame to communicate interaction needs while enabling a more secure framework for the publisher and transparency for both parties.
Q. How does SafeFrame affect consumer privacy?
A. SafeFrame enhances consumer privacy over content-serving models where interactive content is served directly into a webpage. In such models, the content can access any page data including any consumer details that display on the page. With SafeFrame, however, content served from external sources is isolated from the page as well as from any sensitive information contained on it. This isolation offers the publisher greater control over consumer privacy concerns for their sites.
Q. Does SafeFrame support the AdChoices program developed by the DAA?
A. SafeFrame supports the exchange of metadata and a foundation for supporting other industry initiative such as the AdChoices program. SafeFrame 1.0 excludes specific details for how to support specific initiatives, but the framework exists and specific recommendations will be considered for a future release.
Q. Who's responsible for implementing the SafeFrame?
A. The publisher implements the SafeFrame in most interactive advertising models, but a third party such as an ad server or verification vendor may also host the SafeFrame for a publisher page upon agreement from the publisher.
Q. Can a third party, such as a verification vendor, host the SafeFrame API?
A. Yes, but a publisher has to agree to allow another party to host the SafeFrame and requires a high level of trust between the two parties.
Q. Do buy-side developers need to modify ad code to work in a SafeFrame?
A. To work in a SafeFrame, ad code only needs modification if the ad content needs to communicate with the publisher page content, such as when expansion is needed. Most simple ads need no modification.
Q. What if I want to serve a placeholder that will accommodate an ad of unknown dimensions (such as with an ad exchange)?
A. Ads of unknown dimensions can be served to a SafeFrame, but the publisher must agree to support this scenario. In most cases, initial dimensions must be provided and when the ad is served and dimensions are known, the SafeFrame can be expanded to accommodate the served ad. The publisher may need to support the technology for "push" expansion for this operation to work correctly. Push expansion is technology that pushes page content to make room for an expanding ad.
Q. Does SafeFrame offer support for IAB Display Advertising Guidelines, the 2012 Portfolio (including the Display Rising Stars)?
A. The full potential for IAB SafeFrame 1.0 has yet to be fully realized, but all the “plumbing” has been provided to make rendering and tracking complex ad units such as the Display Rising Stars possible in a SafeFrame.
Q. Is "push" expansion supported in SafeFrame?
A. Push expansion is technology that pushes page content to make room for an expanding ad. SafeFrame supports communication for push expansion, but in version 1.0 supporting push expansion is optional for the publisher and the publisher must declare whether it supports the feature. Plans for a future version of SafeFrame anticipates more clarity around the support for push expansion and other technologies.
Q. Can I serve video into a SafeFrame?
A. Yes. SafeFrame is essentially an iframe with an API. Anything you can serve into an iframe can be served into a SafeFrame, including in-banner video. However, SafeFrame was not designed to support in-stream video, such as a linear video ad that is served within the video content of a video player.
Q. Is SafeFrame supported in the IAB Video Suite?
Q. Does SafeFrame work in mobile devices?
A. SafeFrame works in any major browser, including browser-based applications, whether on a desktop computer or on any mobile device. Non-browser (native) applications for mobile are not supported in SafeFrame 1.0, but may be supported in a future version.