Google Analytics Reporting: Really Understanding the Challenges Events and Custom Variables present

In last week’s post we began this “3-course meal” of posts by describing the reporting required to support the business decisions to invest new resources in dealing with Page Load Latency (PLL).

This week we will take a close look at Events and Custom Variables, their strengths, weaknesses and “gotchas”

In Web Analytics, things are often not as they seem. I’m sure that applies also to all Web Analytics tools, even Google Analytics.

This is partly due to using simple solutions appearing capable of solving complex problems.

GA’s Event Reports suggest it would provide the Ecommerce reporting necessary for our PLL tracking solution. However, closer examination, shows the shortcomings of Events in reporting.

Events are great for tracking true interactions with videos and internal banner ads. However, events distort Bounce Rates when used to track non-interaction visit attributes, such as the time it takes to load a page. Events also don’t do well with Attribution of Conversions.

Software solves real world problems in artificial ways. If it does not mimic the real life problems it is to address, we get distorted solutions or need convoluted workarounds.

(Kinda reminds me of Paul Simon’s “Kathy’s Song”:

I don’t know why I spend my time,
Writing songs I can’t believe,
With words that tear and strain to rhyme.)

Two of the most important aspects of PLL tracking are Bounce Rates and Revenue attributed to visits’ average load times. When I saw that neither play nicely with Events, closer examination was required.

What Reporting does the Solution Require?

The first steps in designing a non-obvious solution include defining the reporting required and confirming that the reporting components (Events, Pageviews, CVs, etc) will indeed report what they purport to report.

The reporting needed would have to expose insights and justifications such as these simplistic ( and exagerated?) examples :

1. 25% of the visits were “fast” but produced 50% of the revenueThat suggests the ROI on decreasing load times for the other 75% of visits would be attractive.
2. Conversely, higher conversion rates of faster visits but with revenue showing no clear bias.
   That insight justifies taking no expensive action (or to take a closer look at either the numbers, the average order value or the hypothesis).
3. Similar to the 1st scenario but further segmentation shows that “fast” visits occur primarily in more affluent cities and where operating systems and browsers are the most current.
   Speeding up the site may result in greater micro-conversion rates but not revenue.

From a SiteCatalyst version of the tracking implemented for a different client, the reporting showed 80% of the visits were “fast” and produced 90% of the revenue.

My hypothesis, based also on the site being slow, was that if response times could be increased adequately, the percentage of “fast” visits would increase with a relative percentage increase in visits accounting for revenue. However, I also expect that the number of visits, return visits and all other engagement metrics would increase in number, with an increase in actual revenue.

In addition to speed alone, we also had to track other effects of latency such as skipped Entrance pages, lost Traffic Sources and search engine keywords, Skipped Mid-visit Pages (such as skipped products or category pages).

So Events were not going to cut it and Custom Variables have their own quirks, What to use? What to use?

Digging Deeper into Reporting Challenges

The linked table compares Events, Page Level Custom Variables (PLCVs) and Session Level Custom Variables (SLCVs) by 10 attributes relevant to the problem and notes the implications of each comparison.

1. Attributes:
   The keywords describing the features and characteristics of the tracking component
   They represent issues considered in designing the solution.
2. Event & Custom Variables Columns:
   Describe the way in which the attribute applies to each component and lists the strength or weakness of the component relevant to the attribute
3. Implications:
   The most important column, describing the consequences on the solution and how the component needs to be used, or not, as a result.

Subtleties in Terminology

All sciences have their jargon but Web Analytics has a particular problem. How many times do we talk of people when we mean visitors, visitors when we mean visits and attribution when we mean association?

We might even be short of some technical terms. We have Attribution. But Association?

Take care to distinguish between subtleties as I hope I have succeeded in doing in the linked table.

With what was explained in this post, in this table and in the previous post we should have all the insight needed to design the solution in next week’s post.

As before, we welcome your solutions and suggestions. Please post your comments below.

In next week’s post we will propose our solution and hopefully feature yours.