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

Wed May 14 11:23:12 EDT 2014

On Wed, May 14, 2014 at 4:48 PM, Burr Sutter <bsutter at redhat.com> wrote:

> I am interested in the sorting/filtering of the columns - how many send
> requests happened in the last hour, last day, last week
>

the filter might be on the more fancy side of things - at least I want a
normal table asap

> - how many installations were impacted by those requests - based on the
> aliases, categories, etc that were used.
>

yeah, see the initial data that we used in this thread :-)

>
> I don't recall a proposed UI/mockup/wireframes on this topic.
>

Hylke is working on that; we should be having something later this week

>
>
> On May 14, 2014, at 8:40 AM, Jay Balunas <jbalunas at redhat.com> wrote:
>
>
> On May 14, 2014, at 4:46 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> 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
>
>
> Makes sense as a first pass.  We're already logging this to file anyway
> iirc.
>
>
>
>>
>> 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).
>
>
> I thinking this would be the the data collected, what and how to show it
> would be part of the whole discussion.
>
>
> 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
>
>
> +1
>
>
>
>> 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
>
>
> I thought that was basically what we were going for - sort of a simple
> dashboard type page?  With the table you describe above and maybe a chart
> of messages sent over time or something like that?
>
> (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
>
>
> Very cool ideas for sure :-)
>
>
>> 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
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/acdfdf6e/attachment.html 