New issue
Advanced search Search tips
Starred by 28 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Dec 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Compat

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Google Analytics tracking broken on Chrome 6+

Reported by tomki...@gmail.com, Sep 13 2010

Issue description

Chrome Version       : <Copy from: 'about:version'>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
Firefox 3.x:
IE 7:
IE 8:

What steps will reproduce the problem?
1. See the bottom of this issue...
2.
3.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

So far I couldn't recreate/identify the problem on my own Chrome, but I've got data on thousands of Chrome Users coming to our site (www.rightmove.co.uk) and I can see that the GA Cookie/JavaScript tracking of them has gone really bad since the release of Chrome 6.

See attached a screen-shot of the jump in Unique Users (identified by a cookie ID) from Chrome and a jump in Visits, which shows that the issue (some sort of Cookie "dropping"/overwriting) happens during the visits as opposed to in between the visits. This also pushes the Avg. Pageviews per Visit down (also attached as a screenshot).

To show that this only affect Chrome 6+ versions, I've attached the Avg. Pageveiews per Visit by each of the version (5, 6, 7). As you can see Chrome 5 has a healthy ~20 pageviews per visit average, while 6 & 7 have around 3 pageviews per visit, which points to sessions (cookies) being cut down all the time.

I'll add more data when I manage to identify what technical glitch causes this JavaScript/Cookie malfunction.
 
Chrome 6 Average Pageviews.jpg
89.9 KB View Download
Chrome 5 Average Pageviews.jpg
91.5 KB View Download
Chrome 7 Average Pageviews.jpg
92.7 KB View Download
Chrome Visits jump.jpg
71.6 KB View Download
Chrome Average Pageviews drop.jpg
73.7 KB View Download
Chrome Unique User (cookie id) jump.jpg
72.6 KB View Download
We're seeing the same over here at Skyscanner. 

It is very similar to a problem noticed with the Safari Live Preview feature that resulted in phantom sessions being created. Are the "most visited" previews now making a call?

Comment 2 by dav...@asos.com, Sep 13 2010

ASOS is also seeing this issue and we have raised it with our contacts at Google. It seems far more pronounced than Safari live preview, which we also noted. If the cause is indeed the thumbnail preview function then the refresh cycle must be far more frequent than Safari. Or perhaps a cookie issue as the OP suggest. Our Webtrends Analytics tool (which also utilises first party cookies) is not recording the same issue.

Comment 3 by g...@weeworld.com, Sep 14 2010

We are seeing the same at Weeworld where we saw unusual increases in visits from Thursday the 9th of Spetember onwards. ON the 11th we had a 22% increase in visits as reported by Google Analytics. 

Using their Intelligence feature we established that most of these new visits were referrals from our CDN we  would not usually expect to see as a referral as we only deliver images and swf files through this channel.

I then segmented these "erroneous" visits and found that they were all coming from Chrome. Drilling down further showed that it was specific to Chrome 6 and started shortly after the launch of version 6.0. And as per the first post visits were inflated consequently reducing average pageviews.

I agree with comment 2 The extent of the additional visits created makes me think that this problem must be associated with the session cookie being over written when a page is loaded breaking the click stream, creating a new visitor each time and causing the strange referral data.

We have added a filter to our profile to proactively strip out the bogus referral data which should mostly sort the problem for now but unable to get accurate Unique Visitor numbers for the back end of last week.

Jim Williams







Yup, this is definitely real -> all Analytics tracking is pretty fubar unless Chrome 6 is excluded from the traffic.

Wonder when this will be fixed and if there's a way to escalate this, given both Chrome and Analytics are from Google. :)

Comment 5 by flo...@emesa.nl, Sep 14 2010

We are seeing the same thing in our Analytics profiles. Took quite a long time too find out what it was.
Bouncerates skyrocketed, pages per visit were divided by half and time on site divided by half too.....
Excluding Chrome traffic did the trick :-)

Comment 6 by bnk...@gmail.com, Sep 14 2010

Please post the URLs of the sites on which you're seeing this issue.  It will help determine if this is a cookie path or domain issue.

Comment 7 by goo...@2dehands.nl, Sep 15 2010

We have the same problems. Sites: tweedehands.nl, 2dehands.be and 2ememain.be

Comment 8 by flo...@emesa.nl, Sep 15 2010

We have multiple labels all running analytics but only one: www.vakantieveilingen.nl is showing this problem!
For those folks who are seeing this problem: If you can post the domains on which you're seeing it as well as the domains on which you're *not* seeing it, that would be useful.  I'd also be interested in the specifics of the cookies that this behavior suggests are being dropped--are they always session cookies, or is there evidence that persistent cookies are being dropped?


Given the amount of "New Visitors" has increase very significantly in the reports, that indicates the persistent cookies are being dropped. AFAIK GA definition of a New Visitor is a user without any persistent GA cookies stored. Also the amount of New Visitors who're performing actions that are impossible for new visitors that I'm seeing in our reports is several times higher than with other browsers. so it looks like the cookies are being dropped often.

Having said that, I've noticed GA is quite picky about reading the data in, and it's trivial to create a script that completely messes up the data. Hence this might also be related to something other than cookie resets. I recommend you coordinate the fix with the GA team, as they should be able to tell what's going on, and presumably someone working on Chromium should have access to the GA engineering team.

Comment 11 by g...@weeworld.com, Sep 16 2010

We are definitely seeing the problem on www.weeworld.com but have looked at other domains such as aim.weeworld.com and skype.weeworld.com but do not see an affect. However, these sites have much lower visitors and average page views are in the range of 1-2 pages so if the problem is caused by session cookies these sites are going to be minimally affected.

Comment 12 by Deleted ...@, Sep 16 2010

Same here, we have problems with only one of our pages.
The one with bad stats is using _trackEvent while the others (with correct stats) don't, that might be the problem.

Comment 13 by tomki...@gmail.com, Sep 16 2010

As mentioned in the issue description, on www.rightmove.co.uk both the number of Unique Users and Visits have gone through the roof. So, Chrome appears to be loosing both Session and Persistent User ID Cookies. 

The very strange thing is that the composition of Referrals (Traffic Sources) hasn't been affected that much (if at all). You can see in the attached (Chrome traffic sources.jpg) that the "Extra Visits" are happening quite evenly across the main three traffic sources. This would mean that whilst losing the Session and Unique User cookies Chrome still retains the utmz (traffic source) cookie info, and therefore the "Extra Visits" get attributed to the initial traffic source.

I've also found something that is likely to be the cause (or at least another symptom) of all of this, although I can't recreate it every single time with the same actions...
1. Basically, I open http://www.rightmove.co.uk/ in a new Chrome tab, and have a look a the Chrome "Cookies and other Data" table (see Step 1 screenshot).
2. Type in "tw1" in to the search box at the top of the page and click "For Sale), and check the cookies  (see Step 2 screenshot).
3. Click "Find Properties" button, and check cookies again (see Step 3 screenshot). As you can see the Cookie values for the utma, utmb & utmc have been whipped clean (I didn't have anything in utmv), while the utmz value has been retained. This way to recreate the problem works only some 4 times out of 5 for me, and other people got their cookies whipped out on the 2nd Step. 

That's what I've got so far, and this issue seems to match pretty well what the total numbers are saying within GA.
Step 2.jpg
81.4 KB View Download
Step 1.jpg
75.8 KB View Download
Step 3.jpg
78.3 KB View Download
Chrome Traffic Sources.jpg
14.2 KB View Download
@TomKisss: Thanks for the repro instructions.  Unsurprisingly, I'm unable to repro on my end :-{, but those instructions do bring up possible things you could do on your end if you're so inclined:
* What platform are you running on?
* If you would be willing and are able to reproduce the problem with the latest developer build (7.0.517.5), would you, at each step where you look at the cookies through "Show cookies and other site data", also visit the URL "about:histograms/Cookie" in a separate tab and cut and paste the contents of that tab?  (It'll be plain text).  I'm specifically looking for one copy of that page before the cookies get whipped, and one after.  (A reload to get the new version should be fine.)

In both my repro attempts and your screenshots, the creation time changed when Find Properties was clicked, which means a new cookie was sent from the server to chrome that overwrote the old one.  Naively, it looks like those cookies had null values, but that explanation (which would suggest a bug in GA) doesn't explain the correlation with the chrome version.  I'm presuming the bug's actually in chrome (mostly because for me the light's better over here :-}--I don't actually have any theories yet) and looking for what might be correlated in chrome with getting the behavior you describe.

Comment 15 by tomki...@gmail.com, Sep 17 2010

I've downloaded 7.0.517.8 dev on Windows 7 Professional and was able to recreate the issue and got the Histogram and the "Cookies and other site data" for before and after the wipe out happened. See the attached.
I've had a look at GA and the stats are pretty messed up for Chrome 6+ on all main OS (versions of Windows and Mac), so this shouldn't be OS related.
I also noticed that the utmz cookie doesn't get wiped out because it's a permanent cookie that's only being updated by the GA script when you access the site for the first time or when you re-access the site via a different traffic source. So, it looks like it is indeed GA that sets the empty cookie, but I'd imagine that it's something in the way how Chrome 6+ executes the GA JavaScript that makes it forget what it wanted to update the cookies to (i.e. lose the new value of the cookie variable). The other option is that the Chrome 6+ misunderstands something about the way how GA use the "document.cookie" function and then loses the assigned value.
Lastly, I'm getting convinced that, at least on rightmove.co.uk, the cookie issue can happen on pretty much any page of the site, almost as if every pageload has a 1/4 chance of just messing up the cookie logic. That's also confirmed by the fact that even on Chrome 6+ our GA shows that people do manage to have very long sessions (with many pageviews), but just that since the Chrome 6+ release that has become very rare whilst the number (ratio) of short sessions has increased dramatically.
I hope this helps.
About Histograms - Cookie After.htm
3.4 KB View Download
About Histograms - Cookie Before.htm
3.4 KB View Download
Before.jpg
335 KB View Download
After.jpg
320 KB View Download

Comment 16 by bkuhn@google.com, Sep 18 2010

The Google Analytics team has narrowed this down to a single statement of "x instanceof Array" returning false when it should return true.  Normally, it's important to not use this check if the Array might have been created in another frame.  We are certain the Array was created in the current frame, but it appears Chrome is sharing contexts when the same script is loaded in two different frames.  

http://groups.google.com/group/comp.lang.javascript/msg/1afbcb0da1cd4aef
http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/

This bug manifests itself when you load ga.js in a parent frame and an iframe.  The buggy instanceof check is causing cookies to be overwritten with dashes, which causes GA to think that the visitor is brand new.  

The GA team is working on a work-around on our end, but this sounds like a bigger issue that needs to be fixed in Chrome.

Comment 17 by bkuhn@google.com, Sep 18 2010

Here's a simple test page demonstrating the bug.  
http://analytics.nfshost.com/chrome_six_bug/index.html

Comment 18 by Deleted ...@, Sep 18 2010

youtellme.nl and fashiolista.com joining the list. major issues with analytics for chrome 6 users.

Comment 19 by bkuhn@google.com, Sep 18 2010

We think this (now fixed) V8 bug could be the root cause of this issue.  
http://code.google.com/p/v8/source/detail?r=5483

Any idea when this will make it into stable Chrome?  

Comment 20 by tomki...@gmail.com, Sep 22 2010

@bkuhn: has there been any more news on fixing the issue on GA side?
I've had a look at the traffic data from the latest versions of Chrome Dev and haven't seen any evidence of the issue being fixed there. With that I'm guessing that the fix from Chrome side is not going to be live on "Stable" in the immediate future...
If this bug doesn't get fixed before October then we'll have another month of messed up tracking data and that's going to create a lot of problems for all GA users.
I'd assume that this must be a very important issue in GA eyes?

Comment 21 by bkuhn@google.com, Sep 22 2010

We've determined that it may not be enough to patch ga.js to fix the single manifestation of this bug that we were able to reproduce.  We believe sites a suffering from more than one broken use case, so fixing the one spot we know about in ga.js won't necessarily fix everyone (or perhaps anyone).  We've also been working with the Chrome team to get the fix into the stable channel.  I don't have an exact timeline, but I believe this issue will be fixed soon. 
ASOS stats have reverted to normal, seemingly coinciding with the push of the 6.0.472.63 release. Thanks.

Comment 23 by will...@gmail.com, Sep 27 2010

I can also confirm that this issue is now fixed for us. Our Chrome visitors have dropped while maintaining our pageviews in GA. Thanks. 

Comment 25 by jda...@gmail.com, Oct 1 2010

Fixed!!
Labels: -Area-Undefined Area-Compat-Web
Status: Fixed
Looks like this has been fixed -- please reopen or file a new bug if that's not the case.
Labels: -Area-Compat-Web bulkmove Area-Compat
Project Member

Comment 28 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 29 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Bug -Area-Compat Type-Compat

Sign in to add a comment