Last modified June 15, 2021 by Shelly Wolfe

Troubleshooting in-app messages

This article provides tips for troubleshooting common issues encountered with in-app messages.

Expected behavior

In-app messages are triggered by events. The in-app message workflow enables you to create an audience filter so that the message is only shown to a subset of users who trigger that event.

For iOS and Android, in-app messaging is automatically integrated after you complete the basic integration steps in the integration guide. For Unity an additional step is required, which is outlined in the Unity integration guide.

Testing in-app messages

If an in-app message is not behaving as expected, check the event logs on the QA User Logging screen.

To preview a campaign before launching, add your QA device to a campaign. For preview purposes, your QA device does not need to meet the audience filter. Note that it is only possible to preview one campaign at at time; the QA device is automatically removed from any other campaigns you were previously QA testing.

Swrve automatically sends an impression event of the form Swrve.Messages.Message-[id].impression when an in-app message is displayed, and a click event of the form Swrve.Messages.Message-[id].click when the user clicks a button that has an action other than Dismiss. Swrve uses these events to tracks how many users engaged with a particular in-app message campaign.

Advanced QA testing

Several trigger rules control when in-app messages are shown and when they are not. Each rule is configured in Swrve and then honored by Swrve’s SDK. When you combine rules it can be difficult to figure out why a message is not displaying during QA testing. The best way to see what rules are being used is to check the output of your app.

To check the output of your app for iOS devices, perform the following actions:

  1. Download the Apple Configurator from the App Store.
  2. Connect your device and view the console output.
  3. Start up the Apple Configurator, connect your device and select the Console tab of the utility.
  4. Start your app. The Console tab is now populated with data.
  5. Examine the console to identify data specific to in-app messages. For example:
    • Loading messages – you can identify which in-app messages the SDK downloaded by searching for campaign download success. This includes the full JSON (JavaScript Object Notation) of the message including rules and trigger points.
    • Message shown – search for sending view event, which is displayed each time a message is shown to users.
    • Message not shown – search for not showing message, which is displayed each time a message is not shown to users.

Common problems

Why are there multiple impressions for an in-app campaign?

Some reasons why the impression count may be higher than expected are:

  • Message limits – message limits are set at both app- and campaign-level. The most restrictive of the two apply. One purpose of message limits is to prevent a user from seeing a campaign more than a certain number of times per device. Check that the correct message limits have been applied for the desired behavior.
  • QA users behave differently:
    • If you are previewing an in-app message, then your QA device does not need to fulfill audience filter requirements. However, once the campaign is launched, your QA device needs to meet the audience requirements in order to see the campaign.
    • In-app messages are displayed an unlimited number of times on a QA device across all sessions, providing Reset Device State is enabled on the QA Devices screen.
    • For QA users, the campaign still follows the rules governing time after app start and time between impressions at the app- or campaign-level, depending which is more restrictive.
  • Swrve counts and stores amount of views on each device, so the same user installing on different devices will see the messages multiple times.
  • Older SDK versions – In SDK v4.2 there was an improvement to the campaign state of in-app messages so that it doesn’t get overwritten when campaigns are refreshed from the server. On older SDKs, jumping in and out of the audience for an in-app message would result in message limits being reset.

The in-app campaign is not showing on device

If the in-app message is not displayed as expected, first QA test it by adding your device as a QA user for the campaign. This bypasses the audience filter and maximum number of times the campaign can be shown, and ensures that the message can be displayed on the device.

Check the QA User Logging screen while testing. Logging information lets you know if there are throttling limits in place preventing the message from being shown.

Possible reasons for the issue are:

  • In-app message display rules – these are set at both app- and campaign-level and the most restrictive of the two applies.
  • Device orientation – in-app messages are set up by orientation so ensure images are added for both portrait and landscape.
  • Auto updating of campaigns disabled – by default Swrve downloads campaigns every 60 seconds. Check that this has not been turned off with the autoDownloadCampaignsAndResources setting on initializing the SDK.
  • Check if the campaign was downloaded to the device by looking at the QA User Logging screen. You should see a message that says, “Campaign XXXXX downloaded successfully.” To find the ID of the campaign, check the URL when viewing the campaign in Swrve. For example,[app_ID]/in_app_messages/12345.
  • Is there another in-app campaign launched with the same trigger and audience filter? Messages on the same trigger with the same message limits result in the higher priority message being shown first, until the message limits are reached. If they have the same priority then Swrve randomly chooses which one to display.
  • Is there another dialog hiding the in-app message? Are you initializing the SDK in one Activity, then showing another Activity on top? This could prevent the Session Start trigger from working.
  • Ensure that there is enough time to download the campaign to the device before the trigger event occurs in the app. Timing issues can prevent an in-app message from displaying as expected. Try to trigger the campaign on a QA device and watch the QA User Logging screen for the timing of the campaign download and trigger event. Try changing the trigger event, to see if the in-app message is displayed upon a different event.
  • Audiences filters are event-based – target audiences are not recalculated from scratch when the filters for campaigns are created or changed. Instead when a user is active (that is, sends any event), they are added or removed from segments. If the user has not been active, they may not qualify for the segment and may not download the correct campaigns.
  • In-app messages are disabled on low memory (Android only) – if the device is running low on memory, it isn’t able to load the large assets that are needed to show the in-app message. It may reach the heap limit and eventually crash.

Android – In-app message appears only for a split second

In-app messaging uses a dialog to display the message. If the parent activity is closed, the message disappears as well. This is different to how Conversations behave. Any event that fires on the close of an activity should be passed to the new activity first before firing.

Can a user see more than one in-app campaign at time?

A user can qualify to see multiple in-app messages. If the messages are triggered by different events, they should display without issue, but it depends on setting the message limits to allow a reasonable amount of time between messages. This is where the message settings ‘Time between messages’ comes into play. Whatever event the user triggers first takes priority. If multiple in-app messages are triggered by the same event and have the same priority, then the Swrve SDK randomly chooses which one to display.

Why is the engagement rate so low?

Swrve does not track engagement rate for buttons with no action or the Dismiss action. Ensure the message includes a button with either a deeplink or install action associated with it.

Check the QA User Logging screen for the impression and click events for the message action buttons, as explained in the Testing In-App Messages section above.

Why is the impression count so low?

The below points may help explain the impression count:

  • Check the in-app message display rules, both on an app- and campaign-level and remember that most restrictive of the two applies. It is possible that the user is only able to see the message once and has already seen it.
  • Check the audience filter for the in-app message. Is it too restrictive? Create a segment to review how many users are in the potential audience.
  • QA test your message to make sure it is displaying as expected and that the trigger event is firing – see section The In-App Campaign is not Showing on Device.