[aerogear-dev] [UPS] UI for Sent Push stats

Wed May 14 04:46:35 EDT 2014

On Tue, May 13, 2014 at 10:23 PM, Jay Balunas <jbalunas at 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 at 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%20Server/Export/6.png
> [2]
> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/3.png
>
>
>  --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>  _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140514/1fa5ef1e/attachment.html 