paullangtree / analytics-issues

Automatically exported from code.google.com/p/analytics-issues
2 stars 0 forks source link

iOS v3.09 Session Start causing 0 duration sessions #501

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
---------------------------------------------------------------------------
NOTE: This issue tracking system is for Google Analytics developer products
only.
If you are not a developer/programmer visit:
http://www.google.com/analytics/support.html
---------------------------------------------------------------------------
Name of affected component: Mobile Tracking

Name of related library and version, if applicable (e.g. Android, iOS,
Snippets, etc.): iOS 3.09

Issue summary:
Provide a brief summary of the issue you're experiencing.
We call 
[[self.class trackerForId:t.trackingId] set:kGAISessionControl value:@"start"];
to start a new session when our app starts.  When we turn on debug logging, we 
see that sc=start is attached to every request that is made after that point.  
It seems like this is a functionality change which is causing all of our 
sessions to be 0 duration.

Steps to reproduce issue:
1.  Create a tracker
2.  Start a new session using the above line
3.  Make several calls to record metrics.  Debug output will show that each hit 
will contain &sc=start

Expected output:
What do you expect to see after performing the above steps?
Only the first call after starting a session on a tracker should include the 
sc=start.  This exact code works in version 3.06 but in 3.09 it seems like the 
property is 'sticky' and will be attached to each request after it is set.  
This does not seem to be documented on the documentation 
https://developers.google.com/analytics/devguides/collection/ios/v3/sessions

Actual results:
What do you actually see after performing the above steps?
Every screen or event metric seems to generate a new session.  All of our 
sessions on the new version are 0 duration.  I've tried putting a 'flag' around 
the start session which attempts to set: only on the first call after a call to 
start the new session and then set the value back to nil, but unfortunately, 
that seems to cause the start to never be sent.

Notes:
Provide any additional information which might be useful here. Feel free to
attach screenshots or sample code which demonstrates the issue being
described.

Code parts:

Sending an event:
        [[self.class trackerForId:t.trackingId] send:[[GAIDictionaryBuilder createEventWithCategory:[recordableEvent category]
                                                                                             action:[recordableEvent action]
                                                                                              label:[recordableEvent label]
                                                                                              value:([event respondsToSelector:@selector(value)])?@([recordableEvent value]):nil] build]];

Sending a screen:
    [self.trackingConfigs enumerateObjectsUsingBlock:^(_GATrackingConfig *t, NSUInteger idx, BOOL *stop) {
        [[self.class trackerForId:t.trackingId] set:kGAIScreenName value:newScreenLabel];
        [[self.class trackerForId:t.trackingId] send:[[GAIDictionaryBuilder createAppView]build]];
    }];

Original issue reported on code.google.com by camp...@gmail.com on 26 Sep 2014 at 6:09

GoogleCodeExporter commented 8 years ago
Also, of note, we are using multiple trackers simultaneously.  Thats the reason 
for the loops that you see in the code snippets.

Original comment by camp...@gmail.com on 26 Sep 2014 at 6:33

GoogleCodeExporter commented 8 years ago
It looks like sc=start is a red herring.  That seems to be the same between 
3.06 and 3.09 (once startSession is called, it always includes sc=start) ... 
but the session duration being 0 is still a huge issue. It seems like every hit 
is causing a session on one of the trackers we are using.

Original comment by camp...@gmail.com on 26 Sep 2014 at 6:45

GoogleCodeExporter commented 8 years ago

Original comment by pfrise...@google.com on 10 Oct 2014 at 6:25

GoogleCodeExporter commented 8 years ago
I encountered the same issue. I overcame this issue by removing manual control 
of the session in the iOS app. 

Original comment by Veera.S....@gmail.com on 22 Feb 2015 at 6:54