I first heard about deep linking while building my own app, One Day Gym Pass, which lets you buy day passes to nearby gyms.
Ahead of the launch, I started thinking about how we were going to get users, and I came up with an idea: Wouldn't it be cool if we partnered with fitness-tracking apps to acquire users?
Someone tracking their fitness near one of our gym partners could, theoretically, receive a notification or inline prompt to purchase a discounted day pass to a nearby gym through our service. I'd pay the fitness-tracking app for each user it sent over to my app, and -- assuming we could track it properly -- I'd give them a cut of the resulting sale.
I quickly learned that the infrastructure required for such a cross-app partnership is pretty tough to build, especially if I wanted to partner with multiple fitness-tracking apps. Thankfully a handful of companies has emerged in the past year or so aiming to create a connective tissue in the mobile economy that facilitates traffic and transactions between apps.
After reading a few John Battelle posts describing the imminent "quickening" in mobile, I became hooked on the idea of flattening the walls between apps.
So I created a group called Deeplink.NYC to get product people in New York talking about deep linking as a means of creating new opportunities and economies across mobile.
At our first meetup last month, four startups in the space -- Deeplink, URX, Button and Wildcard -- demoed their products to an audience of developers, designers and founders, followed by a panel moderated by Vera Tzoneva, who works on deep linking at Google.
Here are four takeaways from Deeplink.NYC's first meetup. (Full disclosure: I decided to take a job at URX after the event.)
1) There's no benefit to hoarding users.
Chris Maddern from Button drove this point home with a delightfully simple observation that seems to elude app developers who scoff at the idea of a partnership that sends their users into other apps. In commerce apps, he noted, there's nothing to do when you're done: "After I've got an Uber, my appetite for an Uber is fulfilled. I don't need a second Uber five minutes later."
As a result, for commerce-based apps, there's no real benefit to keeping users in your app forever, though there is a benefit to directing them elsewhere after they complete a purchase. For one, it extends the functionality of your product. Say you're a restaurant-reservations service: Shouldn't your users be able to book a ride to the restaurant from within your app? Secondly, you can receive referral pay from partner apps each time you send them a new user.
2) There's a fatal flaw of deep links (and cards).
Wildcard reiterated this fact as one of deep linking's shortcomings: If a user doesn't have an app installed, and you deep-link them into that app, then they're either sent to the mobile Web or to an app store's download page. Bouncing someone from app to Web is a poor user experience, and sending them to an app store's download page is totally removed from the user's intent: "I don't want to download another app; I just want to buy those shoes."
Wildcard's answer: cards. Cards let developers "share little native snip-its of their apps" so users can start experiencing the app without having to install it, which is a great solution for purely content-based apps (and developers should be pushing hard for standards and common tools to show content natively across contexts). But what about commerce-based apps?
Due to privacy concerns, Apple prohibits passing payment information via cards across contexts. So I still have to download another app (or check out on the mobile Web) to buy those shoes. Listen, I'm just trying to get these shoes back to my house so I can wear them.
3) There's a difference between an ad and a feature.
Here's a common reaction to the growing popularity of inter-app experiences: "So now advertisers are going to be polluting mobile with ads as they've done on the Web. Great."
But early-use cases show that many of the app-to-app experiences facilitated by deep linking are far from banner ads. Instead, they're more like product features.
For example, being able to book a ride from within a restaurant-reservations app like Resy: ad or feature?
Or being able to listen to music from within a fitness-tracking app like Fitocracy: ad or feature?
Or being able buy a concert ticket while listening to a band's music in an app like Spotify: ad or feature?
4) There's one-to-one, and then there's one-to-many.
Where things really start to get interesting is the one-to-many cross-app partnerships. For instance, if you're a sports-news app seeking a cross-app partnership with a ticketing engine so that your readers can buy tickets without leaving your app, why limit your app to the offerings in just one ticketing engine?
What if that ticketing engine shuts down or its tickets become unreasonably priced? Instead, why not show results in your app sourced from multiple ticketing services, such as Stubhub, SeatGeek and Ticketmaster? How would you then choose to rank those results within your app?
Check out Deeplink.NYC to see slides from the demos and sign up for the next meetup.