Overview of domains, URLs and deep links
It is very important that we understand the sharing and social media strategy that you have. If you don't have one, we can help you formulate it. Our research shows that your app users are your best and most loyal users, so pushing users towards the app is beneficial.
In order for your app to be as successful as possible, we need to ensure that it is possible for users to discover it, and end up in the right place when they tap a link - be it from; your website, social media post, a push notification or any other source.
In this doc you'll find an overview of the options available and if you're interested in any of them, you'll find more in-depth guides attached.
The first thing to consider will be your app domain. These are public facing, they will be seen by any users that view your content on Bolt Web, and will be visible in newsletters or social media if you are sending out links.
When you first join us you may see your app domain as something like https://yourcompany.content.pugpig.com/ - which you don't want your users to see. To solve this, one of the first things we'll ask you to do is set up a vanity domain.
We can customise your URLs to follow a particular format if desired. This is especially important if you decide to implement canonical URLs as the app and website URLs will need to share enough common ground to be linked.
To find out about the different options available as well as our URL update plugin, which allows us to change all historical and new URLs, check out our URL structure doc.
Linking and sharing
Users on a mobile device with the app installed
If a user already has your app installed, the app will open and the user will be taken to the right location.
Users on a mobile device without the app installed
A new user will not have the app installed on their device. If you are happy for anonymous users to view your content, the shared story will open as a standalone page in the browser on their device. If they are on iOS, the native iOS Smart Banner will be shown, inviting them to download the app.
If they are on Android, we can show something similar.
We can also include extra marketing information above or below the story using the Pugpig Smart Banner. If you are not happy for anonymous users to see the content, the best we can do is redirect the user to the relevant page on your website, or to a page on your web site advising them how to subscribe.
Users on a laptop or desktop
If a user follows an app domain link on a desktop or laptop, there won't be an app installed, so the link will open in their browser as usual. In virtually all cases, this will be a deep link to an article. The options here are:
- redirect the user to the correct article in the web reader, assuming you are using it. If a user has already been to the web reader, we remember than and automatically redirect them there in the future.
- show the article as a standalone page without navigation, but with more information telling them about the apps
- redirect them to the article on your web site
Almost all mailing services (E.g. Mailchimp, Salesforce Marketing Cloud) rewrite any links in the email to enable clickthrough tracking. As this new link opens in the browser before redirecting it breaks the flow described above, meaning links from newsletters will usually not redirect to the web reader.
The apps will always handle deep links to your articles on the app domain. However, you may want to send deep links to other parts of your app(s). This is particularly common in push notifications as you know they will only be received by users that already have the app installed.
You can send deep links to specific content areas of the app (such as specific tabs, timelines or editions). You can also send command links that will open areas of the app such as the subscribe page or the audio player.
Full information on the available deep links is described in our Deeplinking in Pugpig Bolt article.
With the implementation of Canonical URLs you can share your website link everywhere without worrying where people will end up. Existing app users will end up opening the app in the correct place, while anyone without the app installed, or anyone who opens the link on a laptop or desktop, will go to the website as intended. It is the best all round solution, but does require development work on our end and yours. If this sounds like something you'd be interested in take a look at our document about making canonical links open in the app.
If you're a Pugpig Site and Pugpig Bolt customer no need to worry, this will all be handled for you!
You'll probably recognise smart banners from your day to day mobile usage. As stated in Apple's Smart banner documentation - “Smart App Banners provide a consistent look and feel that users come to recognize. They trust that tapping the banner will take them to the App Store and not a third-party advertisement. They appreciate unobtrusive banners at the top of a webpage, instead of a full screen that interrupts their experience with the web content. And with a large and prominent Close button, a banner is easy to dismiss. When the user returns to the webpage, the banner doesn’t reappear.”
We automatically add the relevant smart banner to all app HTML content pages depending on what platform a user opens it on. But you can also add them to your website.
Smart banner implementation on iOS is straightforward and seamless. Android is less optimised but there are still options available, and we have our own to handle certain edge cases. We go through all three in our smart banner documentation.
How does all of this affect paid content?
If you have paid for content, your paywall strategy will also come into play, especially if you (or your users) are sharing links to your app domain. You want the experience of the recipient of the share link to be as good as possible. Some of our clients allow sharing, but restrict the number of times a user can share, or a shared article can be read. This will virtually always require integration with your back end system or API that controls the sharing count.