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

Wed May 6 05:54:43 EDT 2015

On Wed, May 6, 2015 at 11:52 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> 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.
>

the variant gives us at least the platform - which would be good enough ;-)
But perhaps, at some point, a version string would be nice.

However, on iOS SDK that is a bit of an issue, since that means the push
registration SDK needs to use UIDevice APIs for automatic submit of the
version ;-/
Today, this is done on the user code, on the Delegate - which is better.

>
> 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
>

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