Hi,
With the new data we have I've compared sent vs open messages on a chart
for each App:
(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