Google Changes Chrome to Prevent Abusive Deeplinking
Note: The article was updated below with a comment from Google.
As we noted yesterday, the latest version 40 of Chrome on Android no longer allows deeplinks to be triggered by the web page without direct user interaction. This was noted in the issue 459156 and confirmed by AppsFlyer.
We speculated whether it was a bug or an intentional change and after a few tips and more research we confirmed that this is not a short term bug, but a permanent change to the way Android browser handles intent URLs, which was finally confirmed earlier today in the comments for the issue. This for all intents and purposes breaks the most popular deeplinking solutions on Android, including App Links, DeepLink and URX.
How it all started
The issue got on Google’s radar over a year ago. A Chrome engineer was surprised to find that going to Pandora.com would automatically launch Pandora app if installed, instead of opening Pandora’s website. This behaviour was deemed broken and filed as a bug last year.
Pandora of course wasn’t hit by a random bug: they were intentionally detecting users who already had the app installed and were taking them straight to the app, assuming that’s what they wanted in the first place. But this did not sit well with Google and was slated to be fixed.
Unfortunately, this type of functionality is leaned on heavily by deeplinking companies to detect whether the app is present on a system. If found, user is deeplinked directly into the app, otherwise they’re sent to an appropriate mobile web page.
Does it need fixing?
User intent is paramount when it comes to browser behaviour. Having web pages that navigate away from the browser without user interaction makes for a crappy user experience. This behaviour can be abused in many ways and often surprises users even when not abused (as in the Pandora example above). Chrome engineers were very specific in their feedback around this, including another tracked issue where they said (emphasis ours):
From the omnibox, no, there is no plans to allow external redirects. If typing in the omnibox, the user is showing a strong intent to stay within chrome, so we made the decision to not allow external redirects (too many of them led to what we believed to be bad user experiences).
Clicking on a link should still behave as before and redirect to market:// links.
As it stands, how can I programmatically redirect a user to the play store?
There is no plans to support a redirect without a user gesture.
Apple had a similar problem in Safari just over a year ago: browsing random websites would inexplicably open the App Store page for Clash of Clans and a few other games. As TechCrunch’s Sarah Perez reported then:
For many weeks now, mobile users on both iOS and Android have been encountering a problem where visits to certain websites and apps have automatically redirected them to the platform’s app store to download various games. The issue involves errant ad networks, which should be blocking these shady ads, but aren’t. Meanwhile, mobile consumers simply trying to use an app or read an article are treated to a poor user experience.
Apple has since fixed the problem in Safari without neutering the budding deeplinking ecosystem that grew dependent on this feature, but Google has a harder job on its hands due to the more powerful nature of Android intent URLs.
What this means going forward
App Install Alerts are native Chrome banners, very similar to Apple’s Smart App Banners, that will act as intermediaries between the website and its native app. Unfortunately, this won’t help with the many marketing problems deeplinking companies have set out to solve.
To find out exactly how your deeplinking campaigns on Android will be affected check with your deeplinking partner. Tapstream customers are not affected by this, as we rely on deferred deeplinks to carry intent.
Update March 14: Google has gracefully responded to our first post – it sounds like there is an undocumented way to get around the current limitations, which deeplinking companies can use to route around this change (which will hopefully be a simple fix):
I will try and get some notes up about the fallback URL’s up as quickly as possible because it neatly solves a lot of issues for deep-app-linking, where as JS redirecting is a massive hack-around.