[TIMOB-18957] As a platform customer, I want to track times a push has been received and times opened
| GitHub Issue | n/a |
|---|---|
| Type | Story |
| Priority | High |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Cloud |
| Labels | n/a |
| Reporter | Gabriel Tavridis |
| Assignee | Unknown |
| Created | 2013-12-20T03:31:50.000+0000 |
| Updated | 2018-02-28T19:55:40.000+0000 |
Description
As a platform customer, I want to know for every push notification I sent, the amount of people I sent it to, number of times it reached the user's device and the numbers of times the user opened it. I want to know the OS, OS version, device, and location of the user at the time he received and/or opened the push notification. This information will be surfaced on the Dashboard in the following way:
1. track open rates by device,os, os version (opened/received)
1.1 for one push and for a range of pushes within a period of time
2. track success rate by device,os, os version (received/sent)
2.1 for one push and for a range of pushes within a period of time
This feature is available only to Appcelerator Platform customers
[~gtavridis] we don't have control over how soon a push can be sent to a device since it is done by either GCM or APN. Additionally, neither of those services provided a way to track such info before a device can be down for an extended period of time and each service would retry for a certain period of time before giving up. What is the reason that we need to provide such info? I'm afraid this is not possible.
One of the most valuable metrics for measuring the success of push campaigns are open rates. We should enable developers to track this without relying on what GCM/APNS support.. E.g. when the user opens a push notification we make an API call to the ACS backend marking the push as opened. We would also send some metadata (client os version, app version, client device, timestamp opened. This would update a flag in the push notification record. In turn we will be able to run analytics on top of it. (cc [~ngupta])
This should be done on device side by sending relevant info to pem