✕
Marketers

Guide to Implementing Marketing Cloud MobilePush

By John Green

May 19, 2020

After another successful, but slightly complicated, Mobile Studio implementation I wanted to share my experiences, lessons learned and advice on implementing what I believe is one of the best Marketing Cloud features: MobilePush.

You might have noticed, like I have, that there aren’t many resources available that help bridge the gap between technical implementation guides and the conceptual design of MobilePush. I hope that this guide serves to close that resource gap by discussing what MobilePush does, the 4 step process to enable and connect it to Marketing Cloud, and some ‘gotchas’ and pitfalls I think are beneficial to share.

What is MobilePush?

MobilePush allows Marketing Cloud users to send push notifications to their customers. That’s not all! MobilePush also offers silent notifications, in-app messaging, Bluetooth Beacons and Geo-location.

My favourite part about MobilePush is that, once set up correctly, it is incredibly user friendly. Marketing Cloud users can easily send one-off push notifications, or include them in Journey Builder and Automations. Marketers can even direct their app users to CloudPages, a MobilePush Page or a specific page in their app using OpenDirect.

Implement MobilePush in 4 Steps

Implementing a mobile app with Marketing Cloud might sound daunting but the implementation can be broken down into the following 4 steps:

  1. Provision the app for MobilePush
  2. Create the Marketing Cloud Connect App
  3. Integrate the Marketing Cloud SDK
  4. Test

Step 1: Provision the App for MobilePush

The first step in the process is provisioning your apps for pushes. The process varies slightly for Android and iOS.

For iOS, you will need to ask your developers to create two iOS Apple Push Notification service SSL Certificates (one for sandbox and one for production); these certificates establish a secure connection between Marketing Cloud, Apple and your app. It is important to save these certificates as they will be needed in the next step.

For Android, work with your developers to retrieve the Legacy Server Key and Sender ID from Google Firebase. Again, these items will be needed in the next step so it is worth making a note of them.

Step 2: Create the Marketing Cloud Connect App

Once you’ve acquired the certificates and server keys, it is time to get to work in Marketing Cloud. You will need to navigate to Mobile Studio → MobilePush → Administration and select ‘Create App’.

Upload the APNS Certificate and add the Google Server Key and enable the optional settings such as Custom Sound, Custom Key, OpenDirect and Interactive Notifications- you can also add a Mobile Push Icon if you wish.

Then we move on to the configuration in Marketing Cloud. Make a note of the Access Token, App ID, App Endpoint and the account MID as your developers will need these to configure the SDK. It is important to note at this stage that the one Marketing Cloud App can be used for both Android and iOS.

Step 3: Integrate the Marketing Cloud SDK

Now that the app has been created in Marketing Cloud it is time to integrate it with your mobile app. Thankfully, Marketing Cloud offers a MobilePush Software Development Kit (SDK) for both Android and iOS. The SDK is a collection of files that make it easier for your developers to integrate the two systems.

Share the relevant SDK with your mobile app team along with the Access Token, App Endpoint, App ID and MID – it might also be worthwhile sharing Marketing Cloud’s Mobile Push Notifications Implementation Guide for additional context. If required, you can ask your developers to return additional attributes as part of the implementation but you will need to create these attributes in the MobilePush Demographics table in Marketing Cloud.

Step 4: Test, Test, Test!

As soon as your SDK has been implemented and configured you will begin to see users added to your MobilePush Contacts in Marketing Cloud when they download the app and register, it may take 15 minutes for the SDK to propagate for the first time. The number of total app opt-ins is shown on the MobilePush home page.

Once contacts are added, ensure that your push notifications are working by sending a test as soon as possible. The best method is by navigating to Mobile Studio → Mobile Push → Contacts, and select to create a new filtered list. To ensure you’re only sending to your testers it is a good idea to request a Device ID and use it as the criteria in your filtered list.

Your mobile app should receive the push instantaneously but if not you can troubleshoot by selecting the contact record and ensuring they meet the following criteria:

  • Device ID: the Device ID is how MobilePush knows where to send the notification, it is the equivalent of email address in Email Studio or mobile number in Mobile Connect.
  • Status = Active: if the contact has not been added to the Total Opt-ins it is likely that the user permissions were not correctly passed back to Marketing Cloud.
  • System/Push Token: without the system token you will not be able to send push notifications to the related device. The system token is generated by Apple/Google (not Marketing Cloud) when a user agrees to push messages. Check to ensure the SDK is sending the token back to Marketing Cloud.

MobilePush Gotchas and Pitfalls

Even with the limited configuration required in Marketing Cloud and the extremely helpful SDKs, there are a few considerations that need to be taken into account to ensure MobilePush is implemented successfully.

  • The Contact Key
  • System Token
  • Enabling Permissions
  • Importing MobilePush Contacts
  • MobilePush and URLs

The Contact Key

As with all the studios and builders in Marketing cloud, the contact key is king.

When the SDK adds contacts to Marketing Cloud, it will assign a random unique ID for unidentified app users. Essentially, unless you are asking your users to register when they download the app Marketing Cloud will create new/duplicate users. And even if you do ask your users to register, the SDK will not automatically set the correct contact key.

To prevent this from happening you will need your developers to add sfmc_setContactKey for iOS and setDelayRegistrationUntilContactKeyIsSet() for Android. These functions hold off adding contacts to Marketing Cloud until you have been able to set the contact key, which you can do by returning the Contact Key when verifying a user’s login credentials.

System Token

As mentioned, you will not be able to send a push notification if you have not acquired the system/push token. This token is generated by the OS vendor when an app user agrees to enable push notifications and is checked at the time of send by either Google or Apple – if there is no token, there’s no push.

While the SFPushNotificationManager class is readily available, it’s not part of the Marketing Cloud SDK, and is easily overlooked during the implementation. Be sure to raise this with your developers and share the Android and iOS Developers guides with them so they can properly implement the SFPushNotificationManager class.

Enabling Permissions

iOS implementations also require an additional step and you will need to ensure your mobile app is requesting users to allow push notifications, this does not happen automatically in iOS like it does in Android.

It is also important to note that the initial implementation will only cover the basic push notifications. To be able to use Geo-location or Inbox messaging you will need to ensure you app is asking for users permissions and that your SDK is updated to include the following functions:

Geo-location

Inbox Messaging

Importing MobilePush Contacts

As alluded to earlier, only new contacts are added to MobilePush so unless this is a newly developed app you will most likely want to add existing app users. Luckily, you can easily import existing contacts into MobilePush either to the All Contacts or to a pre-created list as long as you include the following fields;

  • Device ID
  • System Token
  • Platform
  • ContactKey

Additional attributes can be included if required.

MobilePush and URLs

There is a high chance that you’ll want your push notifications to include call to actions, such as directing customers to a landing page or to a specific page in your app (OpenDirect). Whilst these options are available in MobilePush they are not included as part of the SDK, and your app won’t automatically open CloudPage URLs, OpenDirect URLs or URLs from inbox messaging.

Fortunately, Marketing Cloud do have a solution and it just needs to be included in the initial MobilePush implementation. By implementing the MarketingCloudSDKURLHandlingDelegate protocol in iOS and the NotificationCustomizationOptions in Android, your users will have a seamless experience when clicking on your push notification links.

Summary

As I mentioned, Marketing Cloud MobilePush is one of my favourite features in Marketing Cloud and once set up correctly, is incredibly intuitive and easy to use. With customers now spending more and more time and consuming more content on mobile devices, implementing MobilePush really gives Marketing Cloud marketers the ability to connect with their customers at the right time.

If you have any questions about Marketing Cloud MobilePush, feel free to comment below, or get in touch: jrgreen284@gmail.com

The Author

John Green

Marketing Services Consultant at Bluewolf, An IBM company. I have been working with both Pardot and Marketing Cloud for 4 years.

More like this:

Comments:

    Oscar McCall
    May 19, 2020 11:52 pm
    One addition to Contact Keys (which may be resolved now) is if you need the value exposed to create 1:1 mapping back to the contact model eg to do a lookup via AMPScript you need to set another mobile push attribute to catch the value.
    Reply
    Lucy Mazalon
    May 20, 2020 10:35 am
    Hi Oscar, thanks for sharing that!
    Reply
    Hafeel
    August 27, 2020 3:47 pm
    Hi sir..i have some doubts: 1.Set a contact key and call allMessages in InboxMessage then logout app and again set different contact key in same device and call allMessages,In both case i am getting same messages. 2.InboxMessage not working after re-install the app on the same device. If you have any idea please help me.
    Reply
    Bill Mote
    April 23, 2021 7:00 pm
    This is working as designed. The SDK's, and push in general, is designed for a single user with multiple devices, not a multiple users on a single device. Extending this functionality is on roadmap so stay tuned.
    Reply
    Gautam Patel( SFMC Consultant)
    April 19, 2022 3:28 pm
    Hey, I have a few questions on Mobile Push: - We have multiple systems in place to register any contact. Like somebody registers from the mobile application. It has to through the system 1-> then to the data warehouse and then contacts are getting generated to Salesforce CRM. - We are about to implement a Mobile push Notification for Geo-fencing messages. According to the current implementation it is giving us GUID(system generated) as contact keys, which is creating additional contacts in SFMC and difficult to map with the existing or newly created contacts. To overcome this, We came up with the idea to use Salesforce ID as a contact key so that we can avoid contact duplicity. The biggest challenge which we are facing is our system is, it is linked with multiple data streams as I have mentioned above and there is no document available that states how to utilize salesforce ID as a contact key. - Can you please share your valuable feedback on this. - Targeted customers: 1. One who is already in the Salesforce CRM, but doesn't have a mobile App 2. New registrants
    Reply
    Anar
    July 11, 2022 4:10 pm
    I wonder if it has to be a List or can I use a Data extension to import my existing App contacts to Mobile studio?
    Reply
    Umang
    November 11, 2022 8:55 am
    Hi Lucy,  Can you explain how multiple device id are linked to the same contact Key? That is how the device id's are generated. In my current Org, I have a Contact where it has 5 deviceid and whenever we send out the notification, 3 of them receive it as 1 one is opted out and the other one gets errored out.  Can you explain how these device ids are getting generated for the same contact key? Looking forward to hearing from you soon.
    Reply
    Rachid Mamai
    January 20, 2023 11:07 am
    Device ID is a globally unique identifier (GUID) that is randomly generated by the SDK each time an app is installed on a device. Sometimes, this ID is referred to as an Installation ID. Device ID is not used as or considered a persistent unique identifier for the physical device. Device ID represents an instance of an app installation. The ID does not persist across app uninstall and install cycles. When a contact installs your app, the SDK creates a Device ID. The SDK creates another Device ID when these events occur: - The contact purchases a new mobile device and installs your app. - The contact deletes the app and then later reinstalls your app. - The contact does a factory-reset of the device and then reinstalls the app. More here: https://help.salesforce.com/s/articleView?id=sf.mc_mp_FAQ_troubleshooting.htm&type=5
    Reply
    Giulia
    March 20, 2023 7:01 pm
    Hello, my dev team is implementing the method: sfmc_setContactKey for iOS and setDelayRegistrationUntilContactKeyIsSet() for Android. How can I test that this has been implemented correctly? There are some advices or best practices to follow?
    Reply
    Cheap Dedicated Proxies
    December 15, 2023 5:20 am
    An impressive share! I have just forwarded this onto a colleague who has been doing a little homework on this. And he in fact bought me breakfast because I discovered it for him... lol. So allow me to reword this.... Thank YOU for the meal!! But yeah, thanks for spending the time to talk about this issue here on your web page.
    Reply

Leave a Reply