Swrve FAQs

This articleprovides tips for troubleshooting common issues encountered with conversations campaigns.

What you'll see:

Expected Behavior

Testing Conversations

Conversation Impressions

Campaign Display

Displaying Multiple Conversations

Low Impression Count

Video Loading Issues

Launch Button Inactive

Android Dismiss Buttons

Number Of Pages Counts

Expected behavior

Conversations are triggered by events. The conversation workflow enables you to create and deliver interactive in-app messages using any combination of text, images, video, surveys, or rich button actions. This flexible in-app campaign channel comes with a default set of customizable templates for the most common scenarios and it uses an audience filter so that the message is only shown to a subset of users who trigger that event.

Conversations are automatically integrated after you complete the basic integration steps in the integration guide.

Testing Conversations

If conversations are 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 a time and the QA device is automatically removed from any other campaigns you were previously QA testing.

Swrve automatically sends an impression event in the form of Swrve.Conversations.Conversation-[id].impression when a conversation is displayed, and a click event of the form Swrve.Conversations.Conversation-[id].done when the conversation is Dismissed. There are additional events that conversations send through depending upon the template you have been using. Swrve uses these events to track how many users engaged with a particular conversations message campaign.

Why are there multiple impressions for Conversations?

Some reasons whythe impression count may be higher than expected include:

Message limits message limits are set at both app and campaign-level. The most restrictive of the two applies. 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 conversations, 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.

Conversations are displayed an unlimited number of times on a QA device across all sessions, providedReset 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 the number of views on each device, so the same user installing on different devices will see the messages multiple times

The Conversation campaign is not showingon a device

If the conversations are 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 a 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 screenwhile 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:

Conversation display rules these are set at both app and campaign-level; the most restrictive of the two applies.

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_messagesconversation_campaigns/12345.

Is there another 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 conversations? 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 conversations 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 conversation 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.

Conversations are disabled on low memory (Android only) if the device is running low on memory, itisn'table to load the large assets that are needed to show the in-app message. It may reach the heap limit and eventually crash.

Can a user see more than one conversations at a time?

A user can qualify to see multiple conversations. If the messages aretriggered bydifferent events, they shoulddisplaywithout issue, but it depends on setting the message limits to allowa reasonable amount of time between messages. This is where the message settings Time between messages comes into play. Whatever eventthe user triggersfirst takes priority. If multiple conversations are triggered by the same event and have the same priority, then the Swrve SDK randomly chooses which one to display.

Why is theimpression count so low?

The below points may help explain the impression count:

Check the conversations display rules, both on 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 conversations. 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 Conversations Campaign is not Showing on Device.

Why video is not loading for Conversation?

If conversations are not displaying video please check that the link included in the campaign is a Youtube Embed URL. For example "https://www.youtube.com/embed/XIplu-ZSNGA" Swrve does not support video link from any other platforms.

Launch button is not active

If after crafting the Conversation campaign you try to launch the campaign yet the Launch Button is not active please go back to the conversation templet and check you might be missing one or more required values.

Dismiss button is not displayed for Conversations on Android Devices

On Android, there is no extra dismiss button displayed for conversations and the best practice is to let the user use the "Back" button to dismiss.

We are following Android navigation guidelines by not including a close button in conversations on Android.

The guidelines can be found here: https://developer.android.com/design/patterns/navigation.html. Specifically, the Pop-up Notifications section dictates that you should make all pop-ups dismissable by the back button to ensure the user experience across all apps is consistent.

Number of pages counts for multi-page conversation

For multiple page conversations message, Number of page views will not add up the number of conversations that were finished/completed. It will be marked completed or finished only if the user will go through all the pages as the user can leave the app or conversation in the middle without completing it.

Email subject display as SomeSubject

If the email is missing the subject that you set on your templet and insteadshowing up as SomeSubject, pleasefollow steps below.

1: Login to your SendGrid account.

2: Click on Templates button to select your email template.

3: Select your email template, Click on Setting button and then edit.

4: Click on the setting button.

5: Add your subject in Email Subject filed instead of SomeSubject and click on save.

Review this article to identify causes for revenue disparity between Swrve and other services. You can identify many causes for revenue differences by comparing the details in the Swrve service with the revenue totals seen in your mobile app store.

You can investigate many revenue differences by reviewing the data received for a specific device. Add your device as a QA device and make a purchase. The item purchased andall purchase details should be displayed onthe QA User Loggingscreen.

Buy In events

Buy_in events have been deprecated since mid-2013. If your app is still sending buy_in events, be sure to update to a more recent Swrve SDK that can leverage Swrves IAP event with receipt verification.

Buy_in eventsdon'thave receipt verification as the purchase receipt is not a parameter sent to Swrve. This means that Swrve is essentially a bean counter for revenue, with no validation on in-app purchases. If revenue is much higher than what is accounted for in iTunes Connect or Google Play, this could mean users are having their invalid or cheater purchases counted in Swrve. If server-side receipt verification is in place, and revenue is still high, you may want to double-check that purchases are not being sent multiple times from your server.

Recommendations

Instrument the IAP event with receipt verification to stop Swrve from receiving false revenue. For more information, see the platform-specific integration guide.

If a server-side implementation is in place, establish receipt verification before sending Swrve revenue, or send receipts with an IAP event.

If youre unsure whether your app is sending buy_in events to Swrve, on the Analyticsmenu, selectEvents. In the Event Name column, selectSwrve and either IAP or buy_in events or both should display. If there are many buy_in events, this revenue cannot be trusted unless your team has instrumented server-side receipt validation before sending the buy_in event to Swrve.

No receipts or incorrect receipts

Another sure sign of revenue issues is if only valid_iap events display on the Eventsreport underSwrve. Typically, an invalid_iap event is sent to Swrve when an IAP event is sent for a fake purchase. Swrve marks a purchase as invalid when there is an invalid receipt received. However, similar to the buy_inevent, if Swrve doesnt receive the receipt as a parameter for this event, all revenue for IAP events is counted inKPI reports.

Incorrect receipts can also cause a rejection of the purchase. On recent iOS versions, the receipt is expected to be the transaction receipt from SKPaymentTransaction, which isbase64 encoded.

On Google, the parameters receipt and receipt_signature are expected. These parametersare returned in the intent fromGoogle in IN_APP_PURCHASE_DATA and INAPP_DATA_SIGNATURE respectively. An example Google receipt is given below:

"receipt": "{"orderId":"GPA.xxxx-xxxx-xxxx-xxxx", "packageName":"com.test.packagename", "productId":"product-id", "purchaseTime":1448276750398, "purchaseState":0, "developerPayload":"extra", "purchaseToken":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}",

Ensure that your team instruments the IAP event with the receipt from Apple or Google. For more information, see the platform-specific integration guide.

A common mistake is to encode the Googlereceiptit is expected in JSON format.

When inspecting the purchase onthe QA User Loggingscreen, ensure it was notmadethrough UNKNOWN_STORE. If it was, this indicates that purchases are being sent using the unvalidated iap()method rather than the iapPlay() method. These purchases would automatically be counted as valid. We do not recommend sending unvalidated IAPevents unless you have already checked the purchase on your side.

[email protected]

IAP versus purchase events

A common mistake is to send purchase events instead of IAPevents. Ensure that you are sending the correct type of event for the purchase.

IAP events sales for real money

If your app has in-app purchases, send theIAPevent when a user purchases something with real money, such as virtual currency bundles for a game, virtual items or unlocked functionality.Sending IAP events populates the Top Items report, Item Chartsreport and revenue KPIs in the Trend reportsand on the KPI Metrics dashboard.

Purchase events sales for virtual currency

If your app has a virtual economy, send thepurchaseevent when a user purchasesin-app items with virtual currency, such as gold, coins or gems. Sending purchase events populates the Top Items and Item Charts reports. These are useful for quickly identifying which items are selling across your inventory. When instrumenting purchase information, specify one of your in-app currencies in the currency parameter.

Virtual currencies

A virtual currency must be added inSwrve before receiving IAP purchases for it. Add currencies on the App Settings screen, in the App Currencies section. You need to add these currencies to both your sandbox and production dashboards.

View the devicelogs on the QA User Loggingscreen while making a purchase. If IAP events are displayedon the QA User Logging screen, Swrve has successfully received the IAP event. To see the details of the purchase, select Show Raw Eventunder the IAP event .

Google Server key and iTunes bundle ID

When validating revenue, Swrve uses the Google Server Key and iTunes Bundle ID toverify revenue. Check that these arecorrect for the app onthe Integration Settingsscreen.

Exchange rates

Exchange rates between platforms can be updated at different times. Swrve updates these exchange rates periodically, but this interval can be different between platforms.

Exchange rates can account for 1-5% differences in total revenue at any time, but if differences are more drastic, consider alternative causes.

Apples to apples

If youre comparing net revenue from Apple or Google, ensure that the correct multiplier is set in Swrves reporting settings. For Apple and Google app stores, net revenue is 0.7x. Therefore, the multiplier set in Swrve must be 0.7 for revenue charts to display net revenue. Otherwise, you are comparing gross revenue to Swrves revenue numbers. For more information about configuring the reporting multiplier, see How do I configure how revenue is reported?

Units sold

While revenue can be too high due to cheater purchases, it can also be too low if the correct purchase details are not sent to Swrve. For example, if the amount of item purchases displayed in the Top Itemsreport doesnt add up to what youre seeing in Units Sold in your app store, Swrve may not be receiving all of the purchases. Review the Top Items report forincorrect quantities being sent.

In many circumstances this is due to one or more of the following:

An app version into which Swrve is not integrated. On the Analyticsmenu, selectUser attributesand select the App version user attribute to see which versions have been received by Swrve.

The app is not sending purchase events for all purchases that have been made.

The app or server is sending duplicate IAPevents to Swrve.

The server is not sending the purchase event to Swrve. In some instances, the purchase event is simply not sent to Swrve either from the client or a server. On the Eventsreport, under Swrve, examine the IAP event to make sure Swrve is receiving traffic for this event.

Incorrect IAP event parameters. Review the parameters of the IAP event in the Events API documentation. Have your development team review logs and use the built-in QA functionality to see the parameters being sent and received.

General event or URL errors. All apps using the Swrve SDKs use the batch event, reducing network requests and traffic by combining many events into one request. If there is an error in any event parameter, however, the batch of events isrejected by Swrve. This rejected batch can sometimes include IAP events. Examine your error logs to see any rejected batch requests, or 404 errors for incorrect URLs (correct URLS are detailed in the Events API guide ).

Compare units sold on theTop Itemsreport on a daily basis. If the units sold match, but the revenue does not, the prices being sent to Swrve are incorrect. If the amount of a particular item is very low, investigate buying this item by reviewing the QA User Loggingscreen while making a purchase of this item. An IAP event should be displayed when the item is bought. If not, this purchase is not properly instrumented.

If the units sold in Swrve are higher than in iTunes Connect, Swrve is receiving false revenue. Review the platform-specific integration guide for information on removing cheater revenue.

Total revenue over time

It can be useful to examine revenue figures over a longer period of time. Review the total revenue over time by downloading a weeks worth of revenue by means of a Trendreport. Is the revenue now closer to that displayed in iTunes Connect or Google Console?

To track down revenue disparities you can also investigate:

Returns for Google Play and iTunes. For example, Apples Summary Sales Report includes returns in its totals. Swrve does not receive return data. Apple states the recommended refund rate should not exceed 0.1% of sales. For many apps this number is much higher.

Date of payment processed. For Swrve, this is the exact day/time of occurrence. App stores can even include this revenue on different days.

Consider what factors changed around that time period. Was a new app version released? Was the app launched in a new market? Check with Swrve that a new currency is supported.

Minor calculation differences on purchase events sent to Swrve, such as currency exchange and rounding.

Taking the above points into consideration (and recognizing the amount of real units sold on a daily, weekly, or monthly basis) can help narrow down the chief cause of the revenue disparity.

Swrve datais based on the timezone thatwas set in the dashboard. The timezonemay differ fromother revenue sources.

Subscription revenue

If subscriptions are a primary revenue source, these weekly, monthly or annual subscriptions should be checked regularly and IAP events should be sent to Swrve when the user renews their subscription. Without this, revenue would be low due to missing subscriber revenue. If revenue looks accurate early on, but becomes inaccurate without any app updates, talk to your development team to make sure this situation is properly handled.

Conclusion

If you still have questions after reviewing the above details in your app, please contact .

To perform a thorough investigation of the issue, Swrves support team needs to know:

If the issue relates to a particular product.

The exact dates that are affected.

The trueunits sold for that specific time period.

This articleprovides tips for troubleshooting common issues encountered with push notifications.

Expected behaviour

When auser opens the app from a push notification, Swrve automatically sends a push engagement event. It is important that Swrvereceives this engagement event to accurately track how many users have engaged with a particular notification. Swrveneeds to receive the push engaged event in the following scenarios:

When the app is completely closed, that is, swiped away from the list of open apps.

When the app is in the background, that is, still running but inactive.

To check that the push engaged event wasreceived, reviewtheQA User Loggingscreen whensending a test push.

Note that if you send more than onetestpush whilethe app is open in the same session, you will only see the push engaged event for the first push. This is by design, to prevent engagement being tracked more than once for identical push notifications in the same session.

Push Notificationsdebugging

The best way to debug Push Notifications is to send a transaction push message to one of the QA devices from the command line.

Here is a link to the documentation on our transactional push API: https://docs.swrve.com/user-documentation/push-notifications/creating-push-campaigns/transactional-push-api/

Once the transactional push API campaign has been set up in the dashboard, then open a terminal window and copy our CURL request from the dashboard.

Note: Remember to start with a new QA device, or you might be trying to send to an old install of the app, or worse, another user!

Common issues

Unable to send a test push to QA device

Swrve enables you tosend a test push notification via theIntegration Settingsscreen, under theSettingsmenu. If your device is not available to select from theSelect QA devicelist, then a push token has not been received for that QA device.

Ensure that you have followed the complete instructions fromone of the below articles to set up the server key for Google or the push certificate for Apple:

How do I manage the Android Server Key for push notifications?

How do I manage iOS push certificates for push notifications?

Check that you have enabled push in the Swrve SDK. We provide example code for both Google and iOS in our platform-specific integration guides.

Check that Swrve has received the push token:

Under theSettingsmenu, go to theQA Devicesscreen and check if push has been enabled for the device. Under theSettingscolumn, a green checkmark should be displayed next toApple Push enabledorGoogle Push enabled.

On theQA Devicesscreen, in the row for the selected device, selectLoggingto view theQA User Loggingscreen(ensure you have the correct QA device). Inspect the Raw JSON for the User event that is sentwhen the app is opened and look forthe swrve.gcm_token for Google or swrve.ios_token for Apple.

Remote/Silent Push | Expected Behaviour

To understand, when sending remote push notifications to a device, the expected behaviour of the device when the respective app is in different states; and the differences between the iOS and Google/Android environments.

Push types:

Remote notification (visual)

Silent notification (data)

App states:

In foreground

In background

Hard-closed

Force-stopped (Android only)

Platform Type

foreground

background

hard-closed

Force Stopped (android)

iOS Visual

NO

YES

YES

N/A

iOS Data

YES

YES

NO

N/A

Android Visual

YES

YES

YES

NO

Android Data

YES

YES

YES

NO

Push permission properties

There are 2 separate user properties used to track push permissions. One for iOS and one for Android.

iOS

user property: swrve.permission.ios.push_notifications

Possible values:

- authorized - user has accepted push permission

- denied - user has denied push permission

- unknown - user has not yet been asked for push permission

Android

user property: swrve.permission.notifications_enabled

Possible values:

- true - default value when user installs the app.

- false - user has changed push permissions in the app settings to disable them.

Push server delay

There is up to 6 hours delay before a new user will receive a live push. This potential delay is because the Swrve Push system uses a backup of the user_db to build the audiences for push.

So essentially the Swrve push servers updates 4 times a day, if a new user misses any of these windows they will not be grouped into the campaign.

Unable to receive a test push

Android

The following are some reasons this issue occurs:

Incorrect server key or push certificate Check that the server key or push certificatedetails are correct, and that you have a push token associated with your QA device by hovering the mouse over the green checkmarkon theQA Devicesscreen.

Using another push service Is another push service trying to display the message? If you have another push service running, for Android you need to make an additional change to the Manifest. For more information, see the headingUsing Swrve Push Notifications with other providersin the Android integration guide.

Issue processingthe intent To debug the handling of the intent, you can examineadb logcatfor errors. Check that the device is receiving the FCM message and if the broadcast receiver is being called.

iOS

There are some additional points to consider for iOS:

On iOS, push notifications are not shown on the device whenthe app is active. Try again when the app is completely closed or in the background.

A common issue is to upload the wrong certificate. There may be a mismatch between development and production, or the wrong certification may be uploaded. We require a valid .p12 file matching the environment to be uploaded. Anadhoc or production build requires a production certificate.

Not agreeing to the push dialog when the push request appears on the device.

Not having the 'Allow Notifications' enabled in your Build Settings (Xcode). See image below.

https://docs.swrve.com/faqs/push-notifications-faq/manage-ios-push-certificates-for-push-notifications/

Not having the 'Remote Notifications' enabled in your Build Settings (Xcode). See image below.

The app is not calling the push listener

Android

For Android, ensure the following point has been addressed:

Ensureyou made the changes in the Android manifest that are listed in the Android integration guide.

Cannot see push engagement event duringQA

When the user taps a push notification, an engagement event is sent. Theengagement event is displayed on thetheQA User Loggingscreen for your device. The event looks likeSwrve.Messages.Push-0.engaged. If youdon'tsee this event, the engagement reporting in Swrve will not work.

In older iOS Swrve SDK versions, code is required for both scenarios of when the app is running in the background and when it is completely closed. Ensure you have these code lines, or upgrade the SDK.

The Swrve SDK checks the last push notification received to compare against the notification the user has tapped. If this ID is the same, the push engagement event does not fire. This is particularly important in QA, as test pushes have the same ID (0). If youre testing push notifications, close the app entirely and then send the test push. Next,test by closing the app, opening as normal, runningthe app in the background and sending another test push, to ensure the push engagement event is shown on theQA User Loggingscreen.

The device cannot receive a live push

Bear in mind the following points related to live push campaigns:

It can take a few hours from Swrve receiving the push token from the device to being able to send a livepush notification, since our userDBs are updated throughout the day. Try sending a test pushin the meantime as this is available immediately.

If the app is uninstalled and reinstalled, the push token changes. If you have reinstalled the app, you mayneed to wait a few hours before being able to send a real push notification.

The device needs to have an internet connection to receive a push notification. Whether or not and how long a message is queued for depends on Apple and Googles push services. Ultimately Swrve cannot guarantee that a device will receive the push once it has been delivered to Apples APNS or Googles FCM.

Android

For more details on the Firebase Cloud Messaging (FCM) service, see the Firebase Cloud Messaging guide.

iOS

Generally, iOS sees lower engagement rates than Android. Some common reasons for not receiving live pushes on Apple devices are:

Uploading the wrong type of push certificate.

Push notifications are not shown on the device when the app is active.

There are some device factors that prevent push notifications from being received, including the device being face down, in quiet mode, and so forth. Check that your device is configured to receive push notifications and they have not been disabled.

According to Apple documentation, APNS will queue up to one message if it was unable to deliver it; for example, if the device was offline. If any subsequent messages are sent, the previous messages are discarded. Check that your device is online when the push notification goes out.

For more information, see the Apple Push Notification Service guide.

Push notifications are already used in theapp

Android

You will need to make an additional change to the Manifest to ensure that your other push providers continue to work. For more information, see the Android integration guide.

Duplicate push notifications

If another push service is being used with Swrve, it could be trying to display the message. Refer to above section.

On Android this usually means that there's more than one 3rd party push provider trying to consume the push notification. Follow our guide for 'Already using push notifications'

Also, remember that Android has a much larger offline queue of notifications than iOS (just 1 as of 2019). This means if the device has been offline for awhile there's a good chance multiple notifications stored by google will be downloaded to the device right then and there.

I want to register the push token myself

iOS

By default, Swrve automatically registers the device token and triggers the push permission dialog. Swrve does this by swizzling the following methods that handle token registration:

didRegisterForRemoteNotificationsWithDeviceToken

didReceiveRemoteNotifications

didFailToRegisterForRemoteNotificationsWithError

If you want to handle registering the tokens and requesting permission yourself, you need to setconfig.autoCollectDeviceTokentoNO. This prevents Swrve from swizzling the above methods. Note that it is necessary to include both of the following code snippets:

- (BOOL) application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

SwrveConfig* config = [[SwrveConfig alloc] init];

config.pushEnabled = YES;

config.autoCollectDeviceToken = NO;

[SwrveSDK sharedInstanceWithAppID:<app_id> apiKey:@"<api_key>" config:config launchOptions:launchOptions];

}

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {

if ([SwrveSDK messaging] != nil) {

[[SwrveSDK messaging] setDeviceToken:deviceToken];

}

}

The push icon is blank on Android M

The Android SDK includes metadata configurations for remote notifications so they can be configured properly for Android L+.

For Android 6.0 you will need to also set the SWRVE_PUSH_ICON_LARGE. If you are using the latest version of our SDK (4.1+), you need to add the following three new pieces of metadata to the android manifest file:

<meta-data android:name="SWRVE_PUSH_ICON"

android:resource="@drawable/ic_launcher"/>

<meta-data android:name="SWRVE_PUSH_ICON_MATERIAL"

android:resource="@drawable/ic_launcher_material"/>

<meta-data android:name="SWRVE_PUSH_ICON_LARGE"

android:resource="@drawable/ic_launcher_large" />

Does the push look strange, or if no image is shown when expected

Be sure to follow the steps of integration for rich push. On Android this is often caused by another push service consuming the push, as a test remove the other 3rd party push service from your manifest and re-build the app to see if this behaves the same way.

Follow the Swrve integration guide for 'Already using Push Notifications' so both tools will work correctly.

On iOS, this may mean the notification service extension wasn't properly setup.

Follow those steps in our iOS integration guide to ensure rich pushes appear correctly.

The device can receive push notifications, but there arenoengaged users

Are you sending the same push more than once during a session? Only the first one triggers a push engaged event, since Swrve doesnt count engagement for duplicate pushes within a session. Try restarting the app in between tests.

Are you using the most recent Swrve SDK? We recommend upgrading when possible to the latest SDK release, to keep up to date with bug fixes and features. For iOS in particular, push handling is simplified from SDK 4.1. We update the SDK to keep up-to-date with platform changes.

Its also possible that users have uninstalled the app.

Why is thepush campaign targeting zero devices?

It can take a few hours after Swrve receives a push token for a devicebefore Swrve can send live pushes to this user. This is because the push service takes the push token from the user DBs, which are updated throughout the day. The QA user test pushes override this behaviour and are available immediately.

Confirm that the audience filters are correct; User properties may not be being sent exactly as you expect for example, Targeting 'Platform = Apple' instead of 'Platform = iOS'.

The push was sent to less users than the campaign targeted

If the campaign details report shows that a number ofusers were targeted, but the push was sent to a smaller groupof users, then the remaining users may have uninstalled the app.

Push engagement stats are too low

When a push campaign has been sent, you can view the Campaign Details page, which displays the following information:

How many devices were targeted for the push.

How many devices were not sent pushes due to the absence of a required user property, where no default value was specified.

How many push notifications were sent.

When the last push was sent.

How many push notifications failed to send.

How many batches failed.

How many push notifications Google or Android rejected immediately.

Apple and Google change how they deal with push tokens, so it is vital to keep up to date with the latest Swrve SDKs.

Android

Google may reject push notifications for the following reasons:

Mismatch of Sender ID Check the server key that has been uploaded on the Integrations Settings page, as it likely does not match the Sender ID/tokens being generated.

Invalid Token The user may have uninstalled the app. Once you have uninstalled the app and reinstalled, you should hard-close the app and then reopen it to send the token to the dashboard. The device should now have a valid token, but it cannot be targeted for push notification campaigns until the next day.

Rejected or Deprecated Token. Google push will stop working with old tokens once a new version is uploaded to the play store. The push notifications plugin has been updated to the latest FCM library in Swrve SDK version 4.0.2 and above. This allows us to retrieve the correct token type returned from FCM. This leverages the new app instance ID for generating security tokens like for FCM. This updated API is required to handle token refreshes that happen.

iOS

Apple may reject a push notification for the following reasons:

Mismatch of push certificates A development certificate only works for debug builds, so we typically suggest that you should upload a p12 file of the production APNS certificate to our dashboard. The issue may stem from a mismatch between the certificate on our dashboard and the APNS service.

For Apple information on troubleshooting push notifications, see their article on Troubleshooting Push Notifications.

Older versions of the SDK required two code paths to be implemented to handle the scenarios app completely closed and app in background. Make sure you have included both code sections, or upgrade to the latest SDK.

Push certificate renewal

Essentially the push certificate have to be updated every year in the Apple dev center. It doesn't require an app update.

A new push certificate must be generated at developer.apple.com - this would typically be handled by your iOS developers.

Once you have a new certificate, then you should upload that to the Swrve dashboard on the Setup > Integration Settings page, by someone who is a Company Admin.

We have this content here:

Please note: Each app requires its own push certificate. The Apple push certificates are based on the bundle id of the app - so each app needs to have its push cert updated once a year.

Swrve will notify you 28 days before any certificate is due to expire, so you will always have some notice.

These alerts are automated for each app, to be sent when an app's push certificate is due to expire in: 28 days, 14, days, 7 days, 3 days, 1 day, and finally the day they expire. These will be sent to all Company Admins, and to the assigned "Lead Developer" of the app in the Swrve dashboard.

This articleprovides 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 tocreate 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 afteryou complete the basic integration steps in the integration guide. For Unity an additional step is required, which is outlined inthe Unity integration guide.

Testing in-app messages

If anin-app message is not behaving as expected, check the event logs on theQA User Loggingscreen.

To preview a campaign before launching, add your QA device to a campaign. For preview purposes, your QA device doesnot need to meet the audience filter. Note that it is only possible topreviewone 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 formSwrve.Messages.Message-[id].impressionwhen an in-app message is displayed, and a click event of the formSwrve.Messages.Message-[id].clickwhen 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 whythe impression count may be higher than expected are:

Message limits message limits are set atboth app- and campaign-level. The most restrictive of the two apply. One purpose of message limits isto prevent a user from seeing a campaign more than a certain number of times per device. Check that the correctmessage 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, providingReset Device Stateis enabled on theQA Devicesscreen.

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 animprovement to the campaign state of in-app messages so that it doesnt 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.

Thein-app campaign is not showingon device

If the in-app message is not displayedas 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 campaigncan be shown,and ensuresthat the message canbe displayed on thedevice.

Check theQA User Loggingscreenwhile 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 atboth app- and campaign-levelandthe most restrictive of the two applies.

Device orientation in-app messages are set up by orientationso ensureimages are added forboth portrait and landscape.

Auto updating of campaigns disabled by default Swrve downloads campaigns every 60 seconds. Check that this has not been turnedoff with theautoDownloadCampaignsAndResourcessetting on initializing the SDK.

Check if the campaign was downloaded to the device by looking at theQA User Loggingscreen. You should see a message that says, Campaign XXXXX downloaded successfully. Tofind the IDof thecampaign, 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 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 thenSwrve 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 Starttrigger fromworking.

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 theQA User Loggingscreen for the timing of the campaign download and trigger event.Try changing the trigger event, to see if the in-app message isdisplayed upon a different event.

Audiences filters are event-based targetaudiences 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 thesegment and may not download the correct campaigns.

In-app messages are disabled onlow memory (Android only) if the device is running low on memory, itisn'table 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 themessage. 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 campaignat time?

A user can qualify to see multiple in-app messages. If the messages aretriggered bydifferent events, they shoulddisplaywithout issue, but it depends on setting the message limits to allowa reasonable amount of time between messages. This is where the message settings Time between messages comes into play. Whatever eventthe user triggersfirst 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 theclick-through rate so low?

Swrve does not track click-through rate for buttons with no action or the Dismiss action. Ensure the message includesa 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 theQA User Loggingscreen forthe impression and click events for the message action buttons, as explained in theTesting In-App Messagessection above.

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

Why is theimpression 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 sectionThe In-App Campaign is not Showing on Device.

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.

Overview

Swrve has 2 separate login environments for customers. The first is for US and other North American customers: dashboard.swrve.com

EU customers can log into their environment at eu-dashboard.swrve.com

If you have issues logging in, check https://eu-dashboard.swrve.com to confirm if your company has been created on the EU dashboard portal.

If you continue having login issues, you can change your password.

To change your password, do the following:

Step 1: Log out of Swrve.

Step 2: Click the Forgot Password link on the logon screen (in the correct US or EU dashboard). You are prompted to enter your email address.

Step 3: Enter your email address and click the Reset Password button. An email containing a link is sent to the email address you provide.

Step 4: Click on the link contained in the email. You are directed to a change password screen.

Step 5: Enter your new password. This password must be sufficiently complex.

If you still cannot login, confirm with your admin that your user has been created and allowed access to an app in the Swrve dashboard.

As of April 10, 2018, Google has deprecated GCM. The GCM server and client APIs are deprecated and will be removed as soon as April 11, 2019. Migrate GCM apps to Firebase Cloud Messaging (FCM), which inherits the reliable and scalable GCM infrastructure, plus many new features.

There are basically 7 steps to complete migration and make necessarychanges on the Swrve dashboard.

Step 1:

-Go to https://firebase.google.com

-Log in with you Developer Google Account.

-Click on GO TO CONSOLE.

https://docs.swrve.com/developer-documentation/integration/android/

Step 2:

-Click Add Project.

Step 3:

-Select your app project from the list.

Step 4:

-After selecting your app project click on Add firebase.

Step 5:

-Click on setting button and select Project Settings.

Step 6:

-Select Cloud messaging.

-Here you will find Legacy Server Key and Sender Id.

-Copy Legacy Server Key.

Step 7:

-Go to your App integration page on Swrve Dashboard.

-Paste Legacy server key into Server key Field.

-Save that key and check if the key is saved successfully.

-Once the key is saved click on Verify key button and check if key is successfully saved.

Once all of these 7 steps are completed your FCM migration on dashboardlevel is completed. Now you need to make necessary changes into your source code and implement Swrve FirebaseFlavoredSDK. You can find more information regarding that here:

Overview

To QA test your integration, A/B tests, in-app messages and push notifications, you must first set up the QA devices you want to make available for testing. Swrve's QA Devices screen enables you to manage QA devices and access device events.

Setting Up QA Devices

Setting up QA Devices

To set up a new QA device, do the following:

Step 1: Select Settings > QA Devices on the Swrve menu bar to display the QA Devices screen.

Step 2: Click the Add QA Device button to display the Add QA Device dialog box.

Step 3: Depending on number of the app's Daily Active Users (DAU), do the following:

If the app has low DAU (less than 700), open the app on your device and click the Yes, I have opened the app button.

If the app has greater than 700 DAU, the Add QA Device dialog prompts you to enter the device's IP address to filter devices relevant to your app. You can get the IP address by going to www.whatIsMyIPaddress.com in the device's web browser. Enter the device's IP address and then click the Yes, I have opened the app button.

A list of the devices most recently seen by Swrve is displayed. You can refresh this list by clicking the Refresh List button.

Step 4: If your QA device is displayed in the list of devices seen by Swrve, select the device by performing the actions below. Otherwise, proceed to Step 5 to add the device manually.

Click the Select button to the right of your QA device.

Enter the nickname that you want to assign to the QA device into the Nickname field.

Click the Add QA Device button to add the QA device to the list of devices on the QA Devices screen.

Proceed to Step 6.

Step 5: If your QA device is not displayed in the list of devices, add the device manually by performing the actions below:

Click the add your device manually link.

Enter the nickname that you want to assign to the QA device into the Device nickname field.

Enter the user identifier into the User id field. Consult your development team about the user ID to enter. The Finding the User ID section at the bottom of this article provides guidelines on how your development team can ascertain the user ID.

Click the Add QA Device button to add the QA device to the list of devices on the QA Devices screen.

Step 6: Click the Edit link to the right of your new device and update the following controls as needed:

Logging enabled - select this check box if you want the Swrve service to display logging information for in-app messages.

Reset device state - select this check box if you want to bypass in-app message delivery limits.

Step 7: Click the Update button.

Additional (non-editable) controls are displayed to inform you whether or not push notification testing is enabled for the QA device in question:

If the Apple Push enabled control is displayed, push notification testing is enabled for the iOS device (a session has been started on the device and the device token has been saved in the database). The QA device is automatically available for iOS push notification testing on the Preview & Test screen of the push notification creation wizard.

If the Google Push enabled control is displayed, push notification testing is enabled for the Android device (a session has been started on the device and the Sender ID was configured for the device in the SDK). The QA device is automatically available for Android push notification testing on the Preview & Test screen of the push notification creation wizard.

If the Apple Push disabled control, Google Push disabled control,WNS Push disabledcontrol or Web Push disabled control is displayed, the test device cannot currently be used to test push notifications.

For information about QA testing in-app messages and A/B tests, see the following articles on the documentation site:

Viewing QA Device Events

Once you have set up a QA device, you can access the QA Device Events screen. This screen enables you to view the following for debugging purposes:

All events (in real time) sent from the SDK to Swrve, including:

The event name.

The time of the event.

Raw JSON data for the event.

In-app messages triggered and any errors encountered.

In-app messages downloaded and any errors encountered.

To access the QA Device Events screen and view device events, click the Logging link to the right of the device for which you want to view events. The QA Device Events screen is displayed for that device.

Troubleshooting QA Devices

This section provides recommendations for troubleshooting issues related to setting up QA devices.

QA Devices Not Available for Push Notification Testing

If your development team has integrated push notifications for your app and you have set up QA devices for push notification testing, but your QA device is still not displayed on the Preview & Test screen of the push notification creation wizard, check the following:

Check that your development team are using the correct version of the SDK for push notifications. For iOS, the SDK must be version 2.7 or later. For Android and Unity, the SDK must be version 2.9 or later.

For iOS QA devices, check that the Apple Push enabled control is displayed for the device. For Android QA devices, check that the Google Push enabled control is displayed for the device. If either control is displayed as disabled, it is likely that the required configuration has not been performed by your development team.

Finding the User ID

To ascertain the user ID for a specific device, your development team can use the methods outlined below for iOS, Android or Unity, depending on the platform of your app. Alternatively, they can use Wireshark to find the user ID for any platform.

iOS

Step 1: Connect the iOS device to your machine.

Step 2: Open Xcode and navigate to Window > Organizer > Device > Console.

Step 3: Restart the app on your device. An entry is now available which contains information such as the user ID, game ID, API key and other SDK configuration information.

Android

By default, the user ID of your device is the Android ID. Access this ID by using an app from the Google Play store.

Unity

By default, the user ID is the SystemInfo.deviceUniqueIdentifier for your app.

Wireshark

You can use Wireshark to ascertain the user ID for any platform. The device must be on the same network as the device capturing the packets.

Step 1: Start Wireshark.

Step 2: Select Capture > Start.

Step 3: Restart the app on your device. A HTTP request to http://api.swrve.com is now displayed with the user ID.

Overview

You can view your usage data for the past six months on theCompany Usage screen. This screen provides information about the following:

The total DAU (Daily Active Users) for each calendar month, where DAU is the number of unique users on a calendar day in the local timezone of your app.

The total number of unique users in the calendar month.

The total number of push notifications sent in the calendar month.

To access the CompanyUsagescreen, click Settings > CompanyUsage on the Swrve menu bar.