FAQs
Frequently Asked Questions about App Push Notification.
Q1. What is the reason for the drop in push notifications?
Drop in push tokens could be due to the below reasons,
Token not passed to the Lemnisk SDK- If the push notification implementation is incorrect, the token is not passed to the Lemnisk SDK.
Push notification access not granted- If the user chooses "Don't allow" when prompted for permission to receive push notifications.
Network connectivity- If the device connection is poor or not connected to any network.
Solutions :
Make sure the Push Notification is implemented correctly first. Ensure that you correctly register your app for push notifications. Check that you received a device token when attempting to register for remote notification, and sent the same information to the SDK.
Send a test campaign to the targeted device to verify. Check Common failure metrics for the error description if one is received.
Check to see if notification settings for the app were turned off if the test campaign was sent successfully but the notification was not received on the device.
Q2. What makes the push notifications non-deliverable?
Here are the few common reasons that make your push notifications non- deliverable.
Notifications blocked at the OS level:
Users have the option to disable a specific app's notification in operating systems. The problem with this implementation is that GCM won’t invalidate the token and it will not inform the app server about this temporary de-activation. Additionally, some battery-saving applications force stop the currently running applications, which prevents them from sending notifications to the user's device.
Device-specific Issues:
Some devices will not receive notifications when apps are not running in the foreground or background. This issue is gradually being fixed by its manufacturers.
User not connected to FCM due to network issues:
A lot of customers are not connected to the Internet for a long time and hence GCM cannot deliver notifications to them as well as cannot mark them inactive. The GCM cannot deliver notifications to users who are not connected to the internet and cannot mark them inactive.GCM maintains an idle connection from Android devices to Google’s servers. To ensure the connection is active, Google sends a signal every 15 minutes. If the signal is not received, the connection is considered broken and Google tries to re-establish it. This results in delays in messages and non-delivery.
Time to Live (TTL) expires:
FCM may not be able to connect with the device within the TTL time. This results in the non-delivery of messages as the TTL expires.
The gap from GCM in marking the token as inactive:
There is a gap between the time the device is uninstalled and FCM marking the device as inactive. As a result, we might successfully send the notification to FCM without knowing the status of the app on the user's device which won’t be delivered.
Q3. Why some push notifications are queued?
Your messages sent to the campaign target audiences might be queued due to the DND hours or because of frequency cap settings. The notification might be delivered when the device is in Do Not Disturb Mode (DND) or the frequency cap may have been exhausted for that particular user.
Q4. What is a Silent Push Notification?
Silent push notifications can be sent to the applications that the user has installed. These notifications remain hidden by popping out some information in the application with the content that can be downloaded in the background. Any application can leverage the silent push notification to trigger the user about new updates or any other information.
In Lemnisk, we enable silent push notifications to track the uninstalls of your application by triggering the notification once a day. The devices which did not receive notification will be considered as uninstalled devices.
Q5. Why App Push Notification may not get delivered?
Frequency Caps: This failure occurs when the frequency cap limit is exhausted. It depends on parameters that are measured daily, weekly, monthly, or over a lifetime. Users whose frequency cap value is >0 will receive your engagement. To learn more about Frequency Caps, click here.
Personalization Failure: This failure indicates that the engagement failed to send while replacing the personalizing parameters with the actual value stored in the users profile. Use Case: Suppose there is a user in a segment with no premium amount registered. You create engagement for that segment of users using a premium amount macro with an expiration date. The user with no registered amount will not receive the engagement as that parameter does not exist in his/her stored profile.
Last updated