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 available 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 criteria. 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.

---

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 active, 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 if the same user installs the app on different devices, they 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 displaying 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, https://dashboard.swrve.com/apps/[app_ID]/in_app_messages/12345.
• Is there another in-app campaign launched with the same trigger and audience filter? Messages using the same trigger and 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 in Android 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, so the activity doesn't immediately close alongside the Swrve message.

This is most likely to occur on campaigns set to show on launch of the app, as the Swrve SDK tries to hook onto the first activity available, but this could be a loading page removed from the stack quickly. In this scenario, Swrve recommends to send an event when the app has finished loading, like 'Home.Page' or 'Loading.Complete'.

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 click-through rate so low?

Swrve does not track click-through 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.

6.0+ Swrve SDKs do allow a dismiss button callback to be triggered. This must be setup by following the Swrve SDK integration guides.

Check the QA User Logging screen for the impression and click events for the message action buttons, as explained in Testing in-app messages above.

When using the QA logging screen, ensure you're on a production version of the app that you expect the in-app message to behave correctly in.

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 The in-app campaign is not showing on device above.
• Make sure you're triggering the event on the QA logging page! Sometimes events are accidentally removed by the app development team, and an event previously expected to be sent frequently is no longer triggering, or only triggering in specific circumstances. For example old app versions could be triggering the event, and new versions might not.