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 the disappointment when you see an increase in bounce rate as well. What’s going on?
To prove this out, 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, the 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 session 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 users 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:
- Domain: www.google-analytics.com
- Resource URL (simplified): http://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.
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%
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!