Loading

MobilePush Key Points Summary

Publiceringsdatum: Dec 23, 2025
Beskrivning

Point: Target Devices for Sending

When sending an outbound Push Notification, the system attempts to send to "all opted-in devices for the target app" associated with contacts on the specified list or data extension.

Therefore, the number of sent messages will almost always be more or less than the number of contacts on your list or data extension. Please pay attention to this point, as we frequently receive inquiries about discrepancies between the send count (e.g., from the "Sends" tab) and the number of contacts on the list.

It's not uncommon for a single contact to use multiple devices, in which case the send count will exceed the list count. On the other hand, if there are many opted-out devices, or if a contact is not associated with the target app, these devices will not receive the notification, and the send count may be less than the list count.

Note: Inbox messages include opted-out devices.

Reference: Who Receives Your Push Notification

Point: Confirming Send Results

To check the send results for individual devices, use the Data Extract Activity: MobilePush Detail Extract Report. If push notifications aren't displaying correctly on a device, you may need to review and provide this report.

If the report shows a "Success" status for the target device's send, it indicates that the send from Marketing Cloud to the provider was successful. This suggests the problem lies somewhere between the  provider and device/app side. If the status indicates a "Fail," refer to the SERVICERESPONSE column for error details as per the document below.


Reference: MobilePush Message Detail Extract Errors

If the send status for some devices is "Failed," it's mostly due to the invalid token information used for push notifications for those devices. In such cases, the "Service Status" column in the MobilePush Detail Extract report will show messages like "Requested entity was not found," "NotRegistered" (Android), or "InvalidToken" (iOS).

Devices that fail for the reasons above cannot receive sends until a new token is issued after reinstallation/notification permission is granted and then linked to Marketing Cloud. Note that devices will automatically be marked as opted out after three consecutive delivery failures or, for iOS, by using the Feedback service. This prevents messages from being endlessly sent to undeliverable devices without your knowledge.

Note: The MobilePush Detail Extract Report is not enabled by default. Please open a support case with the relevant MID to request its activation.


Reference: Run the MobilePush Detail Extract Report

Additionally, there's an article that provides more detailed information on this topic. If you need to scrutinize send results, please refer to it as well.

Reference: How to Isolate the Issue with Push Notification Send Results Using the MobilePush Detail Extract Report

Point: Integrate Contact Keys with Other Channels

As shown in the "Reference Information" URLs below, implement the method to explicitly specify a contact key (setProfileID/sfmc_setcontactKey) *. By aligning the contact key you specify here with the existing contact key structure used in other channels like Email Studio, you can integrate MobilePush contacts with contacts from your existing channels.

For example, if you use a membership ID as the contact key in Email Studio, you can have the app (e.g., during login, via the methods mentioned above) send the membership ID to Marketing Cloud as the contact key. This links the email contact with the MobilePush contact.

Once contact keys are integrated, you can consolidate data such as message sends and opens from multiple channels for that user, bringing you closer to one-to-one marketing.

You might have a question about the differences in behavior based on the login status since a common execution timing for the above methods is during the login, but Marketing Cloud and the MobilePush SDK do not have the concept of contact login/logout, and there is no difference in behavior. Furthermore, the SDK does not automatically execute the above methods in conjunction with app login processing; you must implement this explicitly. Therefore, if you wish to change behavior based on login status, you will need to implement specific logic according to your requirements.

Reference Information:

Note: setProfileID/sfmc_setcontactKey may collectively be referred to as setContactkey.

Point: Manage Unnecessary Contacts

If your app doesn't send a contact key, MobilePush will register a GUID-formatted contact key (Contacts and Devices) during the SDK's initialization. Consequently, if a contact key is later sent from the mobile app to Marketing Cloud, the initially created GUID-formatted contact key will remain as a contact unlinked to any channel.

If you wish to avoid possessing such GUID-formatted contact keys, you can periodically delete them using the "Find Contacts Without Channel Addresses" method, or you can utilize Delay Registration. With Delay Registration, a contact won't be registered unless a contact key is explicitly sent via setContactKey (e.g., after login from the mobile app side). This also means you cannot send messages until a contact key is sent via setContactKey. Considering these characteristics, please evaluate Delay Registration when necessary.


Reference Information:

Caution 1:
setContactKey
will link to an existing contact if the specified contact key already exists, or generate a new contact if it doesn't. Please note that it does not "update" a contact key. For example, if a single device performs setContactKey 10 times, each with a different new contact key, 10 new contacts will be generated.

Caution 2:
While there's no upper limit to the number of devices you can link to a single contact, implementing a system that registers an unspecified large number of devices to one contact is not recommended. We sometimes see cases where anonymous devices, whose users cannot be identified, are registered to a single contact key. Doing so can lead to various issues, such as being unable to view anonymous contact information in Contact Builder or making tracking information difficult to follow.

For handling anonymous contacts: if you don't want them registered as contacts, use the Delay Registration method mentioned previously. If you do want to register them, register them as default GUID-formatted contacts.


Reference Information:
Registration Updates Via Contact Key, Attributes, and Tags Quote: "Don't set the contact key to a generic, non-unique value"


Caution 3:
When extracting contacts to be deleted because they no longer have channel address information and are unnecessary, always use "Contacts Without Channel Addresses" to extract the deletion targets. Using filtered lists or similar methods might inadvertently delete valid contacts that possess mobile channel addresses.

Especially for mobile channels, unlike email channels, channel addresses are managed per Business Unit (BU). Without considering this, you might accidentally delete valid contacts in a child BU. If that happens, as described below, all MobilePush functionalities, including push notifications, for the devices associated with the deleted contacts will become unavailable. To restore functionality, end-users will need to reinstall the app.


Contact Deletion in Contact Builder > Deleting MobileConnect and MobilePush Contacts

-------------------

The deletion of all MobilePush contacts is considered associated with compliance deletion under GDPR or other legal regulations. Future push notification registrations from the designated mobile devices of this contact will be restricted by the MobilePush SDK and platform. To re-establish the contact, the contact must delete and reinstall the mobile application on their device.

--------------------

Furthermore, in accordance with the above, we do not provide methods other than reinstallation via support cases. We sometimes receive inquiries about implementations aimed at analyzing the internal behavior of the SDK after deletion and attempting recovery by means other than reinstallation.

Implementations that rely on such internal behavior cannot be supported through inquiries or guaranteed to function correctly. You must conduct thorough testing in your own environment before implementing them.

To avoid falling into such situations, always use "Contacts Without Channel Addresses" when extracting contacts for deletion. If you are forced to delete contacts that have channel addresses, please consider the points mentioned above and meticulously check for unnecessary contacts beforehand.

 

Point: Characteristics of Inbox Messages

Inbox messages have distinct characteristics that differ from push notifications, as detailed below:

Push Notification:
Marketing Cloud sends a remote notification request to a message provider (FCM/APNs). Notifications cannot be sent if the user has not granted notification permissions for the app.


Inbox:

When the app comes into the foreground, the app itself downloads messages targeted at its device from Marketing Cloud. Since it doesn't use a notification mechanism, messages can be downloaded even if notifications are not enabled for the app.

Please note that Marketing Cloud does not proactively send or deliver messages to the device. While terms like "delivery" or "send" are sometimes used for Inbox messages for convenience, it actually refers to making the Inbox message available for download by the device, rather than Marketing Cloud proactively sending something to the device.


Note when you check the Report

When you generate the "Push Message Detail Report," records for Inbox messages (only) will not be output unless the message has been downloaded. For example, if you target 10 devices with an Inbox message (making it available for delivery) and only 3 devices download it, the report will only show 3 records at that stage. The remaining 7 records will not be logged. Also, since no push notification is sent, push notification-related fields like "Status" will be blank.


Push Notification + Inbox:

This option sends a push notification while simultaneously making an Inbox message available for download. For devices that have not enabled notifications, the push notification will not be sent, and only the Inbox message will be made available for delivery.


Note when you check the Report

For devices that have enabled notifications, push notifications are sent, so a record is logged in the Push Message Detail Report at the point the push notification is sent. For devices that have not enabled notifications, a record is logged when the Inbox message is downloaded. "Push Notification + Inbox" utilizes two different mechanisms simultaneously, which can often lead to confusion, so please be mindful of this.

 

FAQ

Q) When does a device become opted out after an uninstall or disabling notifications? I tried uninstalling, but it remained opted-in, and the send status was still OK.
A) The exact timing is unclear as it depends on the behavior of the message provider. It's not guaranteed that a device will immediately opt out after uninstalling, or that the send status will change to NG during a send.

Q) I want to know when a device was uninstalled.
A) You cannot receive confirmation of a device uninstall via the Marketing Cloud SDK.

Q) If a DeviceID changes after an app reinstallation, will Inbox messages from before the reinstallation reappear?
A) No, they will not. Inbox messages are tied to the DeviceID. If the DeviceID changes due to reinstallation, those specific Inbox messages will no longer be available.

Q) I logged into a different account from the same device (e.g., set a different contact key via setProfileId), but the list of Inbox messages hasn't changed.
A) As mentioned above, Inbox messages are tied to the DeviceID. Therefore, even if the contact key changes, the messages available for download remain the same.
Note: We do receive inquiries about wanting to switch the list of Inbox messages when an app account (which is the contact key in Marketing Cloud) is switched, as described above, but as stated above, this cannot be achieved because Inbox messages are tied to the DeviceID.

Q) If I set %%_subscriberkey%% as a personalization string for a custom key, can I create Inbox messages based on the contact key?
A) No. Personalization strings are rendered each time the message is downloaded. This means the contact key at the time of download (not send) will be returned, resulting in the same contact key being assigned to all messages, making it impossible to segment.

Q) I've integrated a third-party push notification SDK in addition to the MobilePush SDK. Can I still receive notifications?
A) While technically possible, multiple SDKs might compete for notification control, so we cannot guarantee results, as explained in the article below. Therefore, we do not provide sample code or troubleshooting steps for such scenarios via support cases. You will need to implement customized logic within your app to manage this control.

Use Multiple Providers for Push Notifications

Q) I've embedded the MobilePush SDK in my app and installed the app on a device, but it's not reflecting as a contact in Marketing Cloud right away.
A) Contact reflection in Marketing Cloud is not real-time, so please wait a few minutes. If a sufficient amount of time (e.g., 1 hour) has passed and the contact still isn't reflected, use the Learning App to help isolate the issue.

If the contact is promptly reflected using the Learning App, it's highly likely that there's an issue with your integrated app's specific implementation, such as during initialization. In this case, review your logs to confirm if the app is initializing correctly on startup.

If the contact is not reflected even with the Learning App, various factors could be at play, including incorrect configuration settings in the Learning App, device communication issues, or a problem with the specific MID.

 

Knowledge-artikelnummer

000388835

 
Laddar
Salesforce Help | Article