In-app messages

If you have a mobile application for your users, in-app messages are a way of displaying banners to them within the app. The feature uses the same principle as pop-up weblayers displayed to your website visitors.

This article will show you why in-app messages are useful and guide you through their usage from initial creation to evaluation.

📘

Note

In order for in-app messages to work, your app must implement the appropriate Mobile SDK.

Additionally, this feature needs to be enabled in the project by the CSM.

🚧

Important

The maximum size of an in-app message is 16 megabytes.

Why use in-app messages?

In-app messages are important because they allow you to communicate directly with your customers while they are using the app. This can effectively provide personalized and timely information to customers, such as order updates, promotional offers, and customer service assistance, thus improving the overall customer experience

Some specific benefits of in-app messaging for e-commerce include:

• Targeted communication: In-app messages can be customized and targeted to specific groups of customers, allowing you to send personalized and relevant messages.
• Improved conversion rates: By providing customers with timely and relevant information, in-app messages can help to increase the likelihood that they will complete a purchase or take the desired action.
• Enhanced customer engagement: In-app messages provide a direct and convenient way for customers to interact with your company, which can help to increase customer engagement and build loyalty.
• Increased customer satisfaction: By providing helpful and timely information, in-app messages can help to improve the overall customer experience and increase satisfaction.

In-app message types

In-app messages can be one of the following types:

• HTML-based (default) - Visual builder - In-app messages of this type have advanced formatting and styling capabilities and are built using a drag-and-drop workflow.
• HTML-based (default) - HTML builder - In-app messages of this type have advanced formatting and styling capabilities and are created using HTML and CSS code.
• Native - In-app messages of this type use the native functionality of Android and iOS for displaying popups. They are restricted to the default system formatting and styling. They must be created from a pre-defined template.

Use in-app messages

To create an in-app message, go to Campaigns > In-app personalization > + New in-app personalization.

You can create a new in-app personalization or select one of the pre-defined templates.

Clicking on Create new in-app personalization will give you the option to use the Visual builder or the HTML builder.

Pre-defined HTML-based templates will open in the Visual builder by default. Click on the three dots (...) in the top right corner to choose between Visual builder and HTML builder.

Pre-defined templates marked Native will open in the Native builder.

Visual builder

The Visual builder uses a drag-and-drop workflow, enabling you to build HTML-based in-app messages without any advanced coding know-how. It consists of two main parts:

• An editing region
• A tabbed pane with elements you can drag onto the editing region or change its settings

The tabbed pane contains 3 main tabs:

• Content
• Rows
• Settings

Make sure the Type dropdown is set to In-app message (the other option is In-app content block).

Settings tab

The Settings tab allows you to configure the global parameters of your in-app message template. For example:

• Content area alignment
• Background color
• Content area background color
• Default font
• Link color
• Language attribute

You can do so by changing sliders or respective input fields.

Rows tab

The elements in the Rows tab allow you to design the structure of your in-app message template. These row elements serve as a frame for the content you will add later.

You can also configure the appearance of these rows. A Row properties pane appears if you click on a row that is already placed in the editing region. You can set additional settings for each individual row, such as background color or padding.

For more information about configuring rows, refer to Rows tab section in the Email editors - Visual builder documentation.

Content tab

After adding the rows to your template, you can fill them with content. The various content elements that you can use are grouped together under the Content tab.

The following content elements are available:

You can use Jinja personalization in your templates. To do so, click the { } button at the bottom right of the editing region to open the Jinja editor.

Button behavior

Typically, you specify a URL in the Button properties pane, in the Action section.

When the user clicks on the button, the default behavior is as follows:

• If the URL starts with http or https, open the link in the web browser.
• In all other cases, let the app process the link (custom scheme or Universal Link).

You can override this default behavior using the data-link and data-actiontype attributes.

The data-link attribute accepts a URL and overrides the URL specified in the Action section.

The data-actiontype attribute accepts on of the following three values:

📘

Note

Android SDK up to version 4.0.1 only recognizes the first button with action type "close" as close button. Any additional buttons with action type "close" will have default link behavior.

iOS SDK as well as Android SDK versions later than 4.0.1 support multiple close buttons.

HTML builder

The HTML builder allows you to create an in-app personalization by writing HTML and CSS code.

Make sure the Type dropdown is set to In-app message (the other option is In-app content block).

Enter HTML and CSS code in the editor on the right. The preview on the left will update in real time.

👍

Tip

Test your HTML code on a real device to ensure it will work across devices before starting your campaign.
Always use standard HTML and CSS and avoid using experimental features or proprietary values.

🚧

Important

Always use standard HTML and CSS. Avoid using experimental features or proprietary values.

Forbidden HTML tags and attributes:

Tags: head, script, link, iframe, meta, title, body
Attributes: onclick, href and other inline javascript attributes

Button behavior

You can use the data-link attribute to specify button links.

You can use the data-actiontype attribute to override the default button behavior.

Refer to Visual builder - Button behavior above for details.

Native builder

If you selected a template marked Native, the Visual builder will have limited options corresponding to the native functionality and default system styling of Android and iOS for displaying popups.

You can edit the design of the in-app message in the right column. There is no limit on the number of characters or words you can use in an in-app message.

You can choose from four native templates:

• Alert: Includes Title, Text, and Buttons.
• Slide-in: Includes Title, Text, Image (left/right), Buttons, and Style. The image is stretched top to bottom, maintaining the aspect ratio (cropped left and right, centered).
• Modal: Includes Title, Text, Image, Buttons, and Style. The image is stretched horizontally, maintaining aspect ratio, and cropped and centered vertically when the modal's total height reaches 80% of the screen height.
• Fullscreen: Includes Title, Text, Image, Buttons, and Style. The image is stretched horizontally, maintaining aspect ratio, and cropped and centered vertically.

Each template includes a unique set of elements you can combine to achieve your desired result. They also vary in size and screen space usage:

• Title: A single line header for your In-App Message, with customizable font size and color.
• Text: A customizable block of text that can span multiple lines, with adjustable font size and color.
• Image: You can include an image in all templates except Alert. The image will be cropped and/or stretched based on the chosen template.
  (Note: Image URLs cannot be longer than 190 characters)
• Buttons: You can include up to two CTA buttons. These buttons take the user to a web page in their browser (URL) or to a specific page in the app (deep link) when clicked. The text, text color, and button color are customizable.
• Style: You can also declare limited CSS styling for the template, including the background color and x-close color for the In-App close icon.

📘

Note

If you want to delete any component, for example, a button or a header, you only need to delete its text. The entire component will be deleted along with it.

To see how the message looks for a specific customer/segment of customers or for Android or iOS devices click on Preview and select the specific segment of customers and the device type.

You can add Buttons to in-app messages to enable your customers to interact with them. These offer you two choices:

1. Deep link - navigates your customer from the in-app message onto a specified link
2. Cancel - navigates your customer away from the in-app message, thus quitting it

Limitations of the Native builder

• Custom fonts are not supported.
• Using images with a resolution higher than full HD (1920x1080 pixels) is not recommended due to potential rendering timeouts and increased traffic consumption.
• PNG is the preferred image format.
• We recommend keeping the combined character count of the Title and Text under 500.
• Alert messages on iOS include a default cancellation button. To change it, you will need to overwrite the default SDK implementation of InAppMessageAlertView.swift.

A/B testing

If you want to A/B test your in-app message, first enable A/B Test in the top right corner. Then, go to the A/B Test tab and set up your test as explained in the A/B testing documentation.

Settings

In-app messages have the same settings as Weblayers plus the following additional settings:

Evaluate

You can compare the conversion and click rates by going to the Evaluate tab, which contains a dashboard with measurements of the effectiveness of the in-app messages sent.

Definitions:

• Reach: the in-app message was shown to the customer
• Interaction: the customer interacted with the in-app message (excluding close actions)
• Close: the customer closed the in-app message
• Engagement: the customer had a positive engagement in the 24 hours since they first interacted with the in-app message

Tracking

Each in-app message shown to a customer is tracked as a banner event with the same attributes as in any weblayer. Additionally, the following attributes unique to in-app personalizations are tracked:

Error messages

If an error occurs while delivering an in-app message to a customer's device, the banner event will have an additional attribute error with an error message as value.

You may encounter the following error messages:

If any of the above errors are tracked frequently, that may indicate e a problem with the implementation of the Mobile SDK in your app.

Use cases

Predictive in-app messaging

You can decide to target only the customers with the highest likelihood of conversion. By using Predictions, you create a customer segment with the highest probability of completing a certain action, such as a purchase or interaction. These segments can thereafter be used in in-app messages.

Connect the desktop experience with your mobile app.

You can personalize the content of your in-app messages for every individual customer. This is possible thanks to the unified single customer view where you can use all the customer data collected through multiple different channels. You could, for example, check which customers have not opened your newsletter with personalized products, and display to them that same selection of products in the app instead.

📘

Note

Due to personalization being enabled, you can also use product recommendation models within in-app messages to show recommended products.

Best practices

Images

• Use an image file format supported by the target platform or platforms.
  • GIF, JPEG, PNG are natively supported by both Android and iOS.
  • WebP and HEIC are newer formats that aren't supported on some Android and iOS versions.
• Use an appropriate image size and aspect ratio.
  • Don't use images of a larger size than they need to be. Such images will be scaled down to the appropriate size and display normally but they take up more bandwidth and may lead to a delivery delay.
  • Don't use images whose aspect ratio does not match the layout and design of the in-app message. Such images will be appropriately scaled down to the correct aspect ratio, but they take up more bandwidth and may lead to a delivery delay.
  • Some common screen resolutions for reference:
    • 1284×2778 – Found on high-end iOS devices like the iPhone 14 Pro Max.
    • 1440×3200 – Found on premium Android devices like the Samsung Galaxy S series.
• The Mobile SDKs include the device and OS used in the tracked event properties. You can use this data to analyze which devices and OS versions your customers use.

Clone to another project

This feature allows you to clone in-app messages to other projects you have access to. Read more about Cloneable Data Mapping in our Data Manager article.