Using Load Time Tracking Solutions to Really Understand Google Analytics Events and Custom Variables

I was quite comfortable applying my knowledge of animals like Events and Custom Variables to deliver solutions that required them. That comfort was justified for most solutions … until I came face to face with a problem requiring more than “mere” Actionable Insight.

The central question was whether the page load times of pages on the site or Page Load Latency (PLL), impacted visitors in ways and extents that impacted revenue.

These posts deal with PLL as a practical example through which we can really understand Actionable Insight and both Events and Custom Variables and see when we need to use them together. Or not!

Sometimes, Actionable Insight alone, is not enough …

My first thought was to use TimeTracker, Google Analytics’ page load time tracking solution.

That code was intended as an example and a technical extension of the, then new, event tracking functionality. Its purpose is to report latency to see if one has a problem and the extent of it on a per-page basis. However a complete solution needs to support a business case, because sometimes Actionable Insight alone, is not enough.

So you think your site is fast enough, eh‽

We had the privilege of working with a Google Team on their initiatives to speed up the web. They had done tests which showed that a small, deliberate increase in latency could significantly reduce revenue. We understand Amazon.com have done tests with similar results.

When is Actionable Insight not enough?

In most cases, Actionable Insight merely directs spending already approved budget or amounts to choosing the products to feature for greatest impact.

In contrast, insight into the impact of Page Load Latency (PLL) must support decisions to allocate new funds and resources. Few decision makers will commit new resources to fixing a problem unless they can see not only if, but how much money the problem is costing them.

Unfortunately, Event tracking has limitations that preclude it from providing the insight needed. Custom Variables help but have their own limitations. A solution that goes further to support a business case requires both features working together in well co-ordinated fasion.

Bite-size Pieces

 

I’ve been known to go into detail, on occassion:) so rather than choking you …

• First, this appetizer of a three-course series describing the sample problem – Latency and its consequences. This prepares the palette to appreciate Events and CVs’ respective strengths and weaknesses.
• The second course compares and exposes a deeper view of Custom Variables and Events.
• The last (desert?) applies that deeper view in designing the solution.

Latency and how to Report it

Slow pages result in at least 3 problems:

1. Users click ahead to other pages causing pages to skip GA tracking
2. In the case of skipped Entrance Pages, missed Traffic Sources
3. The distinct probability of reduced revenue and lower conversion rates than otherwise deserved.

The first two problems may be capable of being addressed by loading the GA tracking code near the top of the page. Asynchronous code is advised so to prevent further slow page loading. However, that would merely mask a tangible, identifiable consequence of pages loading too slowly for your visitors’ liking.

The 3rd issue would require implementing techniques justified by a convincing business case. That is where the tracking comes in. It’s objectives are:

1. Track Page Load Times of individual pages to find the worst offenders, as experienced by your visitors
2. Provide the data to determine the cost of latency to the business.
3. In the case of non-eCommerce sites, Goals would be used to determine the cost of latency.
4. Provide the data to determine what resource commitment is justified to address the problem. Relate Revenue, Average Order Value and Transaction Counts, or Conversions to Visit Average Page Load Time of Visits to provide the data

Latency alone, does not tell the whole Story

Where pages load slowly enough, Visitors who are still patient enough to remain on the site may click away to other links. Visitors may be selecting other products or services, possibly less desired, less suitable ones than their first choice.

Frequent Visitors may be familiar enough with the site to simply click ahead, missing new offers or not getting your message as intended. Strange, or even impossible, paths might show up in Navigation Summary Reports.

The vital $Index metric would certainly be distorted.

Such pages, which could be the worst offenders, would appear less frequently in latency reports and their impact would go unreported.  Just how big is the problem?  How would we know?

To detect such behaviour, the code tracks the missed pages and, in the case of missed Entrance pages, also reports missed Traffic Sources.

So why not just use Events and be done with it?

When designing any solution, the question is always whether the data and reports it produces will satisfy the requirements.

The PLL solution must report the following 6 items if it is to provide the insight to not only provide the insight, not only indicate the action needed (if any) but to support the business case:

1. Individual Page Load Times of Bounced Pages,
2. Exit Pages and of
3. Mid-Visit Pages, as well as
4. Visit Average Page Load Times,
5. Skipped Entrance Pages and
6. Skipped Mid-Visit Pages.

How the Latency Tracking Solution Works

• Taking a snapshot at the top of a page. The snapshot includes a starting timestamp, the URL of the previous page and, on the visitor’s arrival, the session’s referrer.
• By skipped we mean that regular GA tracking is skipped, mostly, if not always, because the visitor clicks a link before the page has loaded completely or because or any issue that prevents the tracking code from sending data.(If tracking is lost because it’s a page is not tagged, it may also not have the code to take the snapshot!)
• When (and if) the GA code gets called, the end state is compared to the snapshot and the differences calculated and reported.
• If the previous page had been skipped, the comparison will reflect that and the skipped pages reported, as well as the visit’s lost Traffic Source.

Load Times are reported using configurable histograms. (For examples of histogram-type reports, see the Loyalty, Recency, Depth of Visit and Length of Visit reports and the Visits to Purchase and Days to Purchase reports.)The Histograms used are linear and, by default, configured in 3-second ranges to a maximum of 45s and appear as “0s to 2.9s”, “3s to 5.9s” … “42s to 44.9s” and “45s”

Designing the Solution

 

Can anyone see a problem with the tracking method described? Let us know by commenting below.

If Events are not the appropriate tracking feature they appear to be, are Custom Variables and, if so, which scope of Custom Variable? Page, Session and/or Visitor?

To help decide, I had to do a comparison of them which I will present them in a blog post of it’s own in the next installment in this series, next week.

In the meantime, please give us your insights into the latency problem and your anecdotes too.

We also value your feedback on and suggestions for solutions to tracking problems – ours is by no means cast in stone and, like all tracking problems, there is never only one solution.