0

I have just completed a round of Google Analytics Event Tracking updates on the site, which has included updating my _addOrganic calls, which are included in the file /scripts/ga_search_engines.js.

These files are:

NEW - 27kb in size and 28kb in size, respectively. OLD - 4kb in size and 5kb in size, respectively.

$.getScript('/scripts/ga_search_engines.js').complete(function() {
    _gaq.push(['_trackPageview']);
});

$.getScript('/scripts/ga_search_engines_global.js').complete(function() {
    _gaq.push(['rollup._trackPageview']);
});

My event tracking sets the interaction parameter to false, e.g:

_gaq.push(['_trackEvent', 'Product Details', product_name, product_code, product_price, false]);

So this code (event) above is being fired on every product page on the site, the getScript calls are being included in every page on the site and you will notice will have to be downloaded before the trackePageview is fired.

What I can't work out is why I am finding an increase in my bounce rate of about 50% as Google's docs suggest that adding event tracking would decrease bounce rate, rather than increase.

I'm also noticing a 30-40% drop in pageviews, but again I can't put my finger on this although the slightly increased size of the two JavaScript files above make me wonder.

What is the best way to debug this and is there anything that I should be investigating to find out what has went wrong and where?

Here is the full section of GA code I have included on every page - http://pastebin.com/fj6rf4Xa

crmpicco
  • 16,605
  • 26
  • 134
  • 210
  • you still have the actual GA on-page code that gets the ga.js script, yes? Even if so, I wonder if it's taking longer to load than your local `ga_search_engines.js` file... – CrayonViolent Mar 09 '13 at 03:40
  • @CrayonViolent Hi, I I have just updated my question with the full GA code, including the ga.js include at the bottom after the pageview. – crmpicco Mar 11 '13 at 10:55
  • are you sure `/scripts/ga_search_engine_list_rollup.js` actually exists, in the right location, spelled right, etc..? – CrayonViolent Mar 11 '13 at 12:12
  • are you sure the domain you are setting in `_setDomainName` and `_addIgnoredRef` is correct? I realize it could be on a different subdomain, but I do not see this GA code (or those js files) on the regular www of that domain.. – CrayonViolent Mar 11 '13 at 12:24
  • I also see a condition in your ga.js script include code that stops it from including .js if either `iPad` or `iPhone` are defined. I don't know how either of those are set on your page, but I'm going to assume that you have code that detects type of device and suppresses GA if it's an iPad or iPhone. Perhaps 30-40% of your users browse your site on one of those? Or perhaps the logic used to determine those values is bad? – CrayonViolent Mar 11 '13 at 12:27
  • @CrayonViolet Hi, thanks for your comments. The domain and profile number in the PastBin snippet is not the same as the real one I am using in this occasion, i'm just masking it for security purposes. Both JavaScript files definitely exist. I am using the Charles HTTP proxy to view the `utm` requests going to GA and I can see them firing on Mobile, Tablet and Desktop. One thing I have noticed is links on m.ayrshireminis.com point to www.ayrshireminis.com and fire this code `_gaq.push(['_trackEvent', 'outbound', 'click', this.href.match(/\/\/([^\/]+)/)[1]]);` - could that contribute to this? – crmpicco Mar 11 '13 at 15:01
  • eh, not really..that looks like code meant for exit link tracking, and it might screw with your exit link report data since i assume you don't want to count those as exit links, but that shouldn't be the cause of decreased visits. Did you by chance make any filters for your profiles that might be excluding traffic? – CrayonViolent Mar 11 '13 at 16:28
  • I just highly doubt the increase in file sizes are the reason for the drop in traffic. I guess it's *possible* if they are somehow having trouble loading in general or maybe if there's some kind of syntax error in those files (you haven't shown those files so idk)... but if all that is shiny..there really isn't that much a difference of load time between 5kb and 28kb. – CrayonViolent Mar 11 '13 at 16:33
  • Though I guess a significant increase of `_gaq.push()`'s from those files *might* significantly increase the time it takes for GA code to get around to popping `_trackPageview` ... when you go to a given page, about how long is it taking for GA's request to be made? This is getting into the "unlikely" territory but seeing as how we're running out of reasons... – CrayonViolent Mar 11 '13 at 16:35
  • @CrayonViolent This morning I reverted the two JavaScript files back to their former state, so this has went from two files at around 28KB to two files at 4KB. Looking at the hourly stats in GA I can't see any effect on either the Pageviews or the Bounce Rate, they are both much different from this time last week before the enhancements. Unfortunately, I am not an administrator on the live profile so I cannot view the Profile Filters as only admins can view the filters. There is someone else admining the account, but they are a Web Analytics expert so I don't think the problem would be there. – crmpicco Mar 11 '13 at 17:04
  • @CrayonViolent I have Charles 3.7 installed and use that as a HTTP Proxy Debugger, I have tested the site out on FF, Chrome, IE7/8/9, iPad and iPhone and can see requests coming through Charles for them all. I can't see HTTPS requests with Charles when I move into a HTTPS area, but the Chrome Google Analytics debugger lets you see the requests and there are the usual `Tracking beacon sent!` messages appearing. As part of these improvements I have _removed_ a rack of virtual pageviews and reverted these back to regular pageviews which I can see pulling through in Charles. I'm at a loss now. – crmpicco Mar 11 '13 at 17:08
  • well...if you reverted to original scripts and the numbers haven't changed, then that pretty much rules out that as a possibility. Either there was some other change on the site inadvertently affecting GA calls or else filters added that you don't know about. I'm still kind of wondering about this line though: `if (typeof iPad !== 'undefined' || typeof iPhone !== 'undefined') return;` was that always there? Are you sure nothing has changed as far as how those vars are given values? – CrayonViolent Mar 11 '13 at 17:45
  • @CrayonViolent I know for absolute certain that the conditional you have highligted above was always there, well before this release. As for the filters, i'm not sure. I will need to wait to tomorrow to get a hold of the admin I mentioned earlier, who will hopefully be able to advise me. What still concerns me is there is a multitude of comments on SO, down the right on this page, where people have had issues with Bounce Rate in particular following Event Tracking implementation. Thanks alot for the assistance on this, BTW. – crmpicco Mar 11 '13 at 17:53

1 Answers1

0

Apparently, this was down to previously inflated pageviews through an implementation of Virtual Pageviews. The removal of these as part of improvements brought the value of pageviews down, which looked like a problem but in reality was actually bringing them down to an accurate level.

Not the easiest thing to debug and troubleshoot.

crmpicco
  • 16,605
  • 26
  • 134
  • 210