[aerogear-dev] [UnifiedPush Server] Analytics / Metrics

Mon Apr 7 14:16:01 EDT 2014

Meanwhile I thing it's very good the idea of opening a thread just about
the geo-fencing subject.

On Mon, Apr 7, 2014 at 6:53 PM, Miiguel Lemos <miguel21op at gmail.com> wrote:

> About geo-fencing, yes you are right: it's critical! Now I've not spare
> time for it but one of these days I'll come back with what I think about
> this, and what should /  must be done, and why (in the user / service point
> of view).
>
> See ya ;)
>
> Enviado do meu iPad
>
> No dia 07/04/2014, às 14:54, Burr Sutter <bsutter at redhat.com> escreveu:
>
>
> On Apr 7, 2014, at 9:00 AM, Miguel Lemos <miguel21op at gmail.com> wrote:
>
> Yes, my friend. But the variety of what customers need is so wide, that
> you'll never meet all demands.
>
> I see your service being used in the scope - in one end - of a full
> customized service that developers must build. The developers are supposed
> to develop. For instance in my case, i'll be happy if I know if the message
> has been forwarded to Google or Apple service. The filtering (analytics)
> you offer is too narrow, but I don't complain about it...
>
>
> At this time, we do not tell the user if the message was forwarded or not
> - the UI has no indication that a message has moved through the system.  A
> newbie would like to know that something happened.  Some basic
> metrics/analytics is helpful to giving a new user that warm-fuzzy feeling
> that the UPS is actually doing something, even if the push message does not
> make it out to the phone itself.
>
>
> On the other hand, your core service has yet some things that must be
> fixed / perfectionated (I'm talking only about Cordova). I also think that
> you should consider geo-tagged notifications, which is a very important
> need.
>
> I agree - but these things are not necessarily mutually exclusive :-)
>
> On the Cordova side of things, I would like to know more about what needs
> fine-tuning.  Docs? definitely need work
> And our push plugin is a wee bit fat for Android, needs to go on a diet,
> dexing takes a while
> And the JS API needed some clean-up, you have seen Erik's proposals on
> that item
>
> We should have a thread to more fully flesh out geo-tagging/geo-fencing
> requirements - I also love that idea/feature and think it is critical.  I
> know that Erik already produced an early prototype but I have not yet
> explored how it works, to see if it is cross-platform, battery efficient
> and relatively accurate (within a few KM of distance).
>
>
>
> IMHO the solutions Mathias wrote for using it some weeks ago (the phone
> sending its location to the server) is not the best one...
>
>
> Was this in the Aerodoc example?  I can see a scenario where a developer
> would want this - basically, allow the end-user to set his "home"
> geo-location and perhaps "work" geo-location and not attempt to track the
> physical movement of the phone on a recurring basis.    For instance, a
> sales rep often has specific geographic boundary that he works within (as
> seen in Aerodoc) but a consumer, visiting different malls, does not.
>
>
> But, again, this is only a opinion, the work you are doing so far is
> great, and I much appreciate it.
>
>
> Cheers
>
> Miguel
>
>
>
> On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter <bsutter at redhat.com> wrote:
>
>>
>> On Apr 7, 2014, at 8:16 AM, Miguel Lemos <miguel21op at gmail.com> wrote:
>>
>> I think developers must build their own back-ends and keep track of what
>> they do.
>>
>>
>> While I agree in theory, it is more difficult in practice.  A single push
>> server may be used by several developers across several different app
>> teams, in that case, you will want some metrics/logging captured at the
>> central point.  Any given developer/team may misbehave quite badly.   Our
>> experience with multi-developer services has demonstrated that customers
>> like having centralized logging/metric capture.
>>
>>
>> This will be always the more flexible solution.
>>
>> IMHO you must focus on the core of building a reliable and powerful push
>> send service (includind the documentation part).
>>
>> Enviado do meu iPhone
>>
>> No dia 07/04/2014, às 13:09, Burr Sutter <bsutter at redhat.com> escreveu:
>>
>>
>> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>> Hello,
>>
>> for a first round of collection some more data around the usage of the
>> push server (aka analytics/metrics), I'd propose we keep it very simple.
>>
>> Overall, I see one major area of interest:
>> *metrics around push messages being sent:
>> - time of sending (using timezone of the server?)
>>
>> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias,
>> categories,...))
>> - payload (the entire payload, including custom keys - not only alert,
>> sound, badge etc)
>>
>> As a developer, I wish to know if my 3 test devices all registered
>> properly.
>> As a developer, I wish to know if the push notification was sent to all 3
>> test devices properly (at least delivered to Apple/Google properly)
>> As a developer, I would like to know what were my past messages
>> As a push administrator, a business unit representative (e.g head of
>> sales, warehouse manager) is going ask me if a particular message was sent
>> to a particular user (alias) or user group (aliases or category).
>>
>>
>> This is a nice feature, and would enrich the UPS.
>>
>>
>> However, I can see also some interest around device specific metrics:
>>
>> Today we obivously store all the registered devices, but we also remove
>> them from the database table if needed (to not send messages to phones that
>> would no longer receive them anyways).
>>
>> I can see people wanting to just archive instead of delete those records
>> - interesting data points would be:
>> - any commonality in device type
>> - a trend in date/time of removal
>> - ratio of added/removed (user opted in vs out)
>>
>> Is it possible to distinguish between app uninstall vs push notification
>> disable (where the app remains installed)?
>>
>>
>> Something that would be interesting as well, might be the following data:
>> - how often was an app has reached the push server  (note: every time the
>> app starts, the metadata of the server is being updated (see [2])
>>
>> would this be a good proxy for letting me know how often an end-user is
>> using the app?
>>
>> - number of device-tokens / registrationIDs that have been removed, when
>> receiving errors from Apple/Google (see [3] or [4])
>> - number of devices, that were activly removed using our APIs (supported
>> only on Android/SimplePush due to Apple policy, see [5])
>>
>>
>> While the initial focus should be around the message related metrics,
>> capturing some device data is nice too.
>>
>>
>> Any thoughts ?
>>
>> -Matthias
>>
>>
>> PS: Oh, for the longer run(...), I'd also like to see metrics like "was
>> mobile app opened due to a push notification". BUT that also requires some
>> more work/reseach on the client Push SDKs. But seriously, this is not a
>> priority for the next few months!
>>
>>
>>
>>
>> [1] https://issues.jboss.org/browse/AGPUSH-116
>> [2]
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112
>> [3]
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94
>> [4]
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94
>> [5]
>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119
>>
>>
>> --
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/9e1977e5/attachment-0001.html 