On Wed, Apr 8, 2015 at 3:58 PM, Andres Galante <agalante(a)redhat.com> wrote:
There will be more stats for each notification. The idea is to have
a
general view on the App analytics and more detail numbers on each
notification.
I don't know how "intelligent" they can be. First crawl, then walk, then
run. Lets crawl and get the most we can with the numbers we have.
We can do some clever stuff with performance ratios, and I trying to
figure out which ratio is useful and which isn't.
that would be a split per variant (since you can not have APNs and GCM on
one variant)
On Wed, Apr 8, 2015 at 10:51 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Thanks for the changed UI
>
> I think we also have the notion to track a specifc push message "Show
> this by Friday, and get 5% discount".
> I think what I'd like to see is, on the current UI, you click a specific
> push message, to get more details: here would be the right spot to see 2k
> opened due to push
>
> On Wed, Apr 8, 2015 at 3:44 PM, Andres Galante <agalante(a)redhat.com>
> wrote:
>
>> Yes, you are right, it should be something like:
>>
>> 5 message sent
>> 3k delivered
>> 2k open
>> 4k devices.
>>
>> Just change the example. Also the x-axis should be dates.
>>
>> Thanks!
>>
>>
>>
>>
>> On Wed, Apr 8, 2015 at 10:32 AM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>> One thing: I think the numbers on the chart are confusing, and
>>> incorrect.
>>> It's usually not a ton of messages that are sent. that's more like 5
or
>>> 10 per day (speaking of vanilla marketing pushes). If more, I'd
UNINSTALL
>>> the damn app.
>>> Therefore the "app opened due to receiving push" numbers are also
not
>>> 100% correct here.
>>>
>>> On Wed, Apr 8, 2015 at 2:59 PM, Matthias Wessendorf
<matzew(a)apache.org>
>>> wrote:
>>>
>>>> :-) I like that too.
>>>>
>>>> But Andres, again, awesome UX !
>>>>
>>>> On Wed, Apr 8, 2015 at 2:46 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 8, 2015 at 2:37 PM, Lukáš Fryč
<lukas.fryc(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Looks good so far, Andres,
>>>>>>
>>>>>> you are right, we want to show time-aggregated data, not
particular
>>>>>> events.
>>>>>>
>>>>>> Idea:
>>>>>> My perspective might be very technical rather then marketing, but
a
>>>>>> pie chart with Push Network split would be interesting to me.
>>>>>>
>>>>> +1 (or Donut :) )
>>>>>
>>>>>>
>>>>>> st 8. 4. 2015 v 14:12 odesílatel Andres Galante
<agalante(a)redhat.com>
>>>>>> napsal:
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> With the new data we have I've compared sent vs open
messages on a
>>>>>>> chart for each App:
>>>>>>>
>>>>>>>
https://rawgit.com/andresgalante/UPS/master/app-detail-analytics.html
>>>>>>> (the x axis should be dates)
>>>>>>>
>>>>>>> I am wondering if we can generate a ratio that's useful
for a
>>>>>>> marketing person and show a benchmark comparing with other
UPS users to
>>>>>>> know if the users campaign is successful or not. Something
like: open/sent
>>>>>>> or device/open
>>>>>>>
>>>>>>> I believe that to show the first and last time a message was
open
>>>>>>> is not very useful. Maybe I am wrong, but, If we want to show
an over time
>>>>>>> chart for each notification we should collect periodical
data, for example
>>>>>>> # of open messages per hour to generate a linear graph that
represents a
>>>>>>> day.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 5:00 PM, Sébastien Blanc <
>>>>>>> scm.blanc(a)gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Envoyé de mon iPhone
>>>>>>>>
>>>>>>>> Le 30 mars 2015 à 21:31, Daniel Passos
<dpassos(a)redhat.com> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>> On Mon, Mar 30, 2015 at 12:29 PM, Sebastien Blanc <
>>>>>>>> scm.blanc(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Folks !
>>>>>>>>>
>>>>>>>>> For AGPUSH-969[1] and to kick off the discussions, I
started a
>>>>>>>>> small POC mainly focused on the backend. To sum up
quickly : we want to
>>>>>>>>> know how many installations/users has opened the
application after that a
>>>>>>>>> Push Notification has been touched.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Let me see if I understood. UPS will send a message to
the client
>>>>>>>> and when the message be *read* (instead of delivered),
the client will send
>>>>>>>> a message back to the UPS saying: "The message was
read"?
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes , but let me be more specific here : us when the app
is in the
>>>>>>>> background or not running and that the user
"tap" the notification
>>>>>>>>
>>>>>>>> So, the very first thing that had to be done was to give
the Push
>>>>>>>>> Notification a unique identifier, so that we can
track it and do the
>>>>>>>>> metrics on it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1. Not only us (UPS) but also the backend app
>>>>>>>>
>>>>>>>>
>>>>>>>>> For that, I have been using an existing model object
that we have
>>>>>>>>> , the PushMessageInformation[2], and that is
currently used to provide
>>>>>>>>> information for our dashboard.
>>>>>>>>> This object has now some extra fields, like a
appOpenCounter etc
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> The ID of this PushMessageInformation is now passed
into the
>>>>>>>>> payload of the Push Message, just before we send it,
this way the client
>>>>>>>>> library can use this ID to pass extra information to
the UPS when a
>>>>>>>>> notification is touched.
>>>>>>>>> For this POC, I hijacked the cordova-helloworld, so
that it
>>>>>>>>> extracts the ID from the payload and pass it as
header when registering.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The message back (from client to UPS) will be send every
time the
>>>>>>>> user _read_ that?
>>>>>>>>
>>>>>>>> Well normally that will only happen once per installation
per Push
>>>>>>>> message
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> When the UPS receive the request, it looks for the
header and if
>>>>>>>>> it exist it updates the existing
PushMessageInformation instance.
>>>>>>>>>
>>>>>>>>> Please note, that for this POC, all is happening on
Application
>>>>>>>>> level and not on Variant level but that can be easily
changed. It depends
>>>>>>>>> on how fined grained we want to have these
analytics.
>>>>>>>>>
>>>>>>>>> I did a small screencast that shows this in action :
>>>>>>>>>
https://www.youtube.com/watch?v=PseBBJZLz6s&feature=youtu.be
>>>>>>>>>
>>>>>>>>> The UPS branch containing the changes is here (the 2
latests
>>>>>>>>> commits are relevant) :
>>>>>>>>>
https://github.com/sebastienblanc/aerogear-unified-push-server/tree/analy...
>>>>>>>>>
>>>>>>>>> The client app is not really relevant since I really
hacked badly
>>>>>>>>> the app (and the push plugin) ;) , however if
interested I may share it.
>>>>>>>>>
>>>>>>>>> Now, let's discuss :)
>>>>>>>>>
>>>>>>>>> Sebi
>>>>>>>>>
>>>>>>>>> [1]
https://issues.jboss.org/browse/AGPUSH-969
>>>>>>>>> [2]
>>>>>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model...
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -- Passos
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog:
http://matthiaswessendorf.wordpress.com/
>>>> sessions:
http://www.slideshare.net/mwessendorf
>>>> twitter:
http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>
>
>
> --
> 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