How and why to use app indexing in your app
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 46 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47157 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
droidcon Berlin 201543 / 46
5
7
10
13
16
18
20
21
23
26
31
34
35
36
41
42
45
00:00
Android (robot)Software developerCross-platformBitMobile appData conversion
00:19
Android (robot)outputMobile appHypermediaData conversionBookmark (World Wide Web)SineWeb 2.0Content (media)
01:06
Mobile appContent (media)WebsiteMobile WebLink (knot theory)ResultantComputer animation
01:30
Web 2.0Cache (computing)AngleGoogolQuery languageLatent heatLink (knot theory)Mobile appSoftware developerWeb pageEntire functionTerm (mathematics)Software protection dongleImplementationMobile appSinc functionLink (knot theory)Web applicationWebsiteWeb pageUser profileHyperlinkCASE <Informatik>Search engine (computing)Content (media)Default (computer science)Meeting/Interview
02:26
Open setGoogolOrganic computingFreewareWeb pageRankingWebsiteMaxima and minimaMobile appLink (knot theory)Self-organizationSoftware developerWeb pageCASE <Informatik>Content (media)FreewareGoogolOrder (biology)ResultantSource code
03:15
Mobile appMobile WebResultantLink (knot theory)WebsiteDifferent (Kate Ryan album)LoginMereologyWeb pageRankingOpen setMeeting/Interview
04:09
Android (robot)GoogolGraphical user interfaceTouchscreenContext awarenessLink (knot theory)Order (biology)Mobile appAutomatic differentiationTap (transformer)outputComputer animation
04:57
Block (periodic table)Inclusion mapMobile appContent (media)Sampling (statistics)ResultantMatching (graph theory)ImplementationMaxima and minimaWeb 2.0View (database)Electronic mailing listWebsiteInformationGraphical user interfaceAndroid (robot)GoogolMeeting/Interview
05:44
Uniform resource locatorLink (knot theory)Mobile appMobile appLink (knot theory)Web 2.0Android (robot)Block (periodic table)WebsiteNumbering schemeComa BerenicesComputer animation
06:21
Data structureView (database)Group actionAbelian categoryDefault (computer science)GoogolContent (media)Electronic visual displayDegree (graph theory)Filter <Stochastik>Link (knot theory)Category of beingWeb browserMobile appDefault (computer science)Content (media)Matching (graph theory)Group actionOrder (biology)View (database)Type theoryFlow separationAndroid (robot)Message passingElement (mathematics)JSONXML
07:44
Mobile appLink (knot theory)Web browserContent (media)XMLComputer animation
08:27
Markup languageComputer configurationMobile appSheaf (mathematics)Level (video gaming)Link (knot theory)WebsiteContent (media)EmailTemplate (C++)FeedbackJSONXML
09:34
Markup languageLink (knot theory)Lecture/Conference
09:49
Android (robot)Software developerArtificial neural networkHydraulic jumpService (economics)Subject indexingMobile appGoogolLink (knot theory)WebsiteError messageSheaf (mathematics)Web crawlerProcess (computing)Markup languagePurchasingVideo game consoleHardware-in-the-loop simulationTrailAnalytic setSheaf (mathematics)Mobile appWebsiteTraffic reportingConnected spaceGoodness of fitSoftware developerService (economics)GoogolLink (knot theory)Video game consoleComputer animation
10:12
Mobile appWebsiteWeb 2.0InformationLecture/Conference
10:44
Client (computing)View (database)Web pageContent (media)Row (database)Object (grammar)Mobile appVideo gameComa BerenicesWeb crawlerClient (computing)GoogolRobotWeb pageView (database)Cycle (graph theory)Latent heatJSONXML
11:33
Block (periodic table)PasswordLatent heatPole (complex analysis)
12:43
Computer animation
13:43
RepetitionImplementationLink (knot theory)AdditionMobile appComputer animation
14:16
GoogolFreewareMereologyTouchscreenMobile appImplementationLink (knot theory)Web pageUser profileComputer configurationProfil (magazine)Arithmetic meanWeb browserWebsiteLecture/Conference
15:45
GoogolDampingAlpha (investment)Video game consoleMobile appLink (knot theory)Sound effectWeb 2.0Content (media)WebsiteProfil (magazine)User profileOrder (biology)
16:34
Mobile appResultantType theoryMobile WebVideo game consoleFeedbackWebsiteWeb pageLecture/Conference
17:30
Bit error rateRepetitionMenu (computing)Mobile appMultiplication signType theoryComputer animationLecture/Conference
Transcript: English(auto-generated)
00:06
Hi, everyone. My name is Shrimeng, and I work as an Android UI developer at Wire here in Berlin. Wire is the new cross-platform messenger app. Here you can see a little bit how it looks like, and our mission is to create a great place for your conversations. So
00:25
Wire is available on Android, of course, on iOS, and web, and besides text, calling a lot of rich media, you can also, and that's my personal favorite, draw nice pictures. I think it's a really nice app, so if you're not on Wire yet, check it out. But I'm here
00:47
today to talk about app indexing and how you can use it in your app. So what exactly is app indexing? This is what the official documentation says. App indexing is a really cool way for your app and app content to show up in Google Search with just a few steps.
01:08
And this is how app indexing looks in practice. For websites that support app indexing, the app icon will appear inside the search result, and when a user who has the app already
01:20
installed clicks on the link, they are not taking to the mobile website, but instead the app will open up with that specific content. And even if the user doesn't have the app installed, in some cases, they will be taken to the app download page, and after the download, the app will remember the original search and still open up with the app content.
01:43
So this is a mock-up of how we would implement app indexing for Wire. We're considering to get all user profiles indexed. So unfortunately we haven't been able to release it yet, as our web app just got recently launched. But basically the idea would be if you search
02:01
for a person, you could instantly connect with them inside the app. And as you know, websites use hyperlinks by default, and this makes websites easily discoverable for search engines. We're very used to Google showing us deep links to content. But that
02:22
doesn't work with apps, since apps don't use hyperlinks, and they're more or less silos of their own. So in order to make apps indexable as well, developers have to create those deep links with an URI for apps. And through those deep links, Google is then able to index your app content. Why is app indexing relevant? Well, it can give several
02:50
benefits to your app. First of all, it can provide a source of free and organic traffic which isn't too bad. And app indexing can also introduce your app to new users. So as
03:02
I mentioned earlier, in some cases, app results can be shown to users even if they haven't downloaded the app, and it can increase your install base. And earlier this year, Google also changed their page ranking to be more mobile-friendly. So as part of that, sites that support app indexing can get a positive boost in their page ranking.
03:24
And not only are app results with icons visually more prominent in the search results, a native app, of course, can provide a better user experience than a mobile website. For some apps, opening in the app or website might not make a big difference, but especially
03:43
for messenger apps like Wire, most of our users use the mobile app, and they're almost certainly logged into the app, but not necessarily to the website. So opening the search result in the app instead of the website would remove a lot of login issues. And if you
04:04
implement deep links to your app, you can also use them outside of Google search. So for example, you can use the deep links to open your app from another app. You can use them in paid ads for better targeting. And you can also use app deep links in order
04:21
for your app to appear in the upcoming Google Now on Tap. So Google Now on Tap will show also app content based on the context that the user has on the screen. App editing is not something new. It was already introduced in 2013, but back then
04:45
it was limited only to a handful of apps. Now there's a public API, and just recently it also became available for iOS. But there are a few requirements I would like to mention. So for Android, your app should support at minimum Jelly Bean or lower, and app results
05:03
are only visible to users who are signed in to their Google accounts, and they are only visible when those users are searching with Chrome for Android 4.1 or higher, or the Google app 2.8 or higher. So let's take a look at how to implement
05:21
app indexing. For that, I created a sample app called Boulder Finder with all border places in Berlin. It's very simple. The home screen has a list of all places, and if you select a place, it will open up the detail view with more information. And the same matching web content exists on Boulder Finder.de. So the same way a website
05:47
is identified by a URL, app deep links use also an app URI. For Google, the app URI should look like this. Android app followed by a package name, and then the scheme and
06:01
host path of your web resource. So for a particular Boulder Hall, the app deep link would look like this. Android app, com.boaterfinder, which is the package name, and then for example, HTTP, borderfinder.de slash place slash os block. And the first step is to make
06:24
your app support deep links. So in Android, this is done with intent filters. For Boulder Finder, I have a place activity to show the places, and so in the manifest, we add an intent filter to place activity. And the intent should use the action action
06:42
view for displaying content. And the intent has two categories. The browseable category enables your app to be open from a browser. The default category is optional. It's only required if you want your deep links to work outside of Google search, because when
07:00
your app is triggered outside of Google search through a deep link, the intent is implicit, and that's why you need the default category. And then the intent has a data element, which specifies the URI of the content. So you can do it, of course, in several ways, but here I'm using a path prefix to say the path should be something
07:24
like slash place. And in order for the deep link to work, we need to handle the incoming intent. So in onCreate of the activity, we can check the action type of the intent and retrieve the place ID and then show matching content. So that's basically all
07:47
that's needed to create deep links to your app. And they work everywhere, also outside of Google search. I can show it. So here in the browser is the app link. And
08:08
if you click on it, it will open the app to a specific place. And this will work everywhere. The second step is to pair up the app and the website content.
08:36
There are several options to do that. One is to add a link tag to the HTML header section
08:43
with the reference to the app deep link. This way has the advantage that if your website is using a template, you can add the deep link for many places at once. Another way is to use a sitemap. The downside of the sitemap is that if you have a lot of
09:01
content, it's very hard to list it for each and every place. But the good side with the sitemap is that in Webmaster Tools, you can quickly get feedback on how many app deep links were successfully detected. And you can also add the deep links via
09:42
the schema.org markup. But I didn't try it for Boulder Finder. And after setting up your app and website, you need to verify the connection in the Google Play developer console. So there's a section called services and APIs where you can do that.
10:05
And of course, it's important to measure the performance of your app deep links. So Webmaster Tools provides a very good search analytics report for your app. But you can also use the referrer information in the intent extra. The referrer extra is a UI which can be either app referrer or web referrer.
10:24
So if it's an app referrer, you know your app was opened by another app. If it's a website, web referrer, it was opened from a website which also includes Google search. So you can then match the Google host in the host path.
10:44
But if you use the referrer, it's very important not to track traffic coming from the Google bot. So the official documentation prohibits that. And you should not track it. It has a package ID of com.google.appcrawler. And this is optional, but you can also have
11:04
your app appear in the outer complete suggestions of the Google app. So for that, create a Google app indexing API in onCreate of the activity. Then you can record the start and end of the page views. The start method of the API
11:23
should not be called before the views are rendered. So usually this is done on start and on stop of the life cycle. And let's try it out. If I now Google for a specific
12:00
border poll. Let's say I'm not connected to the WiFi, I just realized.
12:51
So let's try again. Now with WiFi. Okay. So unfortunately I'm not able to show it. But
13:51
as you saw previously in the example, if you click on the link, it would open it up from search. So the technical implementation of app indexing is not very complicated.
14:08
But there are a few other things to consider. Often app indexing is a multi-team effort. And that's why it takes longer to implement. In addition to the technical part, app indexing also has a few UI requirements. So your app should support a deep link
14:24
that opens the home screen. After opening a deep link, the back button should take the user back to the previous screen. So if your user opens an app from Google search and they click back, they should be taken back directly to the Google search page in the mobile browser
14:43
without any intermediate app screens. And it also is required that your app follows the first click free principle. So you may know first click free for many news sites where you can read the first article that you find through Google. But if you want to read
15:01
further, you're required to log in. So the same applies to app indexing. You should first click free means that an indexed app page should be shown to the user without requiring them to log in or anything else. Even if the user has never opened the app before. So this is how we would implement first click free for wire. If the user is already
15:29
logged in, we would show the user profile that was open through Google search and with immediate options to connect to that person. If the user closes the profile, we would
15:42
continue to navigate elsewhere of the app to the search inside the app. And if the user is not logged in, they can still see the user profile. But they don't have the ability to connect to that person and trying to navigate away from the profile would prompt the user
16:00
to sign in or to register. So with wire and I think probably many other apps, the navigation wasn't initially designed with these requirements in mind. So if you want to use app indexing for your app, make sure to consider early enough the effects to the UI as well.
16:20
In my experience, getting Google to index app content takes much longer than with websites. For example, with border finder, the web content appeared within a day, but it took almost one and a half weeks for the app links to appear. So that's why it's really good to get to know webmaster tools well. About over a week ago, Google released a
16:41
dedicated search console for apps. Which is really awesome because before that, it was much harder to get feedback if something went wrong. And now it's even possible to ask Google to manually fetch your app pages, just like with websites. And last, be prepared
17:02
that the app results, how they appear in Google search can vary a lot. So I identified at least three different types, how the app results can appear. All three act the same if the user has the app already installed, but if they don't, only the first and the
17:24
second page, but the second one will always go to the mobile website. And there's not so much documentation on these different types and how you can influence the appearance. So all in all, reserve enough time for app indexing because it has UI requirements as well.
17:46
But the tools are improving very quickly and there are a lot of really exciting possibilities with this. So I hope this has perhaps raised your interest in app indexing. And if you have any questions, feel free to write or talk to me. Thank you.