Introduction to in-app messages

In-app messages allow you to display any creation in a mobile application. This feature allows you to implement use cases such as abandoned cart, discount codes, or any information campaign, such as application update.

In contrast to push notifications which are sent (pushed) to the app user by Synerise, in-app messages are requested (pulled) by the user's device through Synerise mobile SDK. Thanks to this, you can design your mobile application to request and show notification precisely when you need to, making them more reliable in some scenarios than push notifications. Combining this with the capabilities of segmentations and Decision Hub that allow you to measure the performance, in-app messages can be targeted better and more effective.

In-app messages vs push notifications

How it works

In-app messages are fetched:

• when the application is launched,
• after refresh of in-app definitions that occurs every 10 minutes by default,
• when the customer context changes (for example, a user logs in/logs out, UUID changes)

When a mobile application user performs an activity which triggers an in-app message, then the message is displayed.

The mobile application can display only 1 in-app message at a time. The selection of the in-app message to display is based on:

• the priority assigned to the message
• the time windows a message is scheduled to display (if any are set)
• limits established for a particular in-app message to not upset app users

The rest of the in-app messages which overlap are stored in the memory. They can be displayed if triggered.

Key information

• In-app messages are fetched and kept by SDK for 6 hours. Because of this, when you stop the communication, customers may still see the message until in-app messages are fetched again and refreshed by the SDK
• If your mobile application is a single-activity application, an in-app message is displayed after switching between the screens in the application.

In-app types

In-app messages are divided into two main types:

• Overlay in-apps are displayed as a layer in the application:
  • Top bar - In-app messages are shown at the top bar of the application, and user interaction is limited to the area below the message.
  • Bottom bar - In-app messages appear at the bottom bar of the application, with user interaction restricted to the area above the message.
  • Fullscreen - In-app messages are displayed in the center of the mobile application, with no clickable elements within the application.
    These display options are selectable in the in-app template builders.
• Inline in-apps can be used to manage large chunks of content, or even all content, in an application.
  Inline in-apps can be added to any container in your application, without releasing a new version of the application. The container can be a small element, such as a search box, a group of elements, or even manage all the content shown in the application. As you gather more data about a customer, you can make the elements more personalized, tailoring both the content and its layout to the customer's preferences - all without updating any application code on the customer's device.
  The display of this content can be triggered by events or on-demand, by calling a method in the SDK.
  Some examples of what you can show as inline in-apps are:
  • A Stories widget
  • Promotions and recommendations intertwined with app content
  • Personalized menus
  • Progress bars with order status
  • A Loyalty card and points widget
  • A Chat with the Customer AI Assistant
  • Replacing a piece of content with a different one only for customers who meet the audience requirements

For developer integration instructions, see Overlay in-app and Inline in-app in the Developer Guides.

In-app type summary

In-app list

When you go to Experience Hub > In-App, the list of messages opens. From this view, you can:

• create new in-apps.
• open existing in-apps to edit them.
  Editing an in-app involves the same views and options as creating a new one.
• filter the list by in-app status, type, and tags.
• create folders and add in-apps to them for easier management.
• see and change the status (start/pause/stop) of an in-app.
• see and edit the tags assigned to a message.
• see basic statistics:
  • the number of times an in-app message has been displayed,
  • the number of link clicks in an in-app,
  • Click-Through Rate (CTR).
    You can create more advanced analyses in Decision Hub using the events generated by in-app messages.
• see the placement key used by the message (inline only).
• see the priority of the message.
• see information about the author.
• see the list of variants of a message.
• send tests.
• duplicate a message.
• clone to another workspace.
• delete messages.

Requirements

The minimum SDK version depends on the feature you use:

• If your in-app content (such as JavaScript, CSS, images, or fonts) is being loaded from your own server via HTTP and you have configured CORS policies, you need to set the contentBaseUrl to your server's address. For example, if you're loading resources from https://www.synerise.com/example/font.woff, you should configure contentBaseUrl to https://www.synerise.com (check this option in the Settings). The value must be a valid absolute URL. An invalid value is ignored and only reported in the SDK log.
• Enable the IN_APP_DEFINITIONS_COMMUNICATION_READ (Experience Hub) permission in the Profile (formerly Client) API key used by the mobile application so the mobile application can fetch in-app messages.
  

  

• Inline in-apps: embed a placement component in your UI (InlineInAppView created with Injector.createInlineInAppView on Android and iOS, the InlineInAppView React component in React Native). The placement key used in the app must match the one configured in the campaign. See Inline in-app
• Flutter 2.11.0: configure the SDK's reverse method channel in MainActivity.configureFlutterEngine. Without it, the application crashes with a NullPointerException on the first in-app callback. iOS needs no extra steps. Starting with Flutter 3.0.0 SDK, this is no longer required.
  
  JavaKotlin

  @Override
  public void configureFlutterEngine(@NonNull FlutterEngine flutterEngine) {
      super.configureFlutterEngine(flutterEngine);
      SyneriseMethodChannel.configureChannel(flutterEngine);
  }
  

  override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
      super.configureFlutterEngine(flutterEngine)
      SyneriseMethodChannel.configureChannel(flutterEngine)
  }
  

• React Native: use Synerise.Injector only inside Synerise.onReady(...). Before initialization finishes, the module is undefined. onReady keeps one callback (the last registration wins), so register in-app listeners once, at the application root.

Events generated by in-app messages

Interaction with in-app messages generates the following events. Based on these events, you can create analyses to measure the performance of in-app messages.

See In-app Mobile Campaigns section in the Event Reference.

In-app message status

The status of in-app messages is available on the list of in-app messages. In the Communication statuses article, you can check the statuses which can be assigned to in-app messages.