Navigating Deep Linking Depths
Unraveling Mobile Edge Cases with Third-Party Tracking and Redirection Handling
In today’s dynamic mobile app development landscape, deep linking stands as a cornerstone, facilitating seamless user experiences and intuitive navigation within applications. While many developers grasp the fundamentals of mobile deep linking, this article explores the intricate challenges that often arise later on in the journey.
We’ll focus on the nuanced aspects and edge cases tied to third-party tracking from subdomains and redirection handling on iOS. If you’re new to supporting Apple Universal Links, it’s recommended to familiarize yourself with the essential concepts through resources like Apple’s documentation on Supporting Universal Links in Your App and Antoine Van Der Lee’s comprehensive guide on Universal Links in iOS.
My initial assumption was that only a minimal number of users altered their default browser and email apps. However, conversations with colleagues, friends, and family revealed a higher prevalence of users customizing their default applications than anticipated, revealing deep linking edge cases and opportunities to enhance their experience. Overlooking these edge cases could lead to missed opportunities to streamline user experiences and engage customers more effectively from the outset.
If you’re unsure how to customize these settings, you can refer to the Change the default web browser or email app guide on the Apple support website. This information may be helpful as you continue reading this article.
Let’s delve into these deep link issues together.
Direct vs Indirect Deep Links
With a basic deep link setup, when a user clicks on a direct link, they automatically land on the app in the correct location. Direct links, which do not perform redirection, typically represent the happy path.
You may be wondering why using different default apps can cause deep link issues. So, let me reveal something: Indirect deep linking does not work on non-Apple browsing and email apps.
There’s no need to panic because there are strategies to support this.
Indirect deep link issues may be flying under your radar without you even realizing it. In simple terms, an indirect deep link occurs when a customer clicks on a link that performs a redirection. For example, if you click on a link such as clicks.ssense.com in an email or SMS you’ve received, your browser will land on ssense.com once the redirection occurs. Most of the time, the user does not even notice that a redirection has occurred. It’s also quite possible that developers, product managers, and those sending the links don’t know as well. For happy path scenarios, it’s ok, but there are some not so happy paths that can ensue from such a scenario.
Depending on the size and structure of your company, the Marketing and Engineering teams may not always collaborate closely. While this may not seem like a big problem, certain marketing tools used could have technical implications on how the app handles the deep links. Problems often occur when Marketing decisions are made to implement new tools for email campaigns, promoting them on social media platforms, and using third parties to keep track of attribution, influencer partners tools, click tracking, and more. So, it’s essential for Marketing and Engineering to work together to choose and analyze all these new tools and ensure edge cases are handled efficiently.
Omnichannel Campaign Management and Mobile Measurement Partner tools can support the majority of deep link edge cases, but they do come with a significant price tag and potential conflicts if multiple tools are used simultaneously. Engineering input is essential before investing in such tools to ensure a smooth integration process tailored to your mobile app’s reality.
These are a few reasons for which indirect deep link issues can occur.
Tracking Clicks
Marketing teams need to track user clicks on their campaigns — most of which perform redirections — and as we just discussed, they might not even know because it’s managed by third party tools. To see this in action, hover over a button in a promotional email and check the URL that appears, it may not match the main website.
So, what do these links look like? They may be wrapped in a different URL from one of the tools the company uses, but most likely they will use a custom subdomain URL, meaning that the redirection will be performed from a subdomain of the main domain your customer is familiar with. For example, clicks.ssense.com is a subdomain of ssense.com. As a customer, I feel a lot more confident that it’s not fraud or phishing when the link I click is a subdomain of the exact website I want to land on.
Now that you know about these redirection tactics in Marketing campaigns, you might wonder why you never noticed it before. This is intentional. Companies do this to enhance the user experience and measure the success of their campaigns. By tracking which campaign resonates with their customers, they can improve their future content and increase sales potential. While there’s much more to it, this practice is an industry standard for a reason: it works!
Redirections
From a technical point of view, the reason you may not notice a redirection is because it’s probably performed on the tool server side. On iOS, you may or may not see a pop-up that says: Open this page in “SSENSE” depending on your previous action or the way the redirection is configured for the other websites or apps that you use. This pop-up is not an optimal user experience, but it works if the user uses Apple’s default browser, Safari, or email app.
If the user however has set a different browser or email app, such as Gmail, as default and clicks on a redirection link, they land in a webview or the browser website page instead of the app and they will not see a deep link pop-up.
Either Google wants to keep us in their app, or Apple does not allow others to deep link from redirection. In any case, there isn’t much commentary on this topic. Perhaps you can find a discussion around this on a forum…
Bear in mind that similar considerations would apply if instead of having to redirect a URL via a subdomain, the URL was wrapped in a different short link, such as: https://fb.me/ for Meta socials, partner URLs, or other redirects.
If you don’t already know, I suggest asking your Marketing team what tool is generating the redirection links. While they may all be the same, it’s also possible that they vary between email campaigns and social media campaigns. I’ll stick to email in my example.
At SSENSE, email campaigns are generated with HTML via a multichannel marketing tool.
When the Marketing team sets different links, they use links from our main domain, ssense.com. Then, the tool acts as a black box and transforms all these links into click tracking URLs, clicks.ssense.com.
For example, a “New Arrivals” button setup to open https://www.ssense.com/en-ca/men URL will look like this in the email the customer receives: https://clicks.ssense.com/f/a/WvAwN1ilmVTCtOhgMrD0bg~~/AAQRxQA~/RgRnjQYJP0SoaHR0cHM6Ly93d3cuc3NlbnNlLmNvbS9lbi9tZW4_bGlkPTVyeWtuMXlzbDhlMyZ1dG1fc291cmNlPXNzZW5zZSZ1dG1fbWVkaXVtPWVtYWlsJnV0bV9jYW1wYWlnbj1wcml2YXRlc2FsZSZ1dG1fdGVybT0yNF8wMV8xOV9wcml2YXRlc2FsZV9lX2xveWFsdHlfZW4mdXRtX2NvbnRlbnQ9Zm9vdGVyVwNzcGNCCmWhCoGqZfQW3IhSH21hcmMtYW50b2luZS5sYWJlcmdlQHNzZW5zZS5jb21YBAAAAj0~ .
Let’s talk about the apple-app-site-association that lives in the .well-known directory at the root of your website. This file contains all the rules of paths that should or should not deep link to your app.
The following would allow all URLs to deep link to the app:
This is an example of what you can do, but should never do for many reasons, including security issues.
Another example that would allow only URLs with /en-ca/men path to deep link to the app:
This is better, but more rules could be added to support all cases. It’s already safer than allowing all paths of your website to deep link.
But if you like to play dangerously, you can always play the exclusion game with something like this:
Enhancing the User Experience
Have you considered the redirection sub-domain (or other domain)? This is where you might encounter edge cases. If your user uses all default Apple browser and email apps (Safari and Mail), the redirection should deep link them to the app, or at worst they will see a pop-up to open in your app. But for all other browser/email apps, they’ll stay in the web experience without deep linking.
In order to make these redirection deep links direct, you’ll need to have Apple app site associations file in the .well-known directory of the (sub)domain that performs redirection. In our case, it’s clicks.ssense.com.
Now that we know this, another issue arises with the paths of the redirect URL not being very readable and having nothing to do with the original URL we want the user to reach. In some cases, there may be a parameter in the URL that contains the original URL, giving you a chance to manipulate it. But be careful, as the Marketing team might want elegant short links which would eliminate these parameters. So I suggest you continue reading…
In the case where we have paths that don’t make sense, we can’t have an Apple app site association that matches the one on our main website. Although it may be tempting to allow all paths to deep link to your app with a pretty star (*), this could lead to security vulnerabilities and mismatched content between your website and app. It’s important to strike a balance between guiding users to the app for a better experience and allowing them to access page content that is unique to the website. For example, at SSENSE we have insightful articles that you can only read on our website (https://www.ssense.com/en-ca/editorial). It would be a shame to miss out on all this great content.
Here’s a trick that you may have missed within your Marketing tool.
Remember when I mentioned that our Marketing team builds HTML templates for emails and pastes original URLs, with the tool acting as a black box to transform said URLs? Well, it so happens that this black box might accept inputs. In some cases, you can even add custom paths. What does that mean? How does that work? Well, you can add an attribute to the HTML links to specify if these links should deep link to the app. This new attribute will be a new path in the unreadable redirection URL. Let’s demonstrate this with an example:
Instead of generating https://clicks.ssense.com/f/a/WvAwN1ilmVTCtOhgMrD0bg~~/AAQRxQA~/RgRnjQYJP0SoaHR0cHM6Ly93d3cuc3NlbnNlLmNvbS9lbi9tZW4_bGlkPTVyeWtuMXlzbDhlMyZ1dG1fc291cmNlPXNzZW5zZSZ1dG1fbWVkaXVtPWVtYWlsJnV0bV9jYW1wYWlnbj1wcml2YXRlc2FsZSZ1dG1fdGVybT0yNF8wMV8xOV9wcml2YXRlc2FsZV9lX2xveWFsdHlfZW4mdXRtX2NvbnRlbnQ9Zm9vdGVyVwNzcGNCCmWhCoGqZfQW3IhSH21hcmMtYW50b2luZS5sYWJlcmdlQHNzZW5zZS5jb21YBAAAAj0~ for https://www.ssense.com/en-ca/men URL, we could have something like: https://clicks.ssense.com/f/open-in-app/WvAwN1ilmVTCtOhgMrD0bg~~/AAQRxQA~/RgRnjQYJP0SoaHR0cHM6Ly93d3cuc3NlbnNlLmNvbS9lbi9tZW4_bGlkPTVyeWtuMXlzbDhlMyZ1dG1fc291cmNlPXNzZW5zZSZ1dG1fbWVkaXVtPWVtYWlsJnV0bV9jYW1wYWlnbj1wcml2YXRlc2FsZSZ1dG1fdGVybT0yNF8wMV8xOV9wcml2YXRlc2FsZV9lX2xveWFsdHlfZW4mdXRtX2NvbnRlbnQ9Zm9vdGVyVwNzcGNCCmWhCoGqZfQW3IhSH21hcmMtYW50b2luZS5sYWJlcmdlQHNzZW5zZS5jb21.
See the difference?
Instead of /f/a/unreadable path, you could have /f/open-in-app/unreadable path. This way, you allow just a specific path to deep link to your app.
Here’s what the Apple app site association file should look like for clicks.ssense.com:
Now, it’s important to ensure alignment between the Engineering and Marketing teams. The first step is to collaboratively select a custom path name. The Marketing team should have an understanding of which links should or should not deep link to the app, including when to include the custom attribute to HTML links.
It’s worth noting that this approach may vary slightly depending on your setup. For example, that custom HTML attribute may just be a boolean, allowing only one path that is not customizable.
Now we know that WE CAN deep link with any browser or email apps. All we need to do is make that redirect a direct deep link. But we are not done yet because even though we added a custom path to support deep links, we still don’t have the full path… Did I say I was done explaining already? Let’s continue.
Technical Approach
After discussing the Marketing aspect, it’s time to get more technical and address how to handle these links once they hit the app. Which link do we get when the app is open?
We have a couple options and this is where I think many will be able to draw a parallel with that approach, not only for click tracking, but also for other kinds of links used with partners, short links and more.
The first option is to fetch the redirection from the app. Yes, you heard me correctly, by fetching the URL received and obtaining the resulting redirected URL, you can navigate the user to the appropriate page within the app. This option will work if the redirection is performed on the server side of the subdomain, but might not work if there’s some sort of client side redirection.
The second option is quite similar to the first one, but could cover more cases. Sometimes, the Marketing tools offer access to some of their API endpoints where you can specify attributes you get from the URL, in addition to some keys that you know but don’t get with the URL. This approach is great when the redirection URL lacks certain parameters like UTMs. The payload that you’ll get when calling the endpoint will contain more data like, of course, the resulting URL, attribution/UTM parameters, and even the campaign creation date. But in any case, what you want is to deep link users correctly and you can.
One thing that initially concerned us with this approach was the added delays from having to fetch the resulting URL. But after analyzing it further, we found that the delays were negligible. The response time was quite good when fetching via the URL or the API endpoint. Of course, there’s always the risk that the fetch fails if the API is down, or other network issues, but just make sure to handle these cases gracefully and you should be able to sleep well.
Ultimately, all these fancy links that perform redirections are just wrappers of your main URLs. If you look into the open source code of those SDKs, claiming to handle everything magically, you’ll likely find a similar solution under the facade. We all have different code base realities, with various tools that don’t necessarily want to work together and may not seamlessly integrate.
We could even go further to reduce the possibility of human errors like forgetting to set attributes for a link that should deep link or worse, the reverse. I wonder if we could leave these wrapper links to redirect and implement some sort of double redirection from the main website. Let me quickly explain my idea: When a redirection occurs from the main website, we could incorporate some “server side” logic to determine which kind of device the user is using and whether they have the app installed or not. If the app is already installed, we could attempt to redirect users to the app using schemes instead. This could be an interesting avenue to explore as the next step, and perhaps a good topic for a follow-up article.
Continuing the Deep Link Journey
While this article primarily focuses on iOS, the knowledge can be extended to Android. In our case, we’ve applied this approach in our React Native App. Some handling is done at the native layers. We’ve applied this strategy not only to emails but also to certain redirections within a wide variety of Marketing tools.
Do you get how this applies to many other kinds of URLs that bring your user to your website and mobile app? If not, let’s continue the conversation in the comments section, as our deep link journeys continue to evolve.
Editorial reviews by Catherine Heim, Luba Mikhnovsky, Sam-Nicolai Johnston & Mario Bittencourt.
Want to work with us? Click here to see all open positions at SSENSE!
