On Tue, May 13, 2014 at 10:23 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
Wanted to chime in here. The overall goal of the metrics/stats imo,
is
around letting developers/administrators know what is happening with the
server. Messages in/out, registrations, etc.... This will also help new
developers see activity and do some basic debugging if devices fail to
register or messages fail to send.
Maybe in the future we'll get into more analytics, resource usage type
stuff but for Mobile Push 1.0 I think this is overkill. For example I
would not expect us to store this data over 30 days or so, and have viewing
options like "last hour", "last 24 hours", "yesterday",
"last 7 days",
etc...
yeah - a simple history of messages sent
Building on what Matthias posted below, here are some breakdowns of stats
we could/should track:
Registration:
-- Device registered with [x,y,z] metadata
-- Device removed with [x,y,z] metadata
let's focus on message sent stats for now
Messages:
-- Push request <timestamp-id> received from [ip] with [x,y,z] metadata
-- Push request <timestamp-id> matched XYZ devices and sent [ AB: APNS, CD
GCM, etc...]
-- Push request <timestamp-id> had foo errors : details
Yes, these are nice items for the details once you click on a push message
in that 'history table view' (e.g. IP address, full criteria, error
details, etc).
The table itself could be really simple:
* time of sending
* content/payload of the message
* could be sent out to (e.g. a status icon *green/red*)
Once a user clicks an entry, we would display more details
These would all have app and variant info as part of the metadata so
they
can filtered/broken down as needed.
This should give us a great base for all kinds of table and chart views.
-- Registrations over time for the server, specific app, specific variant
-- Messages over time for the server, specific app, specific variant
-- Table of the above if feasible :-)
yeah, all that is good - but IMO more a dashboard (e.g. over time we could
also show how often an app has been launched (per variant) - and with some
work on the registration SDKs, we could (not 1.0) show how often an app has
been opened by a push
Obviously we may need to scale down as needed, and discuss more, but this
is what I was thinking about.
Thoughts?
On May 13, 2014, at 4:47 AM, Hylke Bons <hbons(a)redhat.com> wrote:
Hello,
Depending on the use case, it may even deserve its own spot in the
sidebar. Like already mentioned on the thread, it's better to keep the
number of items there fixed. We may have have several entry points to the
logs, and an overview of some statistics can be useful as a landing page
before going into "Applications".
Let's step back for a moment before looking at the UI: What are we trying
to solve by providing a log?
- Let administrators know everything is going well? (or, that there was a
problem?)
- Looking at resources used? Bandwidth, costs?
- App adoption/growth numbers over time? How well is my app doing?
I'm not sure about the technical possibilities. Thoughts?
Thanks,
Hylke
On 07/05/2014 10:54, Matthias Wessendorf wrote:
Hi,
as discussed , we need some sort of 'stats' around push, like:
* time of sending
* receivers (e.g. categories, alias ?)
* content/payload of the message
* could be sent out to APNs/GCM
But, where, or how to add this ?
My current thought is:
When a user did select an "Application", he enters the "Application
Details Page" (see [1]), now here, on the sidebar (see [2]) he would see
the "Notifications" icon.
Clicking on that "Notifications" icon, would give you a new page, that
contains the "Send Notifications..." button (currently located in [1]), and
a table of all the push messages that were sent out for the _current_
selected Application.
Any thoughts ?
-Matthias
[1]
https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Ser...
[2]
https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Ser...
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf