Tag Archives: interstitials

Using Splash Pages to Avoid Unexpected Launch Interstitials

In this post, we’re going to discuss an easy way to help avoid violating our policy against interstitial ads that unexpectedly launch (Layout Encourages Accidental Clicks - Unexpected Launch Interstitials): implementing a splash page (Loading/Title Screen) in your app. A splash page is a static screen, containing no clickable content, which launches before the user gets to the ‘Home Screen’ of your app.

First, we’ll talk about the violation itself. If you choose to implement interstitial ads in your app, you need to ensure that your implementation won’t encourage users to click on it accidentally. An example of a violating implementation can be found below (Fig.1):

Fig.1: This interstitial ad implementation violates our policies, as an interstitial launches on the ‘Home Screen’ of the app without any action by the user.

In the example above, an interstitial ad launches while the user is idle on the ‘Home Screen’ of the app. This implementation is in violation of our policies, as interstitial ads should only be implemented at logical breaks in between your app's content . One potential way to fix this violation, without removing the interstitial ad altogether, would be to implement a splash page that launches as the first screen of the app, before the ‘Home Screen’. This page will show while the interstitial ad pre-loads. The Interstitial ad should then launch in the transition between the splash screen and the ‘Home Screen’. You can find an example of this correct implementation below (Fig.2):

Fig.2: This implementation does not violation policy. The first screen the user sees is a splash page, followed by an interstitial. Then, when the user closes the interstitial, they are shown the ‘Home Screen’ of the app.

Now that the user sees that content is loading, they won’t be encouraged to accidentally click on the interstitial ad once it launches. Then, when the user closes the ad, they are shown the ‘Home Screen’ of the app.

NOTE: When the user closes the interstitial ad, they must be shown a new screen. Interstitial ads are only to be implemented at logical breaks in between your app's content, so you can’t have the splash page still be there when the user closes the ad. That would be a policy violation.

To have the interstitial ad trigger at the right time, you may need to preload it. You can find more information about preloading interstitials here. As mentioned, as the developer of your app, the design of your splash page is up to you. The only requirement is that the screen doesn’t contain any elements that might encourage users to accidentally click on the interstitial ad once it launches.

It is important to note that, as a developer, it is your responsibility to ensure compliance with our policies. You can consult our Help Centre for even more helpful information regarding our policies and best practices.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Posted by: Tom Ambrose, AdMob Publisher Quality Team

Source: Inside AdMob


Google+: A case study on App Download Interstitials

Many mobile sites use promotional app interstitials to encourage users to download their native mobile apps. For some apps, native can provide richer user experiences, and use features of the device that are currently not easy to access on a browser. Because of this, many app owners believe that they should encourage users to install the native version of their online property or service. It’s not clear how aggressively to promote the apps, and a full page interstitial can interrupt the user from reaching their desired content.

On Google+ mobile web, we decided to take a closer look at our own use of interstitials. Internal user experience studies identified them as poor experiences, and Jennifer Gove gave a great talk at IO last year which highlights this user frustration.

Despite our intuition that we should remove the interstitial, we prefer to let data guide our decisions, so we set out to learn how the interstitial affected our users. Our analysis found that:
  • 9% of the visits to our interstitial page resulted in the ‘Get App’ button being pressed. (Note that some percentage of these users already have the app installed or may never follow through with the app store download.)
  • 69% of the visits abandoned our page. These users neither went to the app store nor continued to our mobile website.
While 9% sounds like a great CTR for any campaign, we were much more focused on the number of users who had abandoned our product due to the friction in their experience. With this data in hand, in July 2014, we decided to run an experiment and see how removing the interstitial would affect actual product usage. We added a Smart App Banner to continue promoting the native app in a less intrusive way, as recommended in the Avoid common mistakes section of our Mobile SEO Guide. The results were surprising:
  • 1-day active users on our mobile website increased by 17%.
  • G+ iOS native app installs were mostly unaffected (-2%). (We’re not reporting install numbers from Android devices since most come with Google+ installed.)
Based on these results, we decided to permanently retire the interstitial. We believe that the increase in users on our product makes this a net positive change, and we are sharing this with the hope that you will reconsider the use of promotional interstitials. Let’s remove friction and make the mobile web more useful and usable!

(Since this study, we launched a better mobile web experience that is currently without an app banner. The banner can still be seen on iOS 6 and below.)

Posted by David Morell, Software Engineer, Google+