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+

Use the Search Analytics report to compare which app content you consider most important with the content that actually shows up in search and gets the most clicks. If they match, you’re on the right track! Your users are finding and liking what you want them to see. If there’s little overlap, you may need to restructure your navigation, or make the most important content easier to find. Also worth checking in this case: have you provided deep links to all the app content you want your users to find?

Make sure Google understands your app content

If we encounter errors while indexing your app content, we won’t be able to show deep links for those app pages in search results. The Crawl Errors report will show you the type and number of errors we’ve detected.

See your app content the way Google sees it

We’ve created an alpha version of the Fetch as Google tool for apps to help you check if an app URI works and see how Google renders it. It can also be useful for comparing the app content with the webpage content to debug errors such as content mismatch. In many cases, the mismatch errors are caused by blocked resources within the app or by pop-ups asking users to sign in or register. Now you can see and resolve these issues.
To get started on optimizing and troubleshooting your own app, add it to Search Console now. If you want to know more about App Indexing, read about it on our Developer Site. And, as always, you’re welcome to drop by the help forum with more questions.

2. Understand how your app is doing in search results

How are users engaging with your app from search results? We’ve introduced two new ways for you to track performance for your app deep links:

  • We now send a weekly clicks and impressions update to the Message center in your Webmaster Tools account.
  • You can now track how much traffic app deep links drive to your app using referrer information - specifically, the referrer extra in the ACTION_VIEW intent. We're working to integrate this information with Google Analytics for even easier access. Learn how to track referrer information on our Developer site.

3. Make sure key app resources can be crawled

Blocked resources are one of the top reasons for the “content mismatch” errors you see in Webmaster Tools’ Crawl Errors report. We need access to all the resources necessary to render your app page. This allows us to assess whether your associated web page has the same content as your app page.

To help you find and fix these issues, we now show you the specific resources we can’t access that are critical for rendering your app page. If you see a content mismatch error for your app, look out for the list of blocked resources in “Step 5” of the details dialog:

4. Watch out for Android App errors

To help you identify errors when indexing your app, we’ll send you messages for all app errors we detect, and will also display most of them in the “Android apps” tab of the Crawl errors report.

In addition to the currently available “Content mismatch” and “Intent URI not supported” error alerts, we’re introducing three new error types:

  • APK not found: we can’t find the package corresponding to the app.
  • No first-click free: the link to your app does not lead directly to the content, but requires login to access.
  • Back button violation: after following the link to your app, the back button did not return to search results.

In our experience, the majority of errors are usually caused by a general setting in your app (e.g. a blocked resource, or a region picker that pops up when the user tries to open the app from search). Taking care of that generally resolves it for all involved URIs.

Good luck in the pursuit of appiness! As always, if you have questions, feel free to drop by our Webmaster help forum.

Share on Twitter Share on Facebook

Share on Twitter Share on Facebook

Hundreds of apps have already implemented app indexing. This week at Google I/O, we’re announcing a set of new features that will make it even easier to set up deep links in your app, connect your site to your app, and keep track of performance and potential errors.

Getting started is easy

We’ve greatly simplified the process to get your app deep links indexed. If your app supports HTTP deep linking schemes, here’s what you need to do:

  1. Add deep link support to your app
  2. Connect your site and your app
  3. There is no step 3 (:

As we index your URLs, we’ll discover and index the app / site connections and may begin to surface app deep links in search results.

We can discover and index your app deep links on our own, but we recommend you publish the deep links. This is also the case if your app only supports a custom deep link scheme. You can publish them in one of the following ways:

There’s one more thing: we’ve added a new feature in Webmaster Tools to help you debug any issues that might arise during app indexing. It will show you what type of errors we’ve detected for the app page-web page pairs, together with example app URIs so you can debug:



We’ll also give you detailed instructions on how to debug each issue, including a QR code for the app deep links, so you can easily open them on your phone or tablet. We’ll send you Webmaster Tools error notifications as well, so you can keep up to date.



Give app indexing a spin, and as always, if you need more help ask questions on the Webmaster help forum.

Share on Twitter Share on Facebook

If you’re interested in participating in App Indexing, and your content and implementation are ready, please let us know by filling out this form. As always, you can ask questions on the mobile section of our webmaster forum.

Finally, if you’re headed to Google I/O in June, be sure to check out the session on the “Future of Apps and Search”, where we’ll share some more updates on App Indexing.

Share on Twitter Share on Facebook