Journeys & iOS Safari Banner Compatibility

If you have iOS Universal Links enabled on your main domain, you should see Apple's Smart App Banners along with your Journeys banner. This can lead to customer confusion on which call to action to interact with to get to your mobile app.

In order to maximize conversion while maintaining full compatibility of Journeys and Universal Links, we recommend utilizing a Floating Pill Button for your Journeys campaign.

Journeys Website Redirect Options

You can configure your Journeys banner to redirect users to a website by doing the following:

Configure Your Redirect Keys

• $android_url - Controls where the journey sends Android users who do not have the app installed; otherwise user will be deep linked into app if installed.
• $ios_url - Controls where the journey sends iOS users who do not have the app installed; otherwise user will be deep linked into app if installed.
• $fallback_url - Controls where the journey sends users who do not have the app installed; otherwise user will be deep linked into app if installed.
• $journeys_cta - Controls where the journey link will redirect to.
  • User is redirected to the provided location regardless of whether or not they have the app installed.
    • For example, redirect all Journeys clicks to mobile web OR deep link users to a different app for cross promotion.
  • This key overrides all others.
  • NOTE: Removes the ability to track Journeys click-through rates, as the customer’s link will be used for the CTA. Branch will not get clicks, and thus it will not be able to attribute installs, opens or conversion events.

Setup via Dashboard

When configuring your Journeys Template:

• On the VIEW EDITOR tab, click the CTA button in the UI of the template you've chosen.
• Add key-value pairs in the DEEP LINK DATA section.
• Click Save&Close.

Setup via Web SDK

Use .setBranchViewData() to programmatically set one or more of the above redirects within the data array

branch.init(...);
branch.setBranchViewData({data: {'$journeys_cta': 'https://example.com',}});

Journeys Image Recommendations

Journeys are hugely successful at bringing mobile web users into your apps. But to be most effective, the Journey needs to look great and fit well on the page. The difficulty here is that Journeys can come in a wide variety of shapes and sizes but this guide should help you make some sizing decisions for a few of the most requested Journeys Templates.

Requirements to image formats

When uploading a template background image, the formats supported through "Upload image" tool are jpeg, png, gif, pdf, mp4, or mov.

Full Page Image

The Full Page Journey is a bit tricky because the template itself is responsive to the dimensions of the phone. To account for these potentially changing dimensions, some bleed must be built into the images in use.

Partial Page Image

The Partial Page Journey can be a little easier to account for because the template itself is responsive to the dimensions of only the width if desired or as a percentage of the view height. To account for these potentially changing dimensions, some bleed must be built into the images in use.

Fixed Height

Variable Height (33% View Height) - Top

Variable Height (33% View Height) - Bottom

App Icon Image

Recommended sizing: 180x180px

Interstitial 6

Banner Tall Banner Bottom 1

Banner Tall Banner Top 4

Template 3

Template 4

Dynamic Journeys Layout Customization

We now support the use case where you can customize the appearance of a Journey depending on which link referred the web session. So, you can create a Branch link with a set of defined keys and values that will change properties such as the title or images when the user is referred to your website from this link.

Note that not all template support all override keys. For example, the floating button does not support title, description or icon image url (floating buttons will support the custom liquid tags detailed below though). If a template is to be rendered and the key you've specified does not exist, we'll simply ignore it while rendering the template.

Custom tags for dynamic Journeys layout customization

In addition to using pre-defined keys (e.g. $journeys_title) to dynamically customize the appearance/content of a Journey, you can use custom liquid tags. Custom tags can be inserted in both the View Editor and the CSS Editor when you’re setting up a Journeys template. Then, you can use setBranchViewData() to dynamically provide values for these tags. You can also embed those values statically on a page with Branch Meta Tags.

Note that if you include custom liquid tags in your templates and also set a value for a pre-defined key (e.g. $journeys_title) in setBranchViewData(), the value of the pre-defined key will take precedence.

The format for a custom liquid tag is as follows. Note that a default value must be specified for every custom tag you include:

{{ key_name | default_value }}

For example, if you were adding a custom liquid tag in CSS to dynamically control the font size of one of your Journeys’ title, you might use a tag like the one below:

{{ fontSize | 12px }}

And if you were adding a custom liquid tag in your template text, you might use a tag like the one below:

{{ adjective | best }}

Then, to dynamically update values for the “fontSize” and “adjective” variables, you would set values for those variables using setBranchViewData():

branch.init(...);
branch.setBranchViewData({
    data: {
        'fontSize': '20px',
        'adjective': 'most entertaining',
    }
});

Or, you can set the values by embedding Branch Meta Tags on the page:

<meta name="branch:deeplink:fontSize" content="20px" />
<meta name="branch:deeplink:adjective" content="most entertaining" />

Journeys Customization for Specific Screen Sizes (CSS)

There is an ability to customize banners for specific screen sizes or even potentially, specific devices, through the use of CSS @media queries. This is a feature of modern browsers and allows you to add logic and apply CSS formats based on the parameters provided by the browser.

⚠️This requires direct CSS knowledge and testing of changes is recommended prior to going live.

1. You can choose to do this at the #branch-banner-iframe container level or at the individual #branch-banner objects level.
2. Determine what property changes you want to make and tied to what available @media query parameters. For example:
   • You want to make the title, stars, reviews, and icon smaller for smaller screen devices.
   • You might want to provide special formatting for a very specific family of devices.
3. Translate your logic into CSS code. Use resources on the web if you are unfamiliar with the syntax:
   • https://developer.mozilla.org/en-US/docs/Web/CSS/@media
   • Web search "@media standard queries" to find some work published to target specific device models, if desired
   • Here's an example that says, for browsers that report a screen width of 1px to 350px, set this CSS:

@media only screen and (min-device-width: 200px) and (max-device-width: 350px) {
  #branch-banner .branch-banner-title {
    font-weight: bold;
    color: #333333;
    padding-bottom: 1px;
    font-size: 10px;
  }
  #branch-banner .branch-banner-stars {
    display: inline-block;
    color: rgba(255, 180, 0, 1);
    letter-spacing: -2px;
    font-size: 14px;
    margin-left: -2px;
  }
  #branch-banner .branch-banner-reviews {
    font-size: 10px;
    color: #777;
    display: inline-block;
    margin-left: 4px;
    position: relative;
    top: -1px;
  }
  #branch-banner .branch-banner-icon img {
    width: 40px;
    height: 40px;
    border-radius: 10px;
  }
  #branch-banner .branch-banner-icon {
    float: left;
    border-radius: 10px;
    width: 40px;
    height: 40px;
    margin-right: 10px;
    padding: 10px 0;
    position: relative;
    top: 50%;
    transform: translateY(-50%);
    -webkit-transform: translateY(-50%);
    -ms-transform: translateY(-50%);
    z-index: 2;
  }

4. Use the test feature to preview the changes in a separate browser instance while emulating different device models/sizes to ensure the banner renders as intended. Inspect the CSS of the page if necessary to validate these properties are reflected in the real banner.
5. Lastly, make sure your logical operators does not have any loopholes or cases left without proper CSS formatting. One approach is an inverse block that reads: @media not screen and (min-device-width: 1px) and (max-device-width: 350px) { to catch all other screen sizes the only block above ignores.