Loading

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

Veröffentlichungsdatum: Dec 10, 2025
Beschreibung

After implementing the MobilePush SDK, you might encounter issues where push notifications (outbound, alert) sent from Marketing Cloud don't reach devices. In such cases, it's often beneficial to first use the MobilePush Detail Extract Report for troubleshooting. This article describes how to investigate why push notifications aren't reaching devices based on the results of the MobilePush Detail Extract Report, and addresses related questions.

Lösung

If you observe that push notifications aren't being delivered, we recommend first checking the MobilePush Detail Extract Report. This report contains detailed results of requests from Marketing Cloud to the Push Notification Service (PNS) for each job and device, which is useful for narrowing down the issue.

 

The next point of investigation will differ based on the Status field in the report:

  • Success: Since the delivery from Marketing Cloud was successful, focus on the receiving end, such as app implementation or device settings.
  • Fail: Details are provided in the ServiceResponse field, so check this. During development, failures are primarily caused by provisioning or implementation issues.
  • No corresponding record: It's possible that sending was suppressed within Marketing Cloud. Check the opt-in/out status or confirm if the target device was included in the audience.

Further details are provided below.

A. If the send result to the target device is "Success"

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

This indicates a potential issue with the receiving mobile device's settings or the app's implementation. In this scenario, processing from Marketing Cloud has completed without problems. Therefore, the cause cannot be identified from the Marketing Cloud administration screen or our service logs. Receiving mobile device and the app should be checked for the root cause.

 

・Receiving Device Settings: Push notifications may not be delivered due to factors like communication status, connection to restricted networks (e.g., public or corporate Wi-Fi), user OS settings (e.g., low power mode or Do Not Disturb), or app notification settings. Please ensure the device is in a state where it can receive notifications by, for example, allowing notifications for the app, connecting to a mobile carrier's network, or disabling power-saving modes that restrict features.

・Implementation or Data-Dependent Issues:

During the development phase, it's common for app implementations, such as the handling of notification reception, to not be correctly executed, resulting in notifications not being displayed to the user. Refer to the documentation and Learning App at the end of this article, compare their samples with your app's implementation, and conduct notification tests.

Note: There are cases where a "Success" response is returned by the provider even if notifications are turned off or the app has been uninstalled. Please be aware that uninstallation and similar status changes are not always reflected in real-time in the Status field.

 

B. If the send result to the target device was "Fail"

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

In many cases, the report will indicate an attempted send to an invalid token. For invalid tokens, messages like "Requested entity was not found," "NotRegistered" (Android), or "InvalidToken" (iOS) will be displayed.

In normal operation, this can happen if the user has turned off notifications for the app or if the app hasn't been used for a long time and the provider has invalidated the token. However, during the development phase, incorrect app provisioning for the respective Push Notification Service is a common cause.

There are various provisioning checkpoints, and our service cannot uniquely identify the exact problem. Therefore, a trial-and-error approach to isoate the issue is needed to reviea each item based on the information below and the related articles. 

References:

In cases of "Fail," the ServiceResponse message often directly reflects the response from the provider. Check the information provided by each respective provider like the following to find out what the problem is:

Reference:

C. If no record of delivery results for the target device existed

 

In this scenario, possible situations include:

  • The target device was opted out and thus excluded from delivery.
  • The target device was not linked to a contact key on the target list.
  • An error occurred in AMPScript or SSJS within the message.

Here's how to check the above:

 

・How to confirm if the target device is an opt-out (or opt-in) device:
There are several methods, but a common one is found under the "Review Contact Opt-Out Status" section of the article referenced below. Please ensure the target device is "Opted-In."

Reference: Review Contact Opt-Out Status

・How to confirm if the target device is linked to a contact key on the target list:

Similar to the URL mentioned above, check the detailed information of the target contact key from Contact Builder. On this screen, you can see a list of devices linked to the target contact key. Confirm whether the device ID of the target device is linked to the contact key for sending. Please note that the device linkage to a contact might have changed since the time of delivery.

・How to troubleshoot if an error occurred in AMPScript or SSJS within the message:

Perform a preview or test send of the message to a test device in MobilePush or Content Builder to ensure no errors occur. However, if the data in the referenced data extension (e.g., records) has changed since the time of delivery, our support service cannot reproduce the exact historical data. Therefore, confirm that the message can be rendered correctly with conceivable data. When reproducing, try to secure as much of the original data as possible and validate it with previews or test sends.

Other Patterns:

If the target device's status is "Inactive," it will also be excluded from delivery. This status is separate from "opt-in/out" and indicates the status of the device itself. However, as a general rule, devices are always "Active." Rarely, some operations may intentionally change the status to "Inactive" via MobilePush contact import activities or Contact Builder. In such cases, exclusion due to status change might occur.

Unintended Opt-Out:

Even if notification settings are enabled, the device might sometimes be marked as opted out on the Marketing Cloud side. As explained in the article below, this is often seen in cases of incorrect provisioning (especially with APNs), such as errors in the app's provision key or certificate. Therefore, review your provisioning settings based on the article below and the "Prerequisites" mentioned earlier.

Reference: Review Contact Opt-Out Reason

<FAQ on Reports>

Q) How do I obtain the MobilePush Detail Extract Report?

A) You obtain it by executing a Data Extract Activity followed by a File Transfer Activity, and then storing it on your Enhanced FTP site or similar location.

Reference: Run the MobilePush Detail Extract Report Please ensure you use a file name with .zip extension, as the file will be created as a zip archive.

Since the Data Extract Activity outputs files to the Safehouse, you'll then transfer them to an FTP server. Use the File Transfer Activity in Automation Studio

 

Q) I can't select the MobilePush Detail Extract Report in the Data Extract Activity.

A) It needs to be enabled. Please contact support with the MID you wish to enable.

 

Q) I want to use the "MobilePush Detail Report" in Analytics Builder.

A) You can find similar information in the MobilePush Detail Extract Report, so it's fine for simple checks. However, from the perspective of the richness of the output information and output performance, we recommend using the MobilePush Detail Extract Report for actual operations and troubleshooting phases.

 

Q) Can you explain the meaning of each item in the report?

A) The definitions are available in the document below. We also recommend generating and reviewing the report after a test send to gain a deeper understanding by seeing the actual data.

Reference: Marketing Cloud - MobilePush Detail Extract Report Output

Please note: While the document above mentions data types and lengths, the report is a CSV file and, unlike a data view, does not inherently possess database-like type or length definitions. Please consider this as an example of settings when inserting CSV data into a data extension. Furthermore, when storing the report's CSV in your own database, you don't necessarily have to adopt the specified data types or lengths. Especially concerning date types, they might not conform to each database's format, in which case you'll need to prepare your own data conversion programs or similar processing.

 

Q) How long does it take for send results to be reflected in the report?

A) It depends on the data volume. For relatively small testing volumes, results are usually reflected within a few minutes after delivery. However, for large-scale deliveries common in live environments, it may take longer.

 

Q) Actions like push notification opens or inbox message downloads by individual devices are not reflected in real-time in reports or the administration screen.

A) Information such as opens and downloads is not sent in real-time. Instead, it's typically batched and sent, primarily when the app is moved back to the background. Therefore, it's not always reflected instantly, and there may be some lag. When testing during development, intentionally perform actions like opening notifications, then put the app in the background, wait a bit, and then check the report results.

Reference:

How the MobilePush SDK Works

=====
After the contact opens and interacts with the push notification, the SDK records the event and sends analytics data to Engagement. The SDK transmits analytics data after the application moves into the background or comes back into the foreground. If a user force-closes the app, the SDK stores the analytics data and sends it to Engagement the next time the user opens the app.
=====

 

Q) The report extraction step takes a long time; is there a service issue?

A) If it suddenly takes a significantly longer time, especially when your sending volume hasn't changed much, please first check the Trust site for any ongoing incidents. On the other hand, extraction time may gradually increase as the number of messages sent grows. In such cases, we may ask you to address this by narrowing the date range for the output.

 

Q) The open data sometimes changes when I modify the report's output date range.

A) Information related to opens may change depending on the report's output date range. For example, imagine an open occurs some time after the send date. If the send data falls within the report's output date range but the open data falls outside of it, the resulting report might show that the message was not opened. However, if you expand the date range to include the open date and retrieve the report again, the open data will then fall within the output date range and be recorded in the report.

 

Q) The "Status" column is blank. What does this mean?

A) This likely indicates download information for an Inbox message (Inbox Only). Please check if the "Template" field is set to "Inbox."

For Inbox Only messages, no push notification is sent, so the Status will be blank. Also, with Inbox Only, a record related to download information is only logged in this report after the message has been downloaded. Conversely, if it's not downloaded, no record will appear in the report. Because of this, you cannot use this report to confirm the number of target devices for Inbox Only messages.

However, there are two cases where this differs even for Inbox messages: First, if it's Inbox Only AND the "Update iOS Badge" option is enabled. When this option is ON, a silent push is sent to update the badge. In this case, a record for the silent push will be generated in this report, and the Status will be logged, even if the message isn't downloaded.

The second case is Inbox + Alert. Since a push notification is sent simultaneously, a record for the push notification will be generated and the Status logged, even if the message isn't downloaded. Note: Even if the Status is "Failed" in this scenario, the Inbox message can still be downloaded. This merely indicates that the silent push mentioned above did not occur, so it should be considered separately from the Inbox display.

 

Q) Is there a way to confirm the Device ID other than through Contact Builder?

A) Exporting a filtered list from MobilePush is a relatively easy method. You can confirm the device ID of your test device based on model information or attribute data. Various other device information can also be obtained this way, making it useful for segment creation and other purposes.

Reference: Export Contacts from a List

Note: *The number of filtered contacts might differ from the count in the exported CSV. This is because the former refers to the number of contacts matching the filter, while the latter outputs MobilePush device information for those contacts. *The exported information does not include the System Token. 
*Please use the methods above or check the logs by connecting your app to a development environment to identify a device ID.

 

Q) The "DateTimeSend" field seems to deviate from the send job's start time.

A) This situation can occur with Inbox messages. Please refer to the link below for details:

About DateTimeSend in MobilePush Detail Extract Report

Related Information:

 

  • Learning App: This is useful for checking SDK behavior and implementation samples, and for isolating problems dependent on app-specific implementations. https://developer.salesforce.com/docs/marketing/mobilepush/guide/additional-developer-resources.html Please note that this app is not a supported product, so questions about the app itself are outside of support scope. However, you can ask questions based on SDK behavior observed in this app, or refer to and compare its behavior as an example.

  • MobilePush Key Points Summary: This document outlines basic operations and considerations for MobilePush. https://help.salesforce.com/s/articleView?id=000388835&type=1

  • Main Confirmation Methods for MobilePush Send Results and Differences in Values (Journey Builder Edition): Since the Journey Builder administration screen primarily displays results per contact, there can sometimes be confusion with the numbers in this report. If you are using Journey Builder for sends and want to understand the differences in values compared to the report, this article will be helpful. https://help.salesforce.com/s/articleView?id=000396496&type=1

Please note that MobilePush, app platforms, and various providers frequently update their SDKs, so the information above may occasionally differ from the latest versions.

 

Nummer des Knowledge-Artikels

002628213

 
Laden
Salesforce Help | Article