On the Branch blog, we’ve talked a lot about deep linking, deferred deep linking, contextual deep linking… you name it. You’ve learned the values Branch links provide, from deep linking for marketing links, content sharing, referral programs, onboarding, and more. But if you want to get into the specifics on how our Branch linking works, this ongoing guide is for you.
Anatomy of a Branch Deep Link
This is part one of a four part series. Following posts will cover redirects, matching, and analytics. In this first post, I’ll be diving into the anatomy of a link: the core explanation of what a Branch link is as a product. This consumer-facing product is seen not only by our consumers (our partner developers), but by their consumers as well, so we know the execution on this is extremely important.
Linking into apps gets complicated quickly. But simply put, a Branch link is a regular web link, and functions just how you would expect a web link to function, with lots of tech baked in automatically. If you know how regular links work on the web, then you know the traversal from someone clicking to someone seeing a web page. With Branch, this means that whenever and wherever anyone clicks our links, we get a user-agent. With this user-agent, Branch gets information into who is clicking that link (device, platform, IP address). This is a large part of how Branch links can be placed/clicked anywhere and subsequently use the correct routing every time.
Another benefit of Branch being a web link is that every Branch link is associated with an actual page on the web. I’ll let this sink in: a Branch link is a literal page on the web. This is exciting because it means each URL is unique and can be associated with different data. https://bnc.lt/abc is fundamentally different from https://bnc.lt/xyz, and now you can apply these differences to different types of data:
Branch Link Structure
The trick is in this URL structure. Just like in the rest of the web, we can separate, organize, and create these web pages based off of what these URLs are telling us. A URL ending in /abc may be associated with App Data A, and a URL ending in /xyz may be stored and tied to App Data B. These data groups can tell us everything from how to route a user coming from Facebook to how to attribute a new user (to a marketing campaign, for example).
When a user clicks that URL ending in /abc, Branch looks up that URL to see which of our partnered apps created it, as well as what that data was associated with it when the app created that link. This data includes what we use for basic routing (the app’s URI scheme and where it lives on the App Store or Play store), but also includes any custom data that you, the developer, want to include (but more on customization in upcoming posts). This information, plus the user-agent information we talked about before, means that Branch gets routing right every time.
We’ll get into how Branch customizes our ‘web-pages’ and routing in future posts, but for now, you now know what a Branch link is: a link that, upon clicking, takes a user to a page Branch generates. Once that page is generated and we associate deep link data back to a click, Branch routes a user based on flexible and customizable data that can be associated with the url and web page.
There’s so much more to how we use this data (everything from routing to analytics). Subscribe to our blog to keep in touch with future posts, where I’ll continue my deep dive into Branch links, including routing and redirections, matching and linking through app stores, analytics, customization, and hosted tags. I’ll also be taking requests on which parts of Branch linking you’d like us to cover. Leave a comment with your suggestions and I’ll incorporate it in a future Branch Links 101 post!
Ready to implement your own Branch Links?