Why do UDVs get such a bad rap? What are they anyway? Most importantly, why should you care?
The what's 'n why's of UDVs
There are many ways GA provides to segment visitors. (Why segment – because “Analyzing data in aggregate is a crime” — Google Analytics Releases Advanced Segmentation: Now Be A Ninja!)
We can segment visitors geographically since the way we analyse how visitors in the US use our site's may be overshadow the way visitors from Canada or Europe do. If we have a Flash-heavy site, don't be discourage by lack of engagement by visitors with slow connections.
However, there are segments that are relevant only to individual sites or which can only be determined in a custom manner, e.g. Registered vs Casual visitors. The UDV allows one to assign a value to a visitor and to segment visitors and visits by that value. E.g. “Registered”, “Gold Member”, “Platinum Member”. The value is stored in the __utmv cookie that, by default, has a 6 month life expectancy. (Bad Trap: Don't set to the value “Casual”. Rather have them appear under “(not set)”)
Use the Visitors -> User Defined report to show basic, Goal and Ecommerce metrics for each segment. Use Advanced Segmentation to separate out visits by visitors identified by UDV value (e.g. One segment of all visits by “Registered” visitors and another by either “Gold Member” or “Platinum Member” if you need to compare visits by all Registered visitors to all visits by all other Members)
UDV's lingering effect on Bounce Rate
As Avinash Kaushik describes it, a Bounce occurs when a visitor arrives at your site, pukes, and leaves. That's Avinash-speak for “single–page-visit”.
Whenever data is sent to GA, it's done in the form a “gif request”—a request for a 1×1 invisible image.
There are 5 types of request that are sent to GA:
- Page View
- Event (as in Event Tracking)
- Ecommerce Transaction
- Ecommerce Item (1 request per Item) and
- User Defined Variables(UDV)
It used to be that all such data report types would count towards what is considered to be a “page view” for the purposes of determining a bounced visit.
If someone lands on a page with a video and leaves—that's a bounce. However, if they start viewing the video on the first page and then leaves, is it a bounce? GA counts the video event (or any other) as an indication that the visitor did something akin to viewing another page.
GA began distinguishing between “Interaction” requests and “Non-interaction” requests. All requests are now considered “Interaction” events except for the “Non-Interaction” UDV request type.
Accordingly, setting a UDV on the first page of a visit is no longer a problem—it is no longer considered an interaction and no longer brands the visit as having more than one Page View.
This was the result of a session held between GAACs like VKI and Google in November 2008.
If you noticed that your Bounce Rate suddenly increased around January 28, 2009, its not because your site suddenly lost its engaging allure but because its use of UDVs no longer caused a problem with Bounce Rates.
However, as with most aspects of most javascript/cookie-based WA tools, changes are not applied to existing data and so are not retroactive. Comparing current to last year's Bounce Rates will have no value.
How UDV's operate within visits
A visit is a bucket of page views and events of a single visitor in a single browser “session”
At the start of the visit, that bucket is indelibly marked with the attributes of the visit such as Browser type, Country, City, Referrer & Traffic Source, UDV, etc.
UDV??? Why should the UDV value define the visit? It's supposed to segment visitors not visits. It seems that GA intends the UDV to be an additional visit-defining attribute even though it's based on some attribute of the visitor and that it should define the entire visit.
So visits are branded with the UDV value in place at the start of the visit and changes to it during a visit will not be reflected. Only the latest value in effect at the start of the visitor's next visit will be recorded against that next visit.
However, if there is no UDV defined at the start of the visit, the first time a value is assigned and submitted, it will be used to define that current visit. However (another however!), as before it defines the entire visit and so segments everything in that visit, including everything that occurred before the value was set.
So what's the big deal?
Assume you want one visitor segment for “Member” set when the visitor signs up and another, “Purchaser”, upon purchase. Visits in which visitors sign up (UDV's first value set to “Member”) and then proceed to buy (UDV now set to “Purchaser”), will all fall under the UDV “Member”. Ecommerce transactions (and any related goals) will be attributed to “Member”.
Metrics for subsequent visits by such visitors will fall under “Purchaser”.
It will appear that Members purchased and Purchasers did not.
The Monolithic UDV
The key here is “mono” — a single value. I don't think GA needs to offer the 50 comparable custom variables supported by Omniture SiteCatalyst but how about just 2 or 3 — each working in a different way (eg one as the current UDV operates and another that segments the visitor's interaction rather than the visit and a 3rd that operates purely at the page view level).
The functionality is already built in to GA—in the way search terms operate—but that's a whole other post
With its current limitations, creating visitor profiles, say, “Lead”, “Registered User”, “Downloader”, “Bigtime Downloader”, “Purchaser”, “Big Spender”, etc) is possible provided changes are only reflected in subsequent visits and don't need a profile of visitors who have both “Downloaded” and “Purchased” (during the same or different visits)
Help is available if you can store 2 or more values in the same UDV eg: “Downloader,Purchaser”. Provided you don't have many profiles, reports on such values will be readable and valuable.
With Advanced Segments we can make great use of such values. An AdvSeg separating visits based on the UDV filtered on containing 'Downloader' will create a sub-set of all visits in which the visitor was a “Downloader”, “Big Downloader” or “Downloader-Purchaser”.
Having no further complaints about the UDV, lets examine 2 scenarios:
Scenario 1: Improved Attribution
I have a student who's Newspaper site sells advertising impressions on its website. Advertisers are interested in the percentage of visitors that have developed brand recognition with the site and either type in its hostname into the address bar or who visit from a bookmark. The newspaper also wants to know (as should we all) which visitors came directly, but later returned via an AdWords campaign (who want's to pay for visitors who already knew of the site?)
The problem is one of attribution. When a visitor arrives from a campaign, referral or organic search, they are “cookied” as such with the 6-month __utmz cookie. When they return directly, they are still segmented as campaign or referral since “direct” visits don't overwrite (or override) prior traffic sources. So how do they know who arrived directly?
Conversely, those that arrived directly (eg by typing a url in the newspaper) and subsequently returned via an AdWord campaign, the latter overwrites the former.
A snippet of custom JavaScript code (available on request) can set a UDV to “Direct Visitor” when visitors land on the site (whatever the visitor's landing page) without a campaign-tagged url and without having been referred.
They, their visits and their pageviews may now be segmented as either “Direct Visitor” or segmented traditionally by their traffic source.
They can then create an advanced segment of visits that have AdWords as the traffic source AND “google” as the referrer AND “Direct Visitor” as the UDV. This AdvSeg will show only those visits that began with an AdWord referral after the visitor had previously arrived directly.
Scenario 2: The Value of Sign-ups
Our client's Users can register. Only their registered users can purchase. Our client wanted GA to show how may users that registered, purchased, but not necessarily in the same visit.
By setting the UDV to “Registered Visitor” when the visitor registers or when the visitor logs in, our client will be able to see the Purchase conversion rate based only on registered users.
I refer to these solutions as being made for UDVs rather than UDVs being available to provide a solution, since, as it happens, none of the UDV's limitations impacted this particular requirement. However, if the Bounce Rate problem had not been fixed, only the 2nd Scenario would still have applied to UDVs.
Some UDV reform is in order.
