Hello, for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. Overall, I see one major area of interest: *metrics around push messages being sent: - time of sending (using timezone of the server?) - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) - payload (the entire payload, including custom keys - not only alert, sound, badge etc)

This is a nice feature, and would enrich the UPS.

However, I can see also some interest around device specific metrics: Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). Something that would be interesting as well, might be the following data: - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5])

While the initial focus should be around the message related metrics, capturing some device data is nice too. Any thoughts ? -Matthias PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! [1] https://issues.jboss.org/browse/AGPUSH-116 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Sounds good ! Some comments inline On Mon, Apr 7, 2014 at 7:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hello, for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. Overall, I see one major area of interest: *metrics around push messages being sent: - time of sending (using timezone of the server?) - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) - payload (the entire payload, including custom keys - not only alert, sound, badge etc) + Response / Status of the submitted message I suppose (response status to the "sender" and info it's has been dispatched to the 3rd Push network) ? It would also be nice to see who has initiated the send request : cURL, backend app or Compose Message Page ? Not sure how to do this but could be useful IMO.

This is a nice feature, and would enrich the UPS. For sure. But how will someone access these metrics ? Is the plan to have some kind of metric/usage page (with charts etc ...) on the console and/or just raw data in the form of json/xml/txt ? However, I can see also some interest around device specific metrics: Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). Something that would be interesting as well, might be the following data: - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) Yes, that is a tricky one even going beyond the scope of metrics. For instance with Android there is no way to unregister when you desinstall the app. While the initial focus should be around the message related metrics, capturing some device data is nice too. Any thoughts ? -Matthias PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! [1] https://issues.jboss.org/browse/AGPUSH-116 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > Hello, > > for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) > - payload (the entire payload, including custom keys - not only alert, sound, badge etc) As a developer, I wish to know if my 3 test devices all registered properly. As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) As a developer, I would like to know what were my past messages As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). > > This is a nice feature, and would enrich the UPS. > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). I can see people wanting to just archive instead of delete those records - interesting data points would be: - any commonality in device type - a trend in date/time of removal - ratio of added/removed (user opted in vs out) Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) would this be a good proxy for letting me know how often an end-user is using the app? > - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) > > > While the initial focus should be around the message related metrics, capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... > [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... > [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Apr 7, 2014, at 8:16 AM, Miguel Lemos <miguel21op(a)gmail.com&gt; wrote: I think developers must build their own back-ends and keep track of what they do. While I agree in theory, it is more difficult in practice. A single push server may be used by several developers across several different app teams, in that case, you will want some metrics/logging captured at the central point. Any given developer/team may misbehave quite badly. Our experience with multi-developer services has demonstrated that customers like having centralized logging/metric capture. This will be always the more flexible solution. IMHO you must focus on the core of building a reliable and powerful push send service (includind the documentation part). Enviado do meu iPhone No dia 07/04/2014, às 13:09, Burr Sutter <bsutter(a)redhat.com&gt; escreveu: On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hello, for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. Overall, I see one major area of interest: *metrics around push messages being sent: - time of sending (using timezone of the server?) - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) - payload (the entire payload, including custom keys - not only alert, sound, badge etc) As a developer, I wish to know if my 3 test devices all registered properly. As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) As a developer, I would like to know what were my past messages As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). This is a nice feature, and would enrich the UPS. However, I can see also some interest around device specific metrics: Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). I can see people wanting to just archive instead of delete those records - interesting data points would be: - any commonality in device type - a trend in date/time of removal - ratio of added/removed (user opted in vs out) Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? Something that would be interesting as well, might be the following data: - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) would this be a good proxy for letting me know how often an end-user is using the app? - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) While the initial focus should be around the message related metrics, capturing some device data is nice too. Any thoughts ? -Matthias PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! [1] https://issues.jboss.org/browse/AGPUSH-116 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> > On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. I agree - but these things are not necessarily mutually exclusive :-)

On the Cordova side of things, I would like to know more about what needs fine-tuning. Docs? definitely need work And our push plugin is a wee bit fat for Android, needs to go on a diet, dexing takes a while

And the JS API needed some clean-up, you have seen Erik's proposals on that item

About geo-fencing, yes you are right: it's critical! Now I've not spare time for it but one of these days I'll come back with what I think about this, and what should / must be done, and why (in the user / service point of view). See ya ;) Enviado do meu iPad No dia 07/04/2014, às 14:54, Burr Sutter <bsutter(a)redhat.com&gt; escreveu: On Apr 7, 2014, at 9:00 AM, Miguel Lemos <miguel21op(a)gmail.com&gt; wrote: Yes, my friend. But the variety of what customers need is so wide, that you'll never meet all demands. I see your service being used in the scope - in one end - of a full customized service that developers must build. The developers are supposed to develop. For instance in my case, i'll be happy if I know if the message has been forwarded to Google or Apple service. The filtering (analytics) you offer is too narrow, but I don't complain about it... At this time, we do not tell the user if the message was forwarded or not - the UI has no indication that a message has moved through the system. A newbie would like to know that something happened. Some basic metrics/analytics is helpful to giving a new user that warm-fuzzy feeling that the UPS is actually doing something, even if the push message does not make it out to the phone itself. On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. I agree - but these things are not necessarily mutually exclusive :-) On the Cordova side of things, I would like to know more about what needs fine-tuning. Docs? definitely need work And our push plugin is a wee bit fat for Android, needs to go on a diet, dexing takes a while And the JS API needed some clean-up, you have seen Erik's proposals on that item We should have a thread to more fully flesh out geo-tagging/geo-fencing requirements - I also love that idea/feature and think it is critical. I know that Erik already produced an early prototype but I have not yet explored how it works, to see if it is cross-platform, battery efficient and relatively accurate (within a few KM of distance). IMHO the solutions Mathias wrote for using it some weeks ago (the phone sending its location to the server) is not the best one... Was this in the Aerodoc example? I can see a scenario where a developer would want this - basically, allow the end-user to set his "home" geo-location and perhaps "work" geo-location and not attempt to track the physical movement of the phone on a recurring basis. For instance, a sales rep often has specific geographic boundary that he works within (as seen in Aerodoc) but a consumer, visiting different malls, does not. But, again, this is only a opinion, the work you are doing so far is great, and I much appreciate it. Cheers Miguel On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter <bsutter(a)redhat.com&gt; wrote: > > On Apr 7, 2014, at 8:16 AM, Miguel Lemos <miguel21op(a)gmail.com&gt; wrote: > > I think developers must build their own back-ends and keep track of what > they do. > > > While I agree in theory, it is more difficult in practice. A single push > server may be used by several developers across several different app > teams, in that case, you will want some metrics/logging captured at the > central point. Any given developer/team may misbehave quite badly. Our > experience with multi-developer services has demonstrated that customers > like having centralized logging/metric capture. > > > This will be always the more flexible solution. > > IMHO you must focus on the core of building a reliable and powerful push > send service (includind the documentation part). > > Enviado do meu iPhone > > No dia 07/04/2014, às 13:09, Burr Sutter <bsutter(a)redhat.com&gt; escreveu: > > > On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hello, > > for a first round of collection some more data around the usage of the > push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, > categories,...)) > - payload (the entire payload, including custom keys - not only alert, > sound, badge etc) > > As a developer, I wish to know if my 3 test devices all registered > properly. > As a developer, I wish to know if the push notification was sent to all 3 > test devices properly (at least delivered to Apple/Google properly) > As a developer, I would like to know what were my past messages > As a push administrator, a business unit representative (e.g head of > sales, warehouse manager) is going ask me if a particular message was sent > to a particular user (alias) or user group (aliases or category). > > > This is a nice feature, and would enrich the UPS. > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove > them from the database table if needed (to not send messages to phones that > would no longer receive them anyways). > > I can see people wanting to just archive instead of delete those records > - interesting data points would be: > - any commonality in device type > - a trend in date/time of removal > - ratio of added/removed (user opted in vs out) > > Is it possible to distinguish between app uninstall vs push notification > disable (where the app remains installed)? > > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the > app starts, the metadata of the server is being updated (see [2]) > > would this be a good proxy for letting me know how often an end-user is > using the app? > > - number of device-tokens / registrationIDs that have been removed, when > receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported > only on Android/SimplePush due to Apple policy, see [5]) > > > While the initial focus should be around the message related metrics, > capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was > mobile app opened due to a push notification". BUT that also requires some > more work/reseach on the client Push SDKs. But seriously, this is not a > priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/... > [5] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev