You’ve just completed a WebPerf project and your site is blisteringly fast. When you review Google Analytics, just like the rules of thumb suggest, you see your web traffic increase – awesome! But the euphoria is quickly followed by disappointment when you see an increase in bounce rate as well. What’s going on?

Some background…

Yottaa has been working with many eCommerce and Media companies to accelerate their websites by 20-40% or more, due in large part to the orchestration afforded by our AppSequencing technology. A common scenario where AppSequencing comes in especially handy is in accelerating 3rd party JavaScript like Google Analytics so business leaders and product owners have a better understanding of visitor behavior. By making Google Analytics load faster, our customers have been surprised to see that they’d been making decisions based on bad data – a very common one being that they experience dramatically more mobile site traffic than they had originally thought. Why? Because accelerating site performance and prioritizing the Google Analytics JavaScript uncovered short clicks, a.k.a. pre-analytics-tag bounce behavior. Put another way, Yottaa showed them the truth behind the industry metrics that gave rise to our 4 Second Syndrome. Users do not wait for a slow-loading site, and so many of them leave before Google Analytics can record they were even there. Trees fell in forests and nobody heard the sounds…

To prove this, we need to cover some basics.

First off, let’s review how the Google Analytics tag works

From an article entitled “How Does Google Analytics Collect Data” (emphasis is ours)

The data that Google Analytics uses to provide all the information in your reports comes from these sources:

• The HTTP request of the user
• Browser/system information
• First-party cookies

The HTTP request for any web page contains details about the browser and the computer making the request, such as the hostname, browser type, referrer, and language. In addition, the DOM of most browsers provides access to more detailed browser and system information, such as Java and Flash support and screen resolution. Analytics uses this information in constructing reports like the Map Overlay, Browser, and Referring Sites reports. Analytics also sets and reads first-party cookies on your users’ browsers in order to obtain user sessions and any ad campaign information from the page request. The Google Analytics Tracking Code also reads the double-click cookie to get information about the Display Features.

When all this information is collected, it is sent to the Analytics servers in the form of a long list of parameters attached to a single-pixel GIF image request. The data contained in the GIF request is the data sent to the Google Analytics servers, which then gets processed and ends up in your reports.

Next, let’s review how page speed impacts Google Analytics

The following text is taken from an article entitled “Latency and why it Impacts AdWords Clicks and Analytics Sessions”

Position is important

We often get asked where the Analytics tracking code should be placed in the HTML source of a page. The answer is, it depends on how accurately you want to measure users who bounce. If a click takes place and it takes several seconds for a session to be recorded, then there is a strong possibility that some of these sessions may not get tracked. In general, we recommend placing the tracking code just before the closing </head> tag.

Consequences of slowness

Short Clicks: A short click occurs when a user clicks an ad, and then before the Analytics tracking-code request is fired, the user clicks the back button or closes the browser. AdWords records the click, but a corresponding session is not recorded in Analytics.

Generally speaking, the slower the website is to respond and the larger the number of requests that appear before the Analytics snippet, the more likely it is you will be subjected to issues with short clicks and missing session data.

Another way to think of short clicks is that they are actually users who are bouncing from the website, which means if you are not tracking these bouncing sessions, then your bounce rate could be artificially low.

Mobile and Short Clicks: As a general rule, mobile devices operate on slower network infrastructure (3G networks) than most Desktop connections (ADSL / Cable). If you target mobile devices, a fast-responding website is even more critical to preventing short clicks.

Now let’s accelerate Webperf to cut down on short clicks

Getting back to our webperf project then, Yottaa has been accelerating web applications and prioritizing Google Analytics to fire as soon as possible in the visitor’s browser. As we can see in this screenshot (and by investigating via the Google Analytics dashboard) Yottaa is accelerating page load time for this site by more than 2x, which cuts the short click potential in half:

This is because the Google Analytics JavaScript is loading sooner and therefore the tracking pixel is being returned far more frequently.  To prove this, we used the Catchpoint APM tool to review two waterfall charts: for the original performance, and after the webperf project was complete:

• Domain: www.google-analytics.com
• Resource URL (simplified): https://www.google-analytics.com/r/collect…

Tracking pixel execution on unadulterated site:

Tracking pixel execution on Yottaa optimized site:

This means that any users who did not stay on the original site for at least 6 seconds would not result in a recorded session or a bounce.

And finally let’s prove that site acceleration reduces Bounce Rate

This is conceptually simple, but practically difficult.  It’s one thing to quote chapter and verse from the Steve Souders or Tammy Everts hymnals, and quite another to convince an eCommerce or Media executive that their metrics need to be re-baselined when webperf is improved.

Why re-baseline?  Because with Google Analytics reporting more often, everything changes.  More sessions, a higher percentage of new users, potentially shorter session duration…the list goes on.  If you can’t see where this is going, then consider the conundrum (Clicktale article covering this) of whether it’s the design, the content, or the webperf that’s affecting KPIs.  But to avoid religion and politics, let’s review the data.

By prioritizing the execution of the Google Analytics JavaScript, two metrics will always increase: Sessions and % New Users.  Your mileage will vary with regard to the absolute numbers, but proportionally both metrics will increase.  To prove that webperf impacts visitor behavior – in this case focusing on Bounce Rate – we will simply look at the proportionality of how Bounce Rates changes relative to Sessions and % New Users:

Using the totals:

• % New Sessions are 9% higher when webperf is improved
• …while Bounce Rate is only 2.3% higher

Using relative values:

• 6.44% more users are observed when webperf is improved
• …while Bounce Rate only increased 2.58%

In Conclusion

Faster load times – specifically, when content starts to render (aligned to the metrics Time to Start Render, Doc Complete, and Time to Display) – directly impact Bounce Rate, just as the industry data suggests.  So when a webperf project accelerates a site more session data is captured and recorded, and despite having to re-baseline KPI levels given this new level of insight, bounce rate is diminished as users have a better experience online.  This is evident by looking at the difference in the impact on certain KPIs: proportionally consistent increases in Sessions and New Users, but disproportionately lower increases in metrics like Bounce Rate.  In all cases, understanding trends for your business and your site(s) is key.  Things like seasonality, visitor demographics, etc will all have an impact, but once you understand the basics, you can extend analyses like the one above to tune any metric – time on site, page depth, conversion rate and more.  Happy tuning!