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

On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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 <corinnekrych(a)gmail.com&gt; > > 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 <matzew(a)apache.org&gt; > wrote: > > > > > >> iOS is also semi automatic ;-) > > >> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; > > >> 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 <edewit(a)redhat.com > > > > >>> 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 <dpassos(a)redhat.com&gt; > > >>>> wrote: > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> > wrote: > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos < > dpassos(a)redhat.com&gt; > > >>>> 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-an... > > >>>> >>> [2] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [3] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [4] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> > > >>>> >>> -- Passos > > >>>> >>> > > >>>> >>> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> >>> 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... > > >>>> >>>> > > >>>> >>>> On the client SDKs this will be read and a HTTP call made to > the > > >>>> soon > > >>>> >>>> introduced MetricsEndpoint. Currently this info is send to the > > >>>> >>>> RegistrationEndpoint, including the deviceToken/registrationId. > > >>>> However, I > > >>>> >>>> think that the deviceToken/registrationId is currently not > needed > > >>>> for > > >>>> >>>> metrics, since we are just interested in anonymous "app > > >>>> launched/opened due > > >>>> >>>> to push", and not a specific "DEVICE X did open, while DEVICE Y > > >>>> did not yet > > >>>> >>>> open". > > >>>> >>>> > > >>>> >>>> So all we really need is the ID of the push notification, to be > > >>>> >>>> processed by our Metrics Service > > >>>> >>>> > > >>>> >>>> > > >>>> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > > >>>> >>>> > > >>>> >>>> Therefore my proposal is have an endpoint: > > >>>> >>>> > > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} > > >>>> >>>> > > >>>> >>>> I think PUT is good/best, because there is nothing really > created > > >>>> on the > > >>>> >>>> server, it's more updating the 'counter' on the existing > > >>>> >>>> PushMessageInformation object. > > >>>> >>>> > > >>>> >>>> Thoughts? > > >>>> >>>> -Matthias > > >>>> >>> > > >>>> >>> > > >>>> >>> _______________________________________________ > > >>>> >>> aerogear-dev mailing list > > >>>> >>> aerogear-dev(a)lists.jboss.org > > >>>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> -- > > >>>> >> Matthias Wessendorf > > >>>> >> > > >>>> >> blog: http://matthiaswessendorf.wordpress.com/ > > >>>> >> sessions: http://www.slideshare.net/mwessendorf > > >>>> >> twitter: http://twitter.com/mwessendorf > > >>>> >> > > >>>> >> _______________________________________________ > > >>>> >> aerogear-dev mailing list > > >>>> >> aerogear-dev(a)lists.jboss.org > > >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > -- > > >>>> > -- Passos > > >>>> > > > >>>> > _______________________________________________ > > >>>> > aerogear-dev mailing list > > >>>> > aerogear-dev(a)lists.jboss.org > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Cheers, > > >>>> Erik Jan > > >>>> _______________________________________________ > > >>>> aerogear-dev mailing list > > >>>> aerogear-dev(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> -- Passos > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev(a)lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >> > > >> > > >> > > >> -- > > >> Matthias Wessendorf > > >> > > >> blog: http://matthiaswessendorf.wordpress.com/ > > >> sessions: http://www.slideshare.net/mwessendorf > > >> twitter: http://twitter.com/mwessendorf > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev