Broken bounce rate stats since April 13th

Question

We are using Google Analytics for our site that has huge traffic. We are in trouble with some interesting -and surely not good- changes in stats since last 50 days(started on April 13). Bounce rates has doubled, our "time on site" value decreased about 5 minutes and unique visitor counts unexpectedly increased very high. In addition, our pageview stats has no change. We are investigating cause of this issue for several days. We know, these symptomps shows us there is a problem about user sessions. We are loosing user's analytics sessions on somewhere on our site. We got a tip:

We noticed that, our search page has 2.5x more value for "landing page" since 50 days. We are using _trackEvent method for tracking some user interactions on our search page. When we followed the utmb cookie of google analytics(that, as we know, it stores user session for analytics), we noticed that, when we track an event, utmb cookie value changes.

So, the question is, is it normal to tracking events changes to utmb cookie? May this problem be the reason we live in?

UPDATE

We are using ga.js as self-hosted on our servers. Our tracking code is so simple:

_gaq.push(['_setAccount', 'UA-235XXX-1']);
_gaq.push(['_setDomainName', '.ourdomain.com']);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_trackPageview']);

UPDATE 2

We removed setAllowHash parameter and started to host ga.js on google as default usage. Problem still continues.

Answer 1

I'm having exactly the same problem. It also started on 14th April 2012, bounce rates going up, new visits also, shortening Time on site and lowering pages per visit... Pageviews remain the same, which means that for some reason, users are 'losing' __utma cookie, responsible for tracking the user as unique.

One thing I found interesting through GA - in my case this problem does not show for Opera 11.64. It holds its previous value of about 14% bounce rate. Other browsers (mainly new versions of Firefox and Chrome) went through the roof (bounce rate of 65-90%).

I am talking about a website with couple of hundreds of thousands of visits... Tommorow I will try change a few things, and post back if I find anything useful.

UPDATE

I have updated the code to the new one

<script type="text/javascript">

    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'XX-XXXXXXXX-X']);
    _gaq.push(['_setDomainName', 'example.com']);
    _gaq.push(['_trackPageview']);

(function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

instead of the old one

<script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
    var pageTracker = _gat._getTracker("XX-XXXXXXXX-X");
    pageTracker._setDomainName(".example.com");
        pageTracker._trackPageview();
} catch(err) {}</script>

The difference in _setDomainName is that in new code it doesn't have the leading dot(.) in domain name, and there seems to be the problem with the old code. I must add that I'm not having any trouble with the other website that doesn't have _setDomainName part, and still is running the old code. I also found a blog post about the same problem: http://diegoscataglini.com/2010/08/17/118/google-analytics-setdomain-beware/

Anyway, now things are back to normal. Bounce rate back to 11%, time on site going up as well as Pages / Visit. When you change the code cookies will be recreated for all users, making them new visitors coming directly to your site. In a day or two (depending on number of visits), as people use your site as they do normally, statistics go back to normal.

I had to wait couple of days before reporting back, and I hope this will solve your problem too.

Answer 2

Thinking aloud, perhaps this could be attributed to a popular browser suddenly supporting "do not track" or GA suddenly respecting the setting.

Answer 3

Updating the utmb cookie is an expected behavior for _trackEvent -- from the Event Tracking API docs:

By default, the event hit sent by _trackEvent() will impact a visitor's bounce rate.

One place to loose session data is with subdomains -- For example, if you've got a mixture of www.domain.com & domain.com links on your site. If you're not using it already, you could try adding _setDomainName before the _trackPageview call:

_gaq.push(['_setDomainName', '.yourDomain.com']);

Answer 4

This is normal. The utmb cookie stores the hit count for a session and when you track an event or a pageview the hit count is increased by one.

This is used in GA internals to control some limits.

Once this counter reaches 500 it won't send any more hits for that session. Each session in analytics can only have 500 hits.

UPDATE: 2012-06-12

Based on the code you posted I have a few concerns:

• You should NEVER self-host ga.js. This file changes as new features are added to GA. This might explain the bounce-rate changes or might not. You might be sending data that is not what ga is expecting anymore as they might have changed the protocol a little bit.
• _setAllowHash is deprecated by now. If you're using now you should keep using it, but if you have any pages without that call that might be causing cookies to be reset. So if all your pages use that, keep it that way, if some pages use and some pages don't, than remove and make sure not a single page has it anymore. You need to be consistent with GA settings.