About In-App Automation

Set up messages that appear in your app when users meet certain conditions.

 Note

There are two variations of in-app messages:

TypeDisplay FormatDisplay TimingCreation MethodsComposers
StandardBannerUpon opening the app.
  • API
  • Dashboard
  • Message
  • A/B Test
  • Automation
  • Journey
In-App AutomationBanner, modal, fullscreen, Custom HTMLStored on the user’s device then displayed according to defined triggers.
  • Dashboard
  • In-App Automation

This document is for In-App Automation only. For standard in-app messages, see: In-App Messages.

In-app messages appear regardless of a user’s opt-in/out status for notifications. In-app automation refers to messages that are cached on users' devices and displayed when your users meet certain conditions within your app, such as viewing a particular screen or opening the app a certain number of times. While standard in-app messages appear as banners, in-app automation messages have various style and layout options.

In-app automation is designed to be highly contextual and displayed immediately in response to user behaviors, e.g., the user opens the app a specific number of times, views a specific screen, adds an item to the cart, makes a purchase, or views a video. Respond to user behaviors instantly with customizable messages, giving you precise control of the user experience. Benefits include:

  • Real-time display — In-app automation uses our on-device automation framework, which means they can respond to a series of events in real time (e.g., multiple game level changes, a sequence of screens, additions to a shopping cart) without round-trips to a server.

  • Guaranteed delivery — In-app automation is designed to use background push to reliably deliver in-app messages by sending a broadcast background push to all of your app users.

  • Dashboard management — Control all aspects of the message, including branding, using the Airship dashboard.

You cannot combine in-app automation with other channels or message types, however you can trigger a JourneyA series of messages that is initiated by a single automation trigger. Airship sends messages in the series based on your timing settings, and you can also set conditions that determine the continuation of the series. when a specific in-app automation displays for a user.

Use cases

  • Welcome messages — Communicate the value of your app and highlight key features.
  • Push and location opt-in prompts — Explain the value of your notifications to drive opt-in rates.
  • Feature education — Drive adoption of critical/new features that promote retention.
  • Onboarding messages — A series of messages educate users about the app over time.
  • App reviews — Prompt users to rate your app after positive experiences.
  • Registration/login — Drive registrations and logins to your loyalty program or account.
  • Profile enhancement — Promote the benefits of a completed profile, and provide a link to the relevant page in your app. Encourage your users to take a second to personalize their experience, and increase engagement and retention.
  • App updates — Send your users an in-app message highlighting your app’s newest features, or encourage users on older versions to update the app. If you just added a new page or have some new content, make sure to include a Deep Link so that they can find it quickly.
  • Ongoing promotions — If you have a promotion that users can take advantage of at any time — such as a discount for inviting a friend or for taking a survey — an in-app message serves as a convenient reminder.

These use cases are also true for standard in-app messages, however, using in-app automation, you can trigger your message to display based on specific scenarios. For example:

  • Display a “Welcome” message when users first open your app.
  • Display a “Tip” message when a new feature is added to your app.
  • Ask a user to rate your app after they have opened it for the 6th time.

These experiences are typically hard-coded by app developers and cannot be updated without custom development and app store updates. With in-app automation, you create and update these in the Airship dashboard, without custom development.

Appearance and behavior

Multiple message styles (banner, modal, fullscreen, and custom HTML) are supported, as well as various layouts for each style.

You will configure the message content based on the requirements for your selected style and layout:

  • Text — May include header and message body fields.

  • Media — See: Media guidelines.

  • Buttons — Different styles support a different number of buttons, and you will associate an action for each. If more than one button is added, you may choose a button layout: Separate, Joined, or Stacked.

 Tip

For accounts that include Personalization features, if you select modal or fullscreen as the message style, you also have the options to use a TemplateReusable message content that saves you the trouble of having to rewrite a message. Templates support merge fields and other logic, letting you personalize the resulting messages. , provide your own HTML, or design using the WYSIWYG editor. See: Create an in-app automation: Template and Interactive Editor.

In-app messages are loaded on the user’s device upon receipt of a background push. When background push is disabled for your project, or for users opted out of background app refresh, our SDK downloads and refreshes the entire message list upon next app open. Up to 50 messages can be pre-loaded onto the device at a time.

In-app automation is not PersistentMessage content that remains available even if the alerts for the message are dismissed. For example, Message Center, email, and SMS content can be viewed in the app’s Message Center, email inbox, or the device’s native SMS client until the message is deleted by its recipient. Non-persistent message types become unavailable when users dismiss them. A message’s linked content, e.g., a web link, deep link, an Apple News story, remains available as determined by the source host. , and display duration varies by message style:

  • Modal and fullscreen messages appear on screen until the user interacts with them, either by clicking one of the main buttons or dismissing the message.

  • Banner messages disappear automatically after 15 seconds but will disappear sooner if the user clicks any button or dismisses the message.

In addition to configuring when the message will display, you can set optional features:

  • Priority — Because multiple messages can become eligible for display at the same time, you can assign a priority to each message. If no priority is assigned, by default, the most recently updated message will appear first.

  • Repeat — To prevent over-messaging, our SDK waits 30 seconds after one message is closed before displaying the next eligible message. This delay value can be updated through native code. You may also control the number of times an individual message is displayed and the minimum waiting period before it is eligible for redisplay. Redisplaying your message is useful because users can dismiss or ignore your messages.

  • Start and end dates — Set the dates and times during which your message can be displayed. Specifying a window of time is useful for messages that are time-bound or tied to scheduled events.

  • Missed behavior — Specify how the message is handled when audience conditions are not fully met.

Styles

There are four styles: Banner, Modal, Fullscreen, and Custom HTML.

Banner

Banner messages appear at the top or bottom of your screen, sliding up from the bottom of the screen, or down from the top. They are designed to be less obtrusive to users than modal or fullscreen messages, by taking only a portion of the screen and not fully interrupting the user from their current task. Example uses include informational messages, news alerts, or promotions that do not deserve a full user interruption.

Banner message elements:

  • Header — An optional headline for the message. Bolded by default to stand out from the message text.
  • Image — A small thumbnail image that appears on the right or left side of the message.
  • Text — The main text of the message.
  • Buttons — Display up to two buttons, allowing a user to respond to the message.
  • Dismiss — Ability to dismiss the message by swiping it back in the direction it came from.

Modal

A modal message takes over the user’s screen, compelling the user to interact with it. Modals are typically used to prompt users to reply to a question or make a quick decision. The message window is smaller than the full width of the screen, superimposed on the app with a translucent background, assuring the user that the interruption is temporary.

Modal message elements:

  • Header — An optional headline for the message. Bolded by default to stand out from the message text.
  • Image — A large image embedded in the message.
  • Text — The main text of the message.
  • Buttons — Display up to two buttons, allowing a user to respond to the message.
  • Dismiss — Ability to dismiss the message by clicking the X button.
 Tip

You can make a modal message display as fullscreen on small screen devices. Use this setting if you want your message to take over the entire screen on a phone but display as a modal on a tablet. See: Display fullscreen on small screen devices in In-App Automation Defaults.

Fullscreen

Fullscreen messages are similar to modal messages but take over the entire screen, providing more real estate for your message.

Fullscreen message elements:

  • Header — An optional headline for the message. Bolded by default to stand out from the message text.
  • Image — A large image embedded in the message.
  • Video — Can be displayed instead of an image.
  • Text — The main text of the message.
  • Buttons — Display up to five buttons, allowing a user to respond to your message.
  • Dismiss — Ability to dismiss the message by clicking the X button.
  • Footer — A text link to content, e.g., Terms & Conditions, relevant to the message.

Custom HTML

Custom HTML messages have the same appearance as modal messages and also have the same message elements. The appearance of custom HTML messages is determined by your provided code.

General guidelines:

  • Set your layout, content text, media, buttons, and any actions you want to trigger.

  • Since much of the message’s content and behavior are defined in your HTML, the settings and options available in the composer are reduced to only those applicable to the custom HTML message style.

  • Any images, CSS, and applicable scripts referenced in your HTML should be made available via a CDN or publicly available repository. You cannot upload additional files using the composer.

 Tip

You can make a custom HTML message display as fullscreen on small screen devices. Use this setting if you want your message to take over the entire screen on a phone but display as a modal on a tablet. See: Display fullscreen on small screen devices in In-App Automation Defaults.

Layouts

Available layouts per style:

  • Banner — Left or right image orientation, or a text-only banner.
  • Modal — Media at the top, middle, or bottom of the message, or text-only.
  • Fullscreen — Media at the top, middle, or bottom of the message, or text-only option

Message status

A message created using in-app automation is either Active, Expired, Canceled, or Pending. When you first create an in-app automated message, it is Active. It remains active until either:

  1. It expires according to its end date.

    OR

  2. You stop it. Stopped messages are considered canceled.

  • Active messages can be edited or canceled at any time.
  • An Expired or Canceled message can be edited and its end date extended, making it active again, within a grace period of 14 days. After 14 days they can only be duplicated.

Recently created or edited messages have the status Pending for a few seconds, until it completes processing and becomes Active.

See: Change status.

Background push

Background push invokes any typical background actions your app takes when it is woken. For some apps this behavior can be too much to handle. Because of this, background push is disabled by default for use with in-app automation.

If you are confident with you app’s ability to handle a larger number of background push notifications, for best results, we highly recommend enabling background push for in-app automation. Without the use of background push, your app will not receive necessary updates of in-app messages until the next time the app is opened.

Here are some examples of what can happen if background push is not enabled:

  • New messages may not be available on the device before the user generates the event that triggers the message display.

  • Updates to or cancellations of in-app messages may not get applied in time, so your app may display the wrong version of your message or display a message that should not have been displayed.

  • Attempts to restore in-app messages may not work if the app is not opened by the user within the editing grace period (14 days), as the device only stores a message for 14 days.

Please note that while background push is not guaranteed to solve all of the issues above, it does give the SDK the best opportunity to update the message list before the app is open, making it more likely that your user sees the correct message.

Enable background push in your project settings.

Design defaults

You can set in-app automation appearance and behavior defaults in your project settings.