Is App Indexing For Google Worth The Effort? A Case Study

What’s more, Google has given not one but two ranking boosts to websites that use app indexing and the app indexing API; so, implementing app indexing for your website is likely to increase your search traffic.

However, when we did it, it was a bust. We got a lot more app traffic from Google search when we implemented app indexing, but it was so little traffic compared to web search at that point that it was almost not worth the effort. Read on to learn more about what we did and what effect it had on our overall traffic.

What Is App Indexing?

If you’re not familiar with app indexing, it is basically the process by which your app appears in Google search results alongside relevant web results. By supporting HTTP URLs in your app and adding the App Indexing SDK, you allow Google to crawl and index your app as it would a web page, and you enable users to install or launch your app from search results when they search with relevant keywords.

If the app is already installed, you’ll see a button to launch it in the relevant search results:

If the searcher doesn’t have the app installed yet, they will see an “Install” button in search results:

Theoretically, this is great for users because they can find relevant authoritative content in Google regardless of whether they prefer websites or apps, and it’s great for app developers and marketers because it allows apps to be exposed to a whole new audience outside of the app store, potentially increasing app usage and downloads. But “theoretically” doesn’t necessarily mean that app indexing brings a lot of real traffic from search.

While I have seen a lot of great info on how and why to implement app indexing, I haven’t yet seen a case study on the benefits of app indexing in terms of traffic (though Google does highlight several other benefits). So, I looked at our app indexing traffic at Vivid Seats so that marketers, developers and webmasters can get a better sense of how much traffic, realistically, they can expect from getting their app indexed.

I want to start the case study with a small caveat: Vivid Seats is the largest independent ticket marketplace, and the number-three resale marketplace behind StubHub and Ticketmaster, according to Bloomberg. As such, we get a lot of web traffic. A website that doesn’t get as much web traffic as we do or an app that has no equivalent website will probably have different results than ours — especially if it’s in a different industry. That said, a lot of large websites might see similar results and might want to adjust their strategy accordingly.

This is also an Android-only case study, because we haven’t yet been given access to the iOS app-indexing beta in Google’s Search Console, and we don’t have the same kind of visibility into our iOS app’s indexing and ranking.

Background

Vivid Seats has had an Android app indexed since September of 2015. However, Google had a difficult time finding the equivalent app URI for our web pages at first, and in February of this year we had about 18 app URIs indexed and more than 35,000 pages with the “Intent URI not supported” error. We had had different URIs for our app than for our website at the time, which was making it difficult for Google to find equivalent pages.

Solution

Initially, we tried to add alternate tags to our web pages pointing to the equivalent app URIs, as instructed by Google’s help section on the subject.

For example, Adele’s Vivid Seats page — http://www.vividseats.com/concerts/adele-tickets.html — had the following rel=“alternate” tag, which was dynamically served to mobile user agents and which pointed to the equivalent app URI:

<link rel="alternate" href="android-app://com.vividseats.android/vividseats/performer/15313">

We were initially hopeful that this solution would be all that was necessary, because Google recommended it in its help section as a solution to this problem. Unfortunately, weeks after implementation, it was clear that Google was still having a difficult time figuring it out, and it didn’t index many more app URIs.

And the crawl errors persisted because Google was assuming that a lot of web pages on our website had equivalent app views, which at the time wasn’t the case.

We supported universal links in our iOS app and HTTP URLs in Android in April, which reduced the number of errors from 40,000 at its apex to about 85 today. As a result, we have seen the number of app URIs indexed go from 18 in February to about 35,000 today.

To do this, we simply followed the procedure outlined in the Firebase documentation:

• We made sure that each type of link on our website had an equivalent view and corresponding URI in our Android app. To do this, we designed templates for page types that were not included in our app previously, and we built them in our Android app. The unique information on each page is dynamically served from our RESTful endpoint, so it’s only necessary to design and code the templates, not individual pages.
• We verified our website in Search Console and associated it with our website, since our website isn’t in SSL, as required by Digital Asset Links.
• We added an intent filter in our Android manifest file.
• We called getIntent in the onCreate code and deployed the app to the Play store.

Results

Predictably, clicks and impressions grew exponentially from December, when 18 app URIs were indexed, to September, when 40,000 app URIs were indexed. Overall, clicks grew 919%, with clicks from non-brand queries (i.e. informational queries that don’t mention Vivid Seats, like “packers tickets”) growing 5,500%. The clickthrough rate (CTR) went down, predictably, as a result of the increase in impressions, specifically non-brand ones.

While app traffic (defined in Search Console as “clicks”) grew exponentially as a result of the increase in app URIs getting indexed, relative to the website traffic, app traffic has been underwhelming to date.

Even with an additional 40,000 app URIs indexed, 99.82% of our traffic from search currently goes to web pages, with just 0.23% of total search traffic going to our app URIs.

A few reasons why this might be so low:

• Android traffic is a lower percentage of our mobile traffic than iOS, which isn’t included in this study.
• We also have fewer app pages indexed than web pages — more than three times fewer, in fact. Because we grew traffic exponentially by having more app URIs indexed, there’s probably more traffic out there to be had that we will see when Google finally indexes all of our app URIs.
• But the biggest reason is that CTRs vary dramatically for app listings and web listings. Our brand term, which we usually rank in position 1 and for which we usually get around a 40% CTR on the web, has a CTR of less than 1% for the app equivalent. This suggests that, though the app buttons are prominent in Google for navigational terms, most people still prefer to click through to the website.

This last point could just be a matter of this being fairly new technology and searchers not fully understanding the new layout, and we could imagine this trend reversing sometime in the future. For now, however, it’s important that this point is understood by all who are looking to index their app pages in search results. It’s tempting to think that the presence of a large colorful button in search results will increase the CTR and traffic, but our research hasn’t found any evidence to support this.

In fact, we found just the opposite: The CTR to app content is less than half of what it is to web content, with our Android app pages getting a CTR of 1.55%, at an average position of 5.1, compared to our web content CTR of 4.67%, two positions below our app content, at 7.6.

Though app content in general has a lower CTR than web content, we found that navigational (or branded) search terms actually have a lower CTR for us than informational terms, which is the opposite of how it works for web content.

56% of the app traffic we received came from branded queries, compared to just 40% of our web traffic.

Looking deeper into query type, we broke down queries into two distinct types: first, navigational queries that mention our brand (for example, “vivid seats”) and informational queries that don’t (for example, “packer tickets”), and secondly, queries that indicate the searcher is looking for a website (for example, “www.vividseats.com”) or an app (for example, “download vivid seats app”) specifically.

If the searcher hadn’t indicated in their query that they were looking for an app or a website, we recorded that the query was branded or not, and that the website or app preference was “Not Specified.”

4% of total app traffic specified that they’re looking for an app, compared to less than 1% for web traffic. This is important traffic to be aware of, because it doesn’t have an equivalent on the desktop, and it could be a new query type to optimize for, but it’s not representative of app traffic. The great majority of queries for both web (99%) and app (96%) do not use qualifiers to describe whether the searchers are looking for an app or website specifically.

The traffic to app content from search has so far been underwhelming, but the real reason most developers would index their app content would be to drive downloads.

Fortunately, with Search Console, we can see installations from search as well. It’s kind of hidden in the Search Console reports; to see it, go to “Search analytics” → “Search appearance” → “Filter search appearance” → “Install app button.”

When we did that, we found that just 0.03% of our total search traffic led to an app installation from search in the last 90 days.

But when you take the total number of installations from the last 90 days and compare it to the installations we’ve gotten from search, it’s clear that about 2% of our total Android downloads came from users installing the downloads in search results. This isn’t terribly impressive, but when you consider that this represents many app installations from search that we may not have had otherwise, it justifies for us the little bit of work it took to implement it.

Summary

If your resources are limited and you’re wondering if app indexing would deliver enough traffic and installations to justify the effort, our experience would suggest you should focus on web content instead. Even after growing our traffic from app indexing by 919%, web content still brings in more than 99.8% of the total traffic from search to our website. If you’re considering other high-value projects, you might want to do those instead.

Still, if you only have an app to index, or if you have resources on your team, then app indexing does bring traffic that you wouldn’t get otherwise, and it might be worth the long-term benefits to your website and to Google users.

Have you implemented app indexing with similar (or dissimilar) results? I’d love to hear about it in the comments.

Many thanks to the UX design and development group at Vivid Seats, including Fawaad Ahmad, who made a lot of this happen.

Front page image credits: Introducing Firebase App Indexing