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

Wed May 6 05:52:39 EDT 2015

On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <scm.blanc at gmail.com>
wrote:

>
>
> Envoyé de mon iPhone
>
> Le 6 mai 2015 à 11:38, Matthias Wessendorf <matzew at apache.org> 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/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
>
> 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/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
>
> 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 at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
>> 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/AGPushPlugin.m#L82
>>> 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 at redhat.com> 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 at gmail.com>
>>>> 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...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > This client could be tested with HelloWorld. See:
>>>> >
>>>> >
>>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>>> >
>>>> > 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/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>>> >
>>>> > 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 at gmail.com> 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 at gmail.com> 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 at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Yeap
>>>> >>> on it.
>>>> >>>
>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>>> 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 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
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>>        Erik Jan
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
> 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
>

-- 
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/20150506/df0d7055/attachment-0001.html 