Deeplinks, deferred deeplinks & app schemas
Deeplinks, deferred deeplinks & app schemas
You know it’s Groundhog day when Apple unveils something magical and new. So it was when we rediscovered “Web 2.0” for Apps as Apple announced deeplink support at WWDC. The fanboys responded with ‘wow, thats incredible’, others thought it was old news and some of us said ‘aha’ at the same time.
Suddenly it made sense that you would allow users to be able search inside your app and surface content – right on the phone – Apple launching another end-run around google search. You see Apple doesn’t need to be the best search engine, it just needs to be the first search engine and you know that Siri a key interface to it.
Deeplinked search is not just about accessing information on the web or calls to your own App’s server, it suddenly make sense that if I have a note taking app on my phone that it would be cool to search for that note – right on the phone.
Google has been doing App indexing for a short while and startups like Quixey have been building a business in this to surface organic content on your phone but also in organic searches via their partnership with browser vendors.
But the real value of deeplinking is what we take for granted on the web….The ability to click on a link and get direct to that deep content in your browser. If that link came via Facebook, email, SMS you know your browser will take you to the stuff that someone was sharing with you.
Not so on Apps.
It’s obvious in hindsight but unless your App developer was really “switched-on” your first release (and probably your current release) does not support the ability to jump to deep content in the app, (say a recipe, hotel or shiny pair of shoes) from an email.
In an App-first world this is dumb.
So there arose a number of App deeplinking “standards” that facilitated this capability.
Quixey, Facebook, Twitter all provided competing formats by which developers could choose to expose their App or content on those platforms. Another advertising player URX puts deeplinked Ads inside other Apps.
I expect that most of these competing standards will now collapse into whatever Apple says. This is great news and also educates developers and marketers about what they can and should be doing.
Now we can all sit back and relax that we’ve finally achieved Web 2.0 in the App world. phew!
Why was deeplinking a barrier?
Back in the Web 2.0 days, you could publish a link and know the user will arrive at a browser and view the content. If you had an App then with the use of MIME types the browser would the target App. This doesn’t work on Mobile because on the web http://facebook.com/path/to/1234 needs to be translated something like fb://1234 on iOS or Android.
Again, its worth reading the schema section below to help understand but what App deeplinks companies do is this:
Deferred Deeplinks and viral onboarding
What excites us is actually “deferred deeplinks”. Whilst we expect that every App should support whatever deeplink convention your developers choose…
The key issue is NOT the users you have…but the users you want.
You see, deeplinking doesn’t solve the problem for customers that don’t have your App.
As I’ve discussed in previous posts, that if 77% users churn away from your App by Day 3, then it could be the first-time user experience (FTUX).
So, here is the flow for deferred deeplinking using StreetHawk, your App or your marketing team can automatically create a link (like a bit.ly link) and then StreetHawk looks after the rest:
- Does the link recipient have your App?
- Based on their platform, should they be sent to Google Play, Apple Appstore or a Web Page
- What Screen should open AFTER the App is installed? – this is deferred deeplinking
- Which links are driving big conversions? Viral? Organic? Paid?
- Which links lead to high lifetime value (LTV) users
The FTUX benefit is uplift of a users engaged with your App. What Dave McClure of 500 Startups calls “Activation”. We can’t guarantee that you’ll keep all your users but you can reduce the amount of churn below the horrific 77% to 50% or around 27% (which is what the best apps are averaging).
So this is awesome! If you are engaging your users, you might be:
- monetizing their activity (InApp purchases, real-world purchases or footfall to retail locations/venues)
- leveraging your users to drive acquisition growth
“One more thing….”
Steve Jobs was famous for “One more thing”… this was his surprise reveal.
With StreetHawk you can deeplink and deferred now
without overhauling your code
We’ve been giving deeplinking abilities to Apps for about 9months with our SDK. Even if you don’t have deeplinking implemented you can use our “yourapp://launchvc?vc=<screen name> command in:
- A Push notification (either transactional or engagement campaign) and
- Email, SMS, website, facebook with that link
This is cool as long as you defined a schemas (see the section below explaining schemas and only a 5 minute job). So you can start doing fabulous on-boarding and FTUX without undertaking a huge developer rewrite of your code.
You can read about the launchvc command here.
What is an App schema?
In the examples above you will see something that looks like a URL. You deeplink to Facebook by using fb://. You deeplink to Yelp with yelp:// and in your own App it would be like MySpecialApp://
So to do ANY deeplinking your developer must have set this up when they do a “build” of the App and submit to Apple Appstore or Google Play.
For the uninitiated back in the pre-web days (when http was just another protocol and had not become dominant) there were many URI’s that were (sort of) reserved. e.g ever heard of gopher:// or ldap://? Perhaps some more obvious ones are ftp:// or mailto:email@example.com.
Personally, I think that schemas are more like DNS than a URI protocol definition because the actual result is not like ftp://hostA/path/to/fileX and ftp://hostB/path/to/fileY.
It’s a shame it has gone this way because it makes a landgrab for that pattern – the URI convention was written during a kindler, gentler time that meant that a server could respond to a ftp://hostname/path/to/file. But in the App world there is only one App that should respond to a particular URL/URI pattern.
For example for our testing, if you have two different apps on your phone with fb: registered, then iOS will likely pick the first
Its not really Apple’s place to control Apps competing for a “pattern:”, but I suspect they will via some Appstore mechanisms. And what happens when an App becomes defunct? Its very similar to domain squatting where a DNS TLD becomes high-stakes property.
If you have multiple Apps on Android that are registered for fb: then a menu of these Apps are presented to the user and they can pick which App they want to handle the deeplink.
Android HTTP handling
Android did something even cooler where in the manifest.xml you can specify the scheme bit you can also specify an http pattern that the App will match. At the time the user clicks a link, they will be prompted for all Apps that support that convention. Consider this example from meetup.com:
BUT ONLY FOR THE APPS INSTALLED ON YOUR PHONE.
Its still a long way from the intentions of RFC3986 but its got specificity of a host implicit in the path pattern.