Quantcast

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

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
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:

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

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


On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <[hidden email]> 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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoyé de mon iPhone
>>
>> Le 4 mai 2015 à 17:53, Corinne Krych <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc


Envoyé de mon iPhone

Le 6 mai 2015 à 11:38, Matthias Wessendorf <[hidden email]> 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:

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

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. 

Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue. 
-Matthias


On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <[hidden email]> 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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoyé de mon iPhone
>>
>> Le 4 mai 2015 à 17:53, Corinne Krych <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <[hidden email]> wrote:


Envoyé de mon iPhone

Le 6 mai 2015 à 11:38, Matthias Wessendorf <[hidden email]> 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:

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

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 <[hidden email]> wrote:


On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <[hidden email]> 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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoyé de mon iPhone
>>
>> Le 4 mai 2015 à 17:53, Corinne Krych <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Wed, May 6, 2015 at 11:52 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <[hidden email]> wrote:


Envoyé de mon iPhone

Le 6 mai 2015 à 11:38, Matthias Wessendorf <[hidden email]> 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:

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

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 <[hidden email]> wrote:


On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <[hidden email]> 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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoyé de mon iPhone
>>
>> Le 4 mai 2015 à 17:53, Corinne Krych <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc
In reply to this post by Matthias Wessendorf


Envoyé de mon iPhone

Le 6 mai 2015 à 11:52, Matthias Wessendorf <[hidden email]> a écrit :



On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <[hidden email]> wrote:


Envoyé de mon iPhone

Le 6 mai 2015 à 11:38, Matthias Wessendorf <[hidden email]> 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:

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

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 
No but it "was" ready in case we wanted to add it.


-Matthias


On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <[hidden email]> 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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Hi Corinne !
>> We want to collect for both situations you described :)
>>
>> Envoyé de mon iPhone
>>
>> Le 4 mai 2015 à 17:53, Corinne Krych <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> Yeap
>>> on it.
>>>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Passos-3
In reply to this post by Matthias Wessendorf
Just to be clear, we are talking about metrics for messages delivered (received on device) or about really read/open?

Because in Android land is not possible know when message was read/opened. We delegate how the message will be delivered/showed to the MessageHandler[1] and we don't have access to it.

Today we only have access when the message is delivered. Basically we receive the message in a AeroGearGCMMessageReceiver[2] do some checks and push the message for all Handles registered[3][4]

[1] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
[2] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
[3] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
[4] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130

-- Passos


On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]> wrote:
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:

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

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
Just to be clear, we are talking about metrics for messages delivered (received on device) or about really read/open?

Because in Android land is not possible know when message was read/opened. We delegate how the message will be delivered/showed to the MessageHandler[1] and we don't have access to it.

when the user clicks on the message, the app opens. That's what we track w/ this PR, not the actual: I read the message - more "App was opened due to push", see:
 

Today we only have access when the message is delivered. Basically we receive the message in a AeroGearGCMMessageReceiver[2] do some checks and push the message for all Handles registered[3][4]

[1] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
[2] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
[3] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
[4] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130

-- Passos


On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]> wrote:
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:

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

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Passos-3
On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]> wrote:


On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
Just to be clear, we are talking about metrics for messages delivered (received on device) or about really read/open?

Because in Android land is not possible know when message was read/opened. We delegate how the message will be delivered/showed to the MessageHandler[1] and we don't have access to it.

when the user clicks on the message, the app opens. That's what we track w/ this PR, not the actual: I read the message - more "App was opened due to push", see:

I can't do that. I can't do an action when app was opened. To do that we would need to create our own application[1] class, and all projects would need to extend it. As I have told in my previous email, for now I only can do something when the message is delivered to the device.

[1] http://developer.android.com/reference/android/app/Application.html

 

Today we only have access when the message is delivered. Basically we receive the message in a AeroGearGCMMessageReceiver[2] do some checks and push the message for all Handles registered[3][4]

[1] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
[2] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
[3] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
[4] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130

-- Passos


On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]> wrote:
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:

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

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc


On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]> wrote:


On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
Just to be clear, we are talking about metrics for messages delivered (received on device) or about really read/open?

Because in Android land is not possible know when message was read/opened. We delegate how the message will be delivered/showed to the MessageHandler[1] and we don't have access to it.

when the user clicks on the message, the app opens. That's what we track w/ this PR, not the actual: I read the message - more "App was opened due to push", see:

I can't do that. I can't do an action when app was opened. To do that we would need to create our own application[1] class, and all projects would need to extend it. As I have told in my previous email, for now I only can do something when the message is delivered to the device.
But at least we could provide a (static) method that the developer can call and that sends the analytics, right ?  
 

Today we only have access when the message is delivered. Basically we receive the message in a AeroGearGCMMessageReceiver[2] do some checks and push the message for all Handles registered[3][4]

[1] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
[2] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
[3] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
[4] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130

-- Passos


On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]> wrote:
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:

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

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Erik Jan de Wit
In reply to this post by Daniel Passos-3
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:

> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Passos-3
Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]> wrote:
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
iOS is also semi automatic ;-)

On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]> wrote:
Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]> wrote:
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Corinne Krych
Yeap all is in "semi". 
for iOs we'll have 2 public static methods:

AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, launchOptions: [NSObject:AnyObject]?)
AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])

If we want all automation we have to provide more wrapping around native life cycle, which can be quite intrusive.

++
Corinne

On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
iOS is also semi automatic ;-)

On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]> wrote:
Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]> wrote:
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc
Let's start with the "semi-automatic" approach ;) 
@passos : maybe you can use the same method's name to keep it unified ? (we can always change the names later) 


On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]> wrote:
Yeap all is in "semi". 
for iOs we'll have 2 public static methods:

AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, launchOptions: [NSObject:AnyObject]?)
AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])

If we want all automation we have to provide more wrapping around native life cycle, which can be quite intrusive.

++
Corinne

On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
iOS is also semi automatic ;-)

On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]> wrote:
Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]> wrote:
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Mon, May 11, 2015 at 3:51 PM, Sebastien Blanc <[hidden email]> wrote:
Let's start with the "semi-automatic" approach ;) 
@passos : maybe you can use the same method's name to keep it unified ? (we can always change the names later) 

I think summers had a good API though on the other thread already
 


On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]> wrote:
Yeap all is in "semi". 
for iOs we'll have 2 public static methods:

AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, launchOptions: [NSObject:AnyObject]?)
AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])

If we want all automation we have to provide more wrapping around native life cycle, which can be quite intrusive.

++
Corinne

On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
iOS is also semi automatic ;-)

On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]> wrote:
Of course. My point was just to be clear we can't do it "automatic" :)

On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]> wrote:
but the android sdk could have a method for uploading the metrics, so
that a developer can opt for having that displayed on the dashboard.

This method can then also be used for cordova ;)

On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]> wrote:
> On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <[hidden email]>
> wrote:
>>
>>
>>
>> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]> wrote:
>>>
>>> Just to be clear, we are talking about metrics for messages delivered
>>> (received on device) or about really read/open?
>>>
>>> Because in Android land is not possible know when message was
>>> read/opened. We delegate how the message will be delivered/showed to the
>>> MessageHandler[1] and we don't have access to it.
>>
>>
>> when the user clicks on the message, the app opens. That's what we track
>> w/ this PR, not the actual: I read the message - more "App was opened due to
>> push", see:
>> https://issues.jboss.org/browse/AGPUSH-971
>
>
> I can't do that. I can't do an action when app was opened. To do that we
> would need to create our own application[1] class, and all projects would
> need to extend it. As I have told in my previous email, for now I only can
> do something when the message is delivered to the device.
>
> [1] http://developer.android.com/reference/android/app/Application.html
>
>>
>>>
>>>
>>> Today we only have access when the message is delivered. Basically we
>>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and
>>> push the message for all Handles registered[3][4]
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
>>> [2]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
>>> [3]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
>>> [4]
>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
>>>
>>> -- Passos
>>>
>>>
>>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <[hidden email]>
>>> wrote:
>>>>
>>>> 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?
>>>> -Matthias
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
-- Passos

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bruno Oliveira
In reply to this post by Sebastien Blanc
On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)

I think by "semi-automatic" you mean "it's up to the developer", right?
If yes, +1.

Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.

Also, do we have documented in some place what we are collecting?
>From our guide I have:

"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."

If we reach an agreement on it, test the endpoint against DDoS might be
required.

> @passos : maybe you can use the same method's name to keep it unified ? (we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it "automatic" :)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics, so
> >>>> that a developer can opt for having that displayed on the dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when message was
> >>>> >>> read/opened. We delegate how the message will be delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens. That's what we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more "App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was opened. To do that
> >>>> we
> >>>> > would need to create our own application[1] class, and all projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>> http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is delivered. Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> 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?
> >>>> >>>> -Matthias
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> aerogear-dev mailing list
> >>>> >>> [hidden email]
> >>>> >>> 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
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> aerogear-dev mailing list
> >>>> >> [hidden email]
> >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > [hidden email]
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> [hidden email]
> >>> 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
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc


On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <[hidden email]> wrote:
On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)

I think by "semi-automatic" you mean "it's up to the developer", right?
right :) 
If yes, +1.

Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.
Yes since we have to collect when a specific action occurs (open an app or bring to foreground) the only way is do a http request  

Also, do we have documented in some place what we are collecting?
We are not collecting anything with this advanced metrics, we are just "counting" anonymously.  
>From our guide I have:

"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."

If we reach an agreement on it, test the endpoint against DDoS might be
required.
Agreed. 
we should even test DDoS against all our "open" endpoints (registration, import, sender) 

> @passos : maybe you can use the same method's name to keep it unified ? (we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it "automatic" :)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics, so
> >>>> that a developer can opt for having that displayed on the dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when message was
> >>>> >>> read/opened. We delegate how the message will be delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens. That's what we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more "App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was opened. To do that
> >>>> we
> >>>> > would need to create our own application[1] class, and all projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>> http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is delivered. Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> 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?
> >>>> >>>> -Matthias
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> aerogear-dev mailing list
> >>>> >>> [hidden email]
> >>>> >>> 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
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> aerogear-dev mailing list
> >>>> >> [hidden email]
> >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > [hidden email]
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> [hidden email]
> >>> 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
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator


On Mon, May 11, 2015 at 6:08 PM, Sebastien Blanc <[hidden email]> wrote:


On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <[hidden email]> wrote:
On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)

I think by "semi-automatic" you mean "it's up to the developer", right?
right :) 
If yes, +1.

Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.
Yes since we have to collect when a specific action occurs (open an app or bring to foreground) the only way is do a http request  
What about making this thing async? Storing statistics locally and flushing them out once a given threshold is crossed...
 

Also, do we have documented in some place what we are collecting?
We are not collecting anything with this advanced metrics, we are just "counting" anonymously.  
>From our guide I have:

"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."

If we reach an agreement on it, test the endpoint against DDoS might be
required.
Agreed. 
we should even test DDoS against all our "open" endpoints (registration, import, sender) 

> @passos : maybe you can use the same method's name to keep it unified ? (we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it "automatic" :)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics, so
> >>>> that a developer can opt for having that displayed on the dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when message was
> >>>> >>> read/opened. We delegate how the message will be delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens. That's what we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more "App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was opened. To do that
> >>>> we
> >>>> > would need to create our own application[1] class, and all projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>> http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is delivered. Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> 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?
> >>>> >>>> -Matthias
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> aerogear-dev mailing list
> >>>> >>> [hidden email]
> >>>> >>> 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
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> aerogear-dev mailing list
> >>>> >> [hidden email]
> >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > [hidden email]
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> [hidden email]
> >>> 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
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
In reply to this post by Bruno Oliveira


On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <[hidden email]> wrote:
On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)

I think by "semi-automatic" you mean "it's up to the developer", right?
If yes, +1.

Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.

Also, do we have documented in some place what we are collecting?
>From our guide I have:

"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."

the collecting of pay, which you quoted is documented, yes (it is true for 1.0.3 already)

That we collect the open is NOT yet documented. It is part of 1.1.0.Fianl doc, of the new UI.
I will update the "warning" section on the begining as well, not just mention the new stats on the UI parts.

makes sense ?

 

If we reach an agreement on it, test the endpoint against DDoS might be
required.

> @passos : maybe you can use the same method's name to keep it unified ? (we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it "automatic" :)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics, so
> >>>> that a developer can opt for having that displayed on the dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <[hidden email]>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when message was
> >>>> >>> read/opened. We delegate how the message will be delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens. That's what we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more "App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was opened. To do that
> >>>> we
> >>>> > would need to create our own application[1] class, and all projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>> http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is delivered. Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> [hidden email]>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> 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?
> >>>> >>>> -Matthias
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> aerogear-dev mailing list
> >>>> >>> [hidden email]
> >>>> >>> 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
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> aerogear-dev mailing list
> >>>> >> [hidden email]
> >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > [hidden email]
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> [hidden email]
> >>> 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
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bruno Oliveira
On 2015-05-12, Matthias Wessendorf wrote:

> On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <[hidden email]>
> wrote:
>
> > On 2015-05-11, Sebastien Blanc wrote:
> > > Let's start with the "semi-automatic" approach ;)
> >
> > I think by "semi-automatic" you mean "it's up to the developer", right?
> > If yes, +1.
> >
> > Another question is: Is another HTTP request required only
> > to feed metrics? I'm thinking about people with very limited data plans.
> > If yes, that's definitely must be optional.
> >
> > Also, do we have documented in some place what we are collecting?
> > >From our guide I have:
> >
> > "For analytic purposes on our Dashboard we store the content of the
> > alert key sent to the UnifiedPush Server. The content of the alert key
> > belongs to the metadata, which is deleted after 30 days, using a nightly
> > job within the UnifiedPush Server."
> >
>
> the collecting of pay, which you quoted is documented, yes (it is true for
> 1.0.3 already)
>
> That we collect the open is NOT yet documented. It is part of 1.1.0.Fianl
> doc, of the new UI.
> I will update the "warning" section on the begining as well, not just
> mention the new stats on the UI parts.
>
> makes sense ?

Sure thing.

>
>
>
> >
> > If we reach an agreement on it, test the endpoint against DDoS might be
> > required.
> >
> > > @passos : maybe you can use the same method's name to keep it unified ?
> > (we
> > > can always change the names later)
> > >
> > >
> > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <[hidden email]>
> > > wrote:
> > >
> > > > Yeap all is in "semi".
> > > > for iOs we'll have 2 public static methods:
> > > >
> > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > > > launchOptions: [NSObject:AnyObject]?)
> > > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> > > >
> > > > If we want all automation we have to provide more wrapping around
> > native
> > > > life cycle, which can be quite intrusive.
> > > >
> > > > ++
> > > > Corinne
> > > >
> > > > On 11 May 2015 at 15:44, Matthias Wessendorf <[hidden email]>
> > wrote:
> > > >
> > > >> iOS is also semi automatic ;-)
> > > >>
> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <[hidden email]>
> > > >> wrote:
> > > >>
> > > >>> Of course. My point was just to be clear we can't do it "automatic"
> > :)
> > > >>>
> > > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <[hidden email]
> > >
> > > >>> wrote:
> > > >>>
> > > >>>> but the android sdk could have a method for uploading the metrics,
> > so
> > > >>>> that a developer can opt for having that displayed on the dashboard.
> > > >>>>
> > > >>>> This method can then also be used for cordova ;)
> > > >>>>
> > > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <[hidden email]>
> > > >>>> wrote:
> > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> > > >>>> [hidden email]>
> > > >>>> > wrote:
> > > >>>> >>
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
> > [hidden email]>
> > > >>>> wrote:
> > > >>>> >>>
> > > >>>> >>> Just to be clear, we are talking about metrics for messages
> > > >>>> delivered
> > > >>>> >>> (received on device) or about really read/open?
> > > >>>> >>>
> > > >>>> >>> Because in Android land is not possible know when message was
> > > >>>> >>> read/opened. We delegate how the message will be
> > delivered/showed
> > > >>>> to the
> > > >>>> >>> MessageHandler[1] and we don't have access to it.
> > > >>>> >>
> > > >>>> >>
> > > >>>> >> when the user clicks on the message, the app opens. That's what
> > we
> > > >>>> track
> > > >>>> >> w/ this PR, not the actual: I read the message - more "App was
> > > >>>> opened due to
> > > >>>> >> push", see:
> > > >>>> >> https://issues.jboss.org/browse/AGPUSH-971
> > > >>>> >
> > > >>>> >
> > > >>>> > I can't do that. I can't do an action when app was opened. To do
> > that
> > > >>>> we
> > > >>>> > would need to create our own application[1] class, and all
> > projects
> > > >>>> would
> > > >>>> > need to extend it. As I have told in my previous email, for now I
> > > >>>> only can
> > > >>>> > do something when the message is delivered to the device.
> > > >>>> >
> > > >>>> > [1]
> > > >>>> http://developer.android.com/reference/android/app/Application.html
> > > >>>> >
> > > >>>> >>
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> Today we only have access when the message is delivered.
> > Basically
> > > >>>> we
> > > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some
> > > >>>> checks and
> > > >>>> >>> push the message for all Handles registered[3][4]
> > > >>>> >>>
> > > >>>> >>> [1]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> > > >>>> >>> [2]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> > > >>>> >>> [3]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> > > >>>> >>> [4]
> > > >>>> >>>
> > > >>>>
> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> > > >>>> >>>
> > > >>>> >>> -- Passos
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> > > >>>> [hidden email]>
> > > >>>> >>> wrote:
> > > >>>> >>>>
> > > >>>> >>>> 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?
> > > >>>> >>>> -Matthias
> > > >>>> >>>
> > > >>>> >>>
> > > >>>> >>> _______________________________________________
> > > >>>> >>> aerogear-dev mailing list
> > > >>>> >>> [hidden email]
> > > >>>> >>> 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
> > > >>>> >>
> > > >>>> >> _______________________________________________
> > > >>>> >> aerogear-dev mailing list
> > > >>>> >> [hidden email]
> > > >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> > --
> > > >>>> > -- Passos
> > > >>>> >
> > > >>>> > _______________________________________________
> > > >>>> > aerogear-dev mailing list
> > > >>>> > [hidden email]
> > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers,
> > > >>>>        Erik Jan
> > > >>>> _______________________________________________
> > > >>>> aerogear-dev mailing list
> > > >>>> [hidden email]
> > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> -- Passos
> > > >>>
> > > >>> _______________________________________________
> > > >>> aerogear-dev mailing list
> > > >>> [hidden email]
> > > >>> 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
> > > >>
> > > >> _______________________________________________
> > > >> aerogear-dev mailing list
> > > >> [hidden email]
> > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > aerogear-dev mailing list
> > [hidden email]
> > 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

> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12
Loading...