Last modified April 28, 2020 by Shelly Wolfe

Push notification permissions

Learn how Swrve collects push notification permissions and how to optimize the permission dialog timing and custom preference-based user properties to successfully target your customers via push notification campaigns.

iOS and Android require app users to give permission for key services, such as push notifications, and to access personal information, such as location, contact information, and photos. This guide will help you understand how Swrve collects and reports notification permissions. It will also show you how to time your permission request for optimal buy-in and how to target users based on their permission preferences to ensure the success of your future push notification campaigns.


Background

If you want to send push notifications to your users, you must first request their permission to do so. iOS and Android use different methods to collect notification permissions from app users.

iOS

Apple uses the Apple Push Notification service (APNs) to send push notifications from Swrve to an iOS device, using a device token that is unique to each app and each device. The first time a push-enabled app requests the device token, iOS displays a dialog that requests permission for your app to send notifications to the user of the device. Note: You can only display this dialog once.

iOS notification permissions

If the user selects Don’t Allow, then Swrve is not sent a device token and cannot send push notifications to that user. That is why the timing of such a request is crucial.

Depending on the user’s selection, Swrve updates the iOS push notification property swrve.permission.ios.push_notifications with the associated value:

Permission Property Value
Allow authorized
Don’t Allow denied
Customer hasn’t seen permission dialogue unknown

The last value, unknown, is an area of opportunity to increase your push permission opt-in. Users in this group have either not been asked to opt in or opted out of a pre-permission prompt. For information on how to target these customers, see Campaigns to optimize push opt-in.

To send a user push notifications, their iOS push notification property must be set as authorized. If the value is set as denied, you may never be able to send them push notifications, unless they change the permission manually in their app settings.

By default, the Swrve SDK sends the iOS push permission value at app startup and it is automatically available in the audience filter options for targeting your push notification campaigns. For information on how to estimate your potential push audience for campaign targeting, see Estimating your push audience.

Android

Android uses a different method to collect app notification permissions. They categorize different permission types (for example, location, notifications, contacts, and so forth) as either normal or dangerous, depending on whether the requested data or resource includes a user’s private information. (For more information, see the Android Developer article, Requesting Permissions.)

Android considers push notifications as a normal permission and automatically collects this permission on the first app session. Swrve then updates the Android push notification property swrve.permission.notifications_enabled to a value of TRUE. If a user revokes this permission in the app settings page, the value is set to FALSE.

For devices running Android Oreo and above, you have the option of using notification channels to let the user customize what type of notifications they want to receive. Swrve does not currently have an option for setting notification channels in the campaign workflow, however, you can create a custom property for each notification preference category and target your audience using those properties. For more information, see Push preferences.


Configuring permission dialog and notification preferences

This section describes how your development team can configure the timing of your notification permission dialog for optimal buy-in (iOS) and create preference-based custom properties that you can use to target your campaign audiences (Android). It also discusses Swrve’s solution for real time push notification opt-out.

Timing the iOS notification permission dialog

We recommend using the Swrve SDK’s built-in functionality to delay the timing of this first device token request to a time when you believe the user is most likely to agree to such messaging.

You can delay the system push permission prompt to display after a user sees and interacts with your own branded in-app message—a pre-permission campaign. For more information on how to create a pre-permission campaign inside Swrve, see Push Opt In Campaign.

The advantage of delaying the prompt until after a user sees this message is that you can show the message to the user as many times as you would like because you are not displaying the system prompt unless they agree to opt in through the pre-permission campaign.

Notification permission opt-in campaigns

One way to optimize the notification permission request is to create a branded, in-app campaign that is displayed first and asks the customer if they would like to give permission to receive notifications. If the customer agrees, you can then trigger the iOS permission dialog. This lets you ask for permission as many times as you like without actually triggering the permission dialog. For more information on how to create this type of campaign, see Timing the device token (push authorization) request.

Push preferences

Although we recommend only allowing users to opt in to all push messages, you can enact “Push preferences” as a method to allow users to select the types push notifications they want to receive.

There are two steps involved in implementing this method:

  • Create a notification preference center
    • Construct a simple page inside the app to collect the user’s preferences.
    • This is not provided or supported by Swrve.
  • Create a custom user property for each preference category
    • Assign a custom user property to the user when they select a specific notification category in the push preference center. Examples include: Push_preference = daily, push_preference = weekly, push_preference = later

Once you collect the user’s preferences, you will need to ensure that you include this “preference” as a custom user property in the target criteria of the specific campaign. This means that no user can receive the campaign unless they have opted in via the preference center.

Real time notification opt-out (Unsubscribe)

If you wish to enact a real time push opt out (that is, unsubscribe), there are a few requirements and steps involved. Again, this setting is very restrictive and not often recommended by Swrve. However, we understand some may have legal obligations to opt out their users to all non-transactional notifications in a real time fashion.

Push opt-out

For a user to opt out of scheduled push notifications from an app, the app needs to send a user property update for property swrve.opt_out.push with value “1”.  If this was done by mistake, or if a user decides they want to receive push notifications after all, the app can send a user property update for property swrve.opt_out.push with value “0” and they will be removed from the opt-out list.

Real time opt-out does not apply to Push via API notifications.

Data refresh timing

While opting out is real time, opting back in can vary in timing.  If the user opts out by mistake (usually meaning the user opts back in within a 24-hour window of opting out), then their opt back in will be handled real time. If the user returns to opt back in after a few days, it will take another 6-12 hour data refresh to make them eligible to receive push notifications again.

The user’s “initial opt in” (when a user first opts in for push) requires a 6-12 hour data refresh (handled by Swrve on the backend).

Integration requirements

This feature does not require an update to the Swrve SDK, but will require an app update to actually start sending this property when a user decides to opt out. For more information, contact your CSM at support@swrve.com.

Real time opt out does not exclude the user from seeing Push via API campaigns as they are triggered and delivered in a different manner with a different purpose.

Using notification permissions to target campaigns

This section shows how to use push notification permissions and their associated user properties when building your Swrve push notification campaigns. This will help you plan and create campaigns in Swrve that optimize your notification permissions.

Estimate your push audience

Depending on how you leverage push permissions (push preference, real time push opt-out), it’s important to understand how to estimate your potential push audience for your upcoming push campaigns in Swrve.

All users with a push token

To view your estimate audience:

  1. When creating a new campaign from your Campaign center, select Push Notifications as the campaign channel.
  2. On the Campaigns builder, the Audience block displays your estimated audience size. This is a count of the device tokens, or all users with a push token.

This device count does not reflect the audience who “unsubscribed” or opted out of all push permissions, that is, user’s with a property value of swrve.opt_out.push=true.

Users with a push token that did not opt out

On the Audience screen, the estimated audience includes this suppression content of those that opted out in real time, that is, user’s with a property value of swrve.opt_out.push=true.

Users with push token that did not opt out and have a push preference

When building a custom audience, use the User Profile Filters Properties tab to continue to filter your estimated audience with the specific push preference that the user requested. This will further narrow down the target of potential recipients.

Campaigns to optimize push opt-in

We highly recommend finding the right moment to request push permissions from your user. This is an important step toward building a dialogue.

Here are a couple of campaigns we suggest:

Pre-permission “Push Opt-In”

Use this campaign to reach users who don’t understand the benefits of opting in for your push notifications.

  • Which tool is best to use to build this campaign?
    • Conversations – Templated campaigns that are easy to set up and launch out-of-the-box.
    • In-app message – If you have display/branding limitations, you can use an in-app message, but it requires additional integration steps.
    • Integration prerequisites – To get started, please refer to our documentation on delaying the system prompt. You will need to integrate a deeplink to fire an event to trigger the app to display the system prompt if a user clicks OK to opt in from this campaign.
  • Who should I target?
    • Add the following user property to your campaign target: swrve.permission.ios.push_notifications = unknown
  • When should I display this campaign?
    • Within the first few sessions of using the app.
    • We recommend you try triggering this campaign after a user engages with a feature that would require or benefit from push notifications.
  • Should I A/B test this campaign?
    • Always! Try A/B testing different creative to see which “tone” or “visual” proves most successful—then optimize, optimize, optimize! For example:
      • Passive vs. urgent
      • Visual steps vs. plain text
      • Large vs. small imagery
  • Can I deliver this campaign to a user multiple times?
    • Yes, we recommend you occasionally check in with the user every to ensure they understand the benefits of opting in for push notifications.
    • More specifically, reach out to the user when they engage with a feature of the app that would benefit or require push opt in.

Re-permission “Push Plea”

Convert users who have opted NOT to receive push campaigns from the pre-permission prompt.

  • Who should I target?
    • You will still add the following user property to your campaign target: swrve.permission.ios.push_notifications = denied
    • In this case, the campaign should include the campaign deeplink “app-settings:”, which will direct the user to the app’s settings page where they can opt back in.