The Push Dashboard gives you a single view of the details, delivery status, and statistics of all registered campaigns.
You can search for the status and statistics of the campaigns sent for the game that the user who’s currently connected has authority over.
Select a date based on the delivery schedule (reserved), then select an app and a campaign. The delivery schedule is set to today’s date by default. All data will be displayed based on a daily unit. However, you can also view trend graphs of a repeated period by whole, country, and server in the respective campaign detail data interval for repetitive campaigns only.
You can check the whole data graph, no. of tokens, delivery, opening and registered campaigns of a specific day of the corresponding game.
The above map shows you the number of delivery (globally) on a specific day. The colored parts are where there’s a lot of delivery. If you put a cursor over, you can view the detailed information with via tooltip.
The above graph shows you the change in the token count on a specific day. The graph is refreshed on an hourly basis in real-time and you can predict the delivery amount based on the accumulated token amount especially when you have to send a bulk amount.
After selecting a game and date at the top, click Search to show results. You can click on a specific campaign to view its detailed data.
Click on the top-right Download Button to download the data as an excel file in a chart format.
Shows the total number of delivery, successful cases, open cases, and failed cases of the selected campaign of the day.
If the selected campaign is a single campaign that sends only one day, it will be displayed as a “dot” graph.
When you click on the graph area, you’ll see a graph of the success/ failure rate of the cases and the reason of failure for that date regarding the single campaign.
If the selected campaign is a recurring campaign that is sent over multiple days, it will be displayed as a “line” graph. For repeated campaigns, you can view data trends of the entire repeat interval, as well as a specific day at the top. The date selected at the top will be the standard date and the week containing the selected date from the entire delivery interval (default value) will be displayed in this area. Click on a specific date in the graph area to view details, such as success/ failure rate of the corresponding date and reason of failure graph at the bottom. If it’s a campaign that has been running for more than a week, you can click the [Previous Week] or [Next Week] Button on the right side of the title area to view results by week.
For the total amount of delivery on the day of the selected campaign, the results will display a pie graph of the success and failure rates. (Left)
The graph on the right shows the reason for the detailed failure and the ratio for the total number of failures of the day. On Google (FCM) and Apple (APNS), if there’s a failure regarding push notifications requested, it will return error codes so you can find out for what reasons it failed. Google (FCM) provides a total of 16 responses and Apple (APNS) provides 28 responses to errors. Hive Push provides users with a reason for failure so that users can find out about errors that aren’t system issues. An overview of each failed error code is shown below.
|MissingRegistration||Check that the request contains a registration token
(in the registration_id in a plain text message, or in the to or registration_ids field in JSON).
|Occurs when a token is omitted in the Payloads that sends to the FCM service|
|InvalidRegistration||Check the format of the registration token you pass to the server.
Make sure it matches the registration token the client app receives from registering with Firebase Notifications.
Do not truncate or add additional characters.
|Occurs when a token is not valid|
|NotRegistered||An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with FCM.
If the client app is automatically unregistered, which can happen if the user uninstalls the application.
For example, on iOS, if the APNS Feedback Service reported the APNS token as invalid.
If the registration token expires
(for example, Google might decide to refresh registration tokens, or the APNS token has expired for iOS devices).
If the client app is updated but the new version is not configured to receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
|Occurs if the app has been deleted|
|InvalidPackageName||Make sure the message was addressed to a registration token whose package name matches the value passed in the request.||Occurs when the app that requests to send push from the server and the token app do not match|
|MismatchSenderId||A registration token is tied to a certain group of senders. When a client app registers for FCM,
it must specify which senders are allowed to send messages.
You should use one of those sender IDs when sending messages to the client app.
If you switch to a different sender, the existing registration tokens won’t work.
|Occurs when the Sender ID that requests to send push from the server and the Sender ID that was used to create a token do not match|
|InvalidParameters||Check that the provided parameters have the right name and type.||Occurs when the Payloads that sends to the FCM service is not valid|
|MessageTooBig||Check that the total size of the payload data included in a message does not exceed FCM limits:
4096 bytes for most messages, or 2048 bytes in the case of messages to topics.
This includes both the keys and the values.
|Occurs when the size of Payloads that sends to the FCM service exceeds 4K|
|InvalidDataKey||Check that the payload data does not contain a key (such as from, or gcm, or any value prefixed by google) that is used internally by FCM.
Note that some words (such as collapse_key) are also used by FCM but are allowed in the payload,
in which case the payload value will be overridden by the FCM value.
|Occurs when the field name of Payloads that sends to the FCM service is not valid|
|Unavailable||The server couldn’t process the request in time.||FCM service error|
|InternalServerError||The server encountered an error while trying to process the request.||FCM service error|
|BadCollapsedId||The collapse identifier exceeds the maximum allowed size.||Occurs when a Collapsed ID for overwriting exceeds its maximum allowed size|
|BadDeviceToken||The specified device token was bad. Verify that the request contains a valid token
and that the token matches the environment.
|Occurs when a push token is not valid|
|MissingDeviceToken||The device token is not specified in the request :path.
Verify that the :path header contains the device token.
|Occurs when a token is omitted in the Payloads that sends to the APNS service|
|PayloadEmpty||The message payload was empty.||Occurs when the Payloads that sends to APNS service is omitted|
|BadCertificate||The certificate was bad.||Push certificate error|
|BadCertificateEnvironment||The client certificate was for the wrong environment.||App certificate error|
|Unregistered||The device token is inactive for the specified topic.||Occurs if the app has been deleted|
|PayloadTooLarge||The message payload was too large.||Occurs when the size of Payloads that sends to the APNS service exceeds 4K|
|TooManyRequests||Too many requests were made consecutively to the same device token.||Occurs when too many push deliveries have been requested with the same token|
|InternalServerError||An internal server error occurred.||APNS service error|
|ServiceUnavailable||The service is unavailable.||APNS service error|
|Shutdown||The server is shutting down.||APNS service error|
|Unregistered||The app instance associated with the registration ID is no longer available to receive messages.||Occurs when the app has been deleted|
|InvalidRegistrationId||The registration ID does not correspond to the sender identified by the provided access token.||Occurs when a token is not valid|
|InvalidData||–||Occurs when the Payloads that sends to the ADM service is not valid|
|AccessTokenExpired||The access token provided was invalid.
The sender should refresh their access token.
|Server certified token expiration|
|MessageTooLarge||The message payload provided in the data parameter exceeded the maximum allowable data size (6 KB).||Occurs when the size of Payloads that sends to the ADM service exceeds 6K|
|MaxRateExceeded||The requester has exceeded their maximum allowable rate of messages.
The sender might retry later honoring the Retry-After header included in the response.
To ensure high availability, ADM limits the number of messages that can be sent over a given period of time.
|Occurs when too many push deliveries have at been requested the same time|
|InternalServerError||There was an internal server error.||Returns HTTP code 500 due to the ADM service error|
|Unavaiable||The server is temporarily unavailable.||Returns HTTP code 500 due to the ADM service error|
|Error code||Error Message||ETC|
|190||Invalid OAuth access token signature.||Occurs when the app_secret and app_id values registered in the App Center are incorrect|
|100||Param body must be at least 10 characters long.||Notification that occurs when the body text is 10 characters or less|
|Param title must be at most 30 characters long.||Notification that occurs when the title is 30 characters or more|
|Param body must be at most 180 characters long.||Notification that occurs when the body text is 180 characters or more|
|Param media is not a valid URI.||Notification that occurs when an invalid image URI is entered|
|613||Only 5 notifications can be sent to a user since they last played.||Notification that occurs when the limit on the number of notification API calls are exceeded|
Please refer to the URL below for the developer’s guide provided by Google, Apple, Amazon and Facebook.
※Error response code guide provided by Google (FCM), Apple (APNS), Amazon (ADM) and Facebook
Downstream message error response codes from FCM : [Go]
HTTP/2 Response from APNs : [Go]
Response format from ADM : [Go]
Graph API error handle from Facebook : [Go]
The left graph shows you delivery info by country and the right graph shows you delivery info by server.
Shows the number of deliveries, successful cases, open cases, and failed cases by server or country of a specific day of the selected campaign. By default, the server or country with most deliveries will be displayed first since there can be many countries or servers to where delivery has been made. If there’s at least one server or a country to where the delivery has been made, you can use the multi-select at the top to expose 2 or more data graphs at the same time and compare them.
Select a specific campaign at the top to display. Campaigns differ in the number of Tasks corresponding to actual work depending on whether you selecting bulk delivery or not. In case of bulk delivery, there’s only one task because cases are sent at once based on KST, without considering the time difference between country and time zone. In contrast, if bulk delivery is not selected, up to 24 tasks can exist because they are sent sequentially according to the specified time by country and time zone.
In this section, you can view the details of each Task of the selected campaign. You must click and select a certain task to view data as below.
Shows you delivery info of a selected task by country or server.
Shows you delivery info of a selected task by AppID.
The left pie graph shows you the success and failure rate for the selected task, regarding the total delivery of the day.
The table on the right shows you the reason for the detailed failure and the percentage for the total number of failures on the selected day. The detailed description of the failure cause error code is the same as the failure cause graph interval of the entire campaign at the top.
If there are 10 failed cases in a campaign and 8 of them have occurred on a particular task, you can check it in this section and find out why they have failed.
If you didn’t use bulk delivery, and the task was sent to Korea, and the reason for failure was mostly because of deleted apps, you can assume that there are more users who deleted apps in Korea compared to the other countries.