Re: [aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics, new PR and call to the client tech leads)

On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > Envoyé de mon iPhone > > Le 6 mai 2015 à 11:38, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : > > Hi, > > as discussed on the previous thread, there will be a new endpoint to > 'track' the "App opened/launched due to received push notification". > > Internally, on the UPS, the Push Message has an ID, which get's append to > the payload of the notification, like here: > > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... > > On the client SDKs this will be read and a HTTP call made to the soon > introduced MetricsEndpoint. Currently this info is send to the > RegistrationEndpoint, including the deviceToken/registrationId. However, I > think that the deviceToken/registrationId is currently not needed for > metrics, since we are just interested in anonymous "app launched/opened due > to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet > open". > > So all we really need is the ID of the push notification, to be processed > by our Metrics Service > > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > > Therefore my proposal is have an endpoint: > > PUT /metrics/pushmessage/{pushMessageID} > > I think PUT is good/best, because there is nothing really created on the > server, it's more updating the 'counter' on the existing > PushMessageInformation object. > > Thoughts? > > Let's make sure it's still protected by basic auth using the variantId, > we need to know which variant is hit. > yes :-) > > Skipping the registration endpoint we might miss metadata, like os > version etc ... But for this first version it should not be a issue. > I think that would be nice to have percentage of OS/OS version - it would be not too hard to have that included.

Are we, today, are already having a relationship between "app opened" and OS/OS_version? I don't really see that on the PR > -Matthias > > > On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> >> >> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >> wrote: >> >>> To give a bit of background on this background to foreground issue :)) >>> >>> Push Cordova plugin matches Cordova life cycle by storing some >>> information locally see: >>> >>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >>> Doing so allows you to call multiple time registration, even when an >>> app comes back from background to foreground. you can do it because you >>> have stored locally all the information neede for registration. >>> >>> But when dealing directly with native apps, the life cycle does not >>> always goes through a registration. >>> >>> To sort out this issue,we can: >>> - either store locally at the ios-push lib level instead of doing it in >>> Cordova plugin and then call registration API on all delegate methods (even >>> though we don't want to register but just send the metrics) >>> >> >> based on summers comments, I thought about this - perhaps this is the >> way to go. >> For sending metrics, we do not need to run the registration again, with >> the new endpoint in place. The iOS push SDK could call a (private) method >> and just deliver the metrics related info - that's splits the concerns and >> removes the need to call register endpoint on places where we do not really >> need it >> >> -M >> >> >> >> >>> - or leave the ios-push lib without any storage and provide a separate >>> endpoint for sending metrics or changing categories. >>> >>> I'd go for the second option. >>> >>> ++ >>> Corinne >>> >>> >>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >>> >>>> I agree with this and maybe we want even more functionality moved, >>>> because also updating the categories is strange in a 'register' >>>> method. Say for instance you want to change the categories your >>>> interested in a developer has to call register again? And if I >>>> understand Corinnes mail that will currently not even work on iOS. >>>> >>>> For cordova I store the device info, because the lifecycle is >>>> different, but that is okay it's an integration problem. >>>> >>>> So updating the installation details should be a separate method that >>>> also contains updating the categories. That way we have a better split >>>> between a device that registers itself with UPS and updating the >>>> subscription data. >>>> >>>> >>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> > Hello Sebi, >>>> > >>>> > >>>> > I've done an initial work on aerogear-ios-push [swift branch], >>>> adding a new >>>> > parameter when doing the registration to pass the ag-push-id. See: >>>> > >>>> > >>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>>> > >>>> > This client could be tested with HelloWorld. See: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>>> > >>>> > What is not covered is the background app coming to foreground >>>> through a >>>> > push notification. If you look at HelloWorld: >>>> > >>>> > >>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>>> > >>>> > In iOS, when we go from background to foreground we don't go through >>>> > registration API. The iOS push lib doesn't store locally (as opposed >>>> to >>>> > windows sdk for ex) the device information. So i can't really make >>>> another >>>> > call to registration API. What i'd suggest is to have a separate >>>> endpoint >>>> > for metrics instead of having it coupled with registration endpoint. >>>> wdyt? >>>> > >>>> > ++ >>>> > >>>> > Corinne >>>> > >>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >> >>>> >> Hi Corinne ! >>>> >> We want to collect for both situations you described :) >>>> >> >>>> >> Envoyé de mon iPhone >>>> >> >>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >>>> écrit : >>>> >> >>>> >> Hello Sebi, >>>> >> >>>> >> After giving it a closer look, I've got a question for you: do we >>>> want to >>>> >> collect metrics only when an app is opened via push notification or >>>> do we >>>> >> also want to collect metrics when an app is brought to foreground >>>> by a push >>>> >> notification? >>>> >> >>>> >> ++ >>>> >> Corinne >>>> >> >>>> >> >>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; >>>> wrote: >>>> >>> >>>> >>> Yeap >>>> >>> on it. >>>> >>> >>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >>>> rebased on >>>> >>>> the latest master and got a lot of polishing. >>>> >>>> >>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? >>>> The only >>>> >>>> "breaking" change is the rename of the header's name that >>>> identifies a Push >>>> >>>> Notification, it's called now "aerogear-push-id" >>>> >>>> >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> [2] >>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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 >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Erik Jan >>>> >>>> _______________________________________________ >>>> 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