About In-App Automation

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 their 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 uses background push for reliable delivery 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 SequenceA series of messages that is initiated by a trigger. Airship sends messages in the series based on your timing settings, and you can also set conditions that determine its audience and continuation. Sequences can be connected to each other and to other messaging components to create continuous user experiences in a Journey. 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.

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.

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.

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.

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

Optional features

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

• Priority — Because multiple messages can become eligible for display at the same time, you can assign a priority value to each one. If no priority is assigned, by default, the most recently updated message will appear first. Priority is shared across in-app automation, ScenesMulti-screen experiences 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. Scenes can include survey questions or be presented as a story., and SurveysQuestion-and-answer experiences used to collect and aggregate feedback or generate a net promoter score. They 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..

• 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 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 — Override the project-level setting for how the message is handled when audience conditions are not fully met.

• Ignore Message LimitsLimits that cap the number of messages you can send within a specified time frame, preventing you from over-messaging your users. They are set at the project level. — Override the project-level limit for a single message.

• Campaign categories — Group messages of a similar type or messaging strategy for aggregate reporting.

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 a 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.

Default settings

You can set appearance and behavior defaults for in-app automation, including Color SetsA named pair of hexadecimal color values supporting device Light and Dark modes. Color sets can be selected for any color field in a scene and when configuring the default appearance of Surveys, Scenes, and In-app Automations. Dark mode is supported for Scenes only. and custom fonts. You can override the defaults in the Design step of the In-App Automation composer. See: In-App Experience Defaults.

Message limits

Message limits cap the number of messages you can send within a specified time frame, preventing you from over-messaging your users. They are set at the project level. The limit for In-App Automation, SurveysQuestion-and-answer experiences used to collect and aggregate feedback or generate a net promoter score. They 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., and ScenesMulti-screen experiences 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. Scenes can include survey questions or be presented as a story. are combined. See: Message Limits.