async versus sync

to sync or to async?

We at the Internet Architects WebAnalytics department - WAIA in short - are serious about data and data quality. That's why we were all excited about the release of the Google Analytics Asynchronous tracking code snippet in December 2009. The benefits seemed obvious, as stated on Steve Souders' blog:

• Faster page loads and improved uptime: the script now loads without blocking the downloads of other resources.
• More data equals more accurate results as early click-aways will now be measured more accurately compared to the synchronous tracking snippet.

The first benefit seems clear: the asynchronous script call leads to ga.js being downloaded parallel to other resources - a good thing for a functional website script as the tracking code adds no new content to a page. After the script is fully downloaded the page view calls (and other GA methods) will be executed.

So how to verify whether the accuracy of data generated by the asynchronous tracking code is more accurate than the data generated by the synchronous tracking code? The answer is simple: the improved tracking code should track more page views and visits since there is less data loss due to early-click aways from pages.

Below you can find a test, set up to verify this improved data accuracy. After all, in a web analytics environment the data itself is already quite the subject of discussion, so let's try to make sure we don't pollute our messy data even more.

synchronous versus asynchronous tracking code snippet

We performed the test on this very blog. The test was implemented as follows:

• Leave the current tracking code as-is: synchronous and implemented inline before the closing body-container.
• Add the asynchronous tracking code as additional measurement (using a different UA) before the closing head-container, as prescribed by Google Analytics.
• Check results in the GA front-end.

Following the async code's raison d'être we expected the traffic data to be more or less the same, with slightly more traffic measured by the asynchronous tracking code as this version is supposed to have lesser data loss due to early click-aways. The actual results looked like this:

Synchronous: 17305 visits / 31891 pageviews
Asynchronous: 17968 visits / 30203 pageviews

Visits: more data measured with the asynchronous tracking code.
Page views: less data measured with the asynchronous tracking code.

The results for measured visits are in line with the expectations: more visits are recorded by the asynchronous tracking code snippet because early click-aways are recorded more accurately. However we didn't expect to see that more page views would be measured by the synchronous code. Following the same logic as before we would expect to see a rise in page views equal to the higher amount of visits.

So we performed a more detailed check, comparing the results on a day-per-day basis:

In the table above, a green table cell in the delta column indicates an expected result (more data measured by asynchronous code). A red table cell indicates an unexpected result (more data measured by the synchronous code).

These results are more or less consistent with previous findings, but they still offer little in the way of explanation as we encounter plenty of fluctuations in the delta columns. We had to dig deeper, finding a way to evaluate the performance of the measurements of early click-aways of the GA async code versus the sync tracking code. The closest match was to segment on bounced visits versus not bounced visits within GA:

• Bounced visits segment: Number of page views equals 1.
• Non bounce-visits segment: GA built-in segment.

These are the results summed up in two tables.

The results are stunning:

• The asynchronous tracking code has improved measuring performance for bounced visits: almost 12% more visits measured compared to the synchronous tracking code.
• The asynchronous tracking code's results are worse for multiple page visits: 8,5% less pageviews are measured compared to the synchronous tracking code.

conclusions

The results of these tests lead us to conclude that a website might benefit from the asynchronous tracking code only if it has a high bounce rate. Then again we must consider the merits of measuring more bounced visits: we receive more accurate data on the visitors who click away early, at the same time we lose about 20% data on our other visitors, while the latter category is by far the more interesting group of visits to analyze.

So how is this possible? Why does the async code measure 8,5% less pageviews? For the moment we are assuming (and of course investigating) that there might be a difference in the way the browser handles the async versus the sync script code, causing these differences. You will hear from us again when we have more results to back these assumptions...