Social Media Measurement Enhancements Announced for Google Analytics

Today, Google announced some exciting enhancements to social media reporting within Google Analytics. Though it will still be a few weeks before everyone is able to use the new reports, here’s a sneak peek into a few of the features that should provide immediate value for GA users.

 

Social Overview Report

 

All Google Analytics users will soon have access to a new report that allows you to quantify and visualize the social media contribution to your various site goals, including Ecommerce conversions. This report provides two separate measures of value: last interaction and assisted conversions.

 

A last interaction goal completion is logged any time a visitor is referred from a social media website and completes a goal during the same session. An assisted goal completion is attributed any time a goal is completed after a visitor is referred by a social media website, regardless of the visit that the completion occurred.

 

 

In most cases, the last interaction measure will understate the value of social media on your site, while the overly generous assisted attribution will overstate the contribution. This report effectively creates upper and lower bounds for quantifying social media value. The “true” value is somewhere between those bounds and will depend on the behavior of your sites’ visitors. This will come as a breath of fresh air for GA users who have struggled in the past to identify an aggregate social media valuation for their site based on an amount of retweets, likes, and +1’s.

 

The only requirement for this report is that you have at least one goal defined for your site. It’s important to note that this report is based on a large predefined list of social networks and is NOT dependent on the UTM link tracking that your organization is using to track traffic sources and marketing campaigns. This means that this functionality is available immediately and you won’t have to worry about making any implementation changes.

 

Social Conversions Report

 

In addition to aggregate measures, the “Conversions” report will be used to analyze conversions from individual referring social media sites. Last interaction and assisted conversions are both included along with a ratio of those two metrics. This ratio is meant to quantify whether the referring site is sending upper funnel (relatively high ratio) or direct converting traffic (relatively low ratio).

 

 

Off-Site Analytics

 

If your organization relies heavily on Google+ to engage with users, then you’re in luck. (If not, you probably won’t find this new feature incredibly useful.) Google has integrated off-site data from their Social Data Hub partners to provide greater insight into users’ behavior while on these participating social networks. This feature has the potential to be valuable in the future as the amount of partners increases.

 

There is still a long way to go to clearly define success within the realm of social media. Analysis in these channels must become more about how these networks help our sites accomplish their goals and less about ambiguous popularity metrics. It’s encouraging to see more analytics tools heading in that direction.

 

 

Google Changes Referrer Values Again For Secure Searches

Over the past 6 months Google has made changes to their search experience in an attempt to increase the privacy and security of their signed in users. What this has meant for analytics tools is that the referring URL for those signed in users was stripped of any searched keywords when clicking on Google organic search results.

 

Here’s what has been happening behind the scenes. All signed in users are now on a secure version of Google (https), and a redirect has been added to each search results click. That redirect is to a non-secure page (http), where the referring URL is changed before the visitor arrives at the page they requested. That new referring URL value has had its keywords removed, but still contains enough information to determine it was a Google Secure search. Workarounds were created to help identify a Google Secure search in SiteCatalyst keyword reporting, as well as Omniture making a change to try and account for those searches.

 

Since making that change Google has determined that the additional redirect is unnecessary and potentially slowed down the users experience, so they have decided to eliminate it (unfortunately that does not mean analytics tools will be able to see those keywords again).

 

Today Google announced a change to the way they plan on handling referring URL’s starting in April 2012. Google has decided that they will now begin to use the referrer meta tag for browsers that will support it, as opposed to the redirect to the non secure page. Currently the only major browser that supports it is Google Chrome.

 

If you are not familiar with the referrer meta tag, what it does is it lets each web page decide how referrer from it should be handled. For example, here’s what a meta referrer tag looks like:

 


 

What this tag will do is that it tells the browser to never pass any referring information from the page its on. The browser should then set the referrer header value to a blank string for referrers from that page.

 

Fortunately Google is not going to that extreme. They have decided to use the “origin” value:

 


 

This is the referrer meta tag value that Google will begin to use in April 2012. When the change goes live, all search clicks from signed in users will now only have the referrer value of https://www.google.com/. There will be no other information in the referring URL, so no way to determine that it was specifically a Google secure search other than the URL being simply that host value. Non-secure searches, ones made from a user not logged into a Google account, will continue to function in the same way as they do now.

 

Currently the referrer meta tag is not currently supported in all browsers. I tried it using Chrome 17 and it is working. Testing it in Safari 5.1.4 and Firefox 11, the referrer meta tag has no impact.

 

So what does this mean as far as SiteCatalyst reporting? According to the Knowledge Base answer #5329, “If the domain of the referrer corresponds to that of a recognized search engine (e.g. “google.com”) and contains the recognized search keyword query parameter for the given search engine domain (e.g. for Google this is “q=”), then the referrer is considered a search engine, and the value of the keyword query parameter is taken as the search keyword.” So no search keyword query parameter, no search is counted. Currently for a Google secure search, the parameter is still there, but it’s unpopulated. Now Google plans to remove it all together.

 

Hopefully before Google rolls this out publicly Adobe will come up with a solution for SiteCatalyst so there are no interruptions in the Search Engine reporting. If Adobe does not get to it in time, or if Google decides to push the change out before April, then a couple of lines of code added to your s_code.js file will keep the impact to a minimum while Adobe works out a solution.

 

if(document.referrer=="https://www.google.com/"){
	s.referrer="https://www.google.com/?q=google%20secure%20search";
}

 

What this will do is look for a referrer with the exact value of https://www.google.com/ and append a q= value to it with the keyword of google secure search. If the .com version of Google is not the one most used by your visitors, then just replace it with the correct tld version applicable to your site. This snippet of code will make sure the search is still counted, and you will continue to keep the same level of reporting that you have now.

Webinar: Wake up your Analytics – Turning Data into Action

I am pleased to be joining two other great individuals from the digital measurement industry Adam Greco – Web Analytics Demystified & Ted McDonald – Verisign, to talk about how you can leverage the features of DemandBase to bring real-time identification of the companies visiting your site into your Web Analytics reports.

Keystone Solutions has partnered with DemandBase to help B2B companies turn web traffic into sales and drive new business using their validated database of businesses to identify visitors to your site. Now you can integrate this powerful information with your web analytics solution of choice, to get a full picture of not only who is visiting your site, but what they are doing on it.

See what sources are bringing Targeted companies to your site, which companies are bouncing, how far a company made it into your lead process, and which company you can remarket to.

To learn more about how Demandbase can wake up your analytics register for this great webinar on Tuesday, December 13, 2011 10:00 AM – 11:00 AM PST  (https://www3.gotomeeting.com/register/548512254)

Using Google Analytics Settings to Properly Identify Pages

This year, I’ve been involved in many Google Analytics implementations and audits, and there has been a recurring theme around misunderstood GA Configuration Settings, mostly regarding how a page is identified. For instance, one recent client of mine had a 350-page site. But because of missed configuration settings, those 350 pages were showing up as literally 28000 URIs! Can you imagine pulling a report on any given page of that site? So to clear the air and hopefully save some GA users out there from future headaches, here are 3 quick ways to use GA Configuration to properly identify your pages:

1. Default Page does NOT mean “my defaultiest page”

The default page setting is used whenever a page URI ends in a trailing slash without specifying a file name- for instance, if you used this setting to specify that “index.html” is your default file name, “example.com/”and “example.com/index.html” would merge into just “example.com/index.html” in your content report, making analysis on that single page much easier.

Unfortunately, the name of the setting is misleading and tempts people into entering what they consider the “default page” of their site: their home page. But if you enter “http://www.example.com/index.html” as your default page, the real result would be that any page that ends in a trailing slash will have the full home page URL appended to it:

www.example.com/folder/

would become this in the reports:

www.example.com/folder/http://www.example.com/index.html

This is obviously not desirable, so please do not put your full home page URL as your “Default Page”. If you have a site that sometimes uses index.html or index.php, then you may want to specify THAT as your default page, so all pages with a trailing slash would consistently have index.html appended to them. Otherwise, leave the setting blank.

2. So what DO I do about those trailing slashes?

The default page setting cannot be used for what most people WANT to use it for- to standardize whether or not a page ends with a trailing slash. If you give in to the temptation to simply put a “/” in this setting, then “folder/” and “folder” wouldn’t merge together as desired- rather, “folder/” would become “folder//”, and “folder” would stay the same (remember, the setting only looks at which pages have a trailing slash, then appends the setting value to it).

If you would like to have all trailing slashes removed as the standard, so that example.com/folder/ and example.com/folder would appear as the same line item in the Content report- and who wouldn’t want that?- you will need to set up a custom filter that removes all trailing slashes:

Field A -> Extract A should be set to "^/(.*?)/+$"
Output To -> Constructor should be set to "/$A1"

Please note, much to my chagrin, such a filter would prevent your profile from being eligible for the not-filter-friendly Real Time Analytics(for now), but I promise this isn’t as big a deal as you might think it is, though I’ll save my reasoning for the unimportance of “real time” analytics for another blog post.

3. Exclude parameters!

Most GA implementations I’ve seen have at least a few query string parameters excluded, but I don’t think I’ve seen anyone get it “just right” yet (admittedly, my level of nitpickiness may be a tad unrealistic). The problem with not excluding all non-content-identifying parameters is that parameters will cause one page to show up as separate items in the content report. For instance, if I want to report on how many page views promotions/springlanding.html got, I might need to pull the following 3 pages:

promotions/springlanding.html
promotions/springlanding.html?secured=true

AND

promotions/springlanding.html?type=4

Into my reports, to report on only one piece of content. This isn’t the end of the world; using filters in my reports I can usually get the info I need, though it does make trending harder. But it’s such an easy fix!
To see which query parameters might have escaped your settings, go to your Top Content report and do a search for “?”. If there are a variety of those pernicious params in there, you may want to use an advanced filter to filter them out one at a time, to be sure you’ve got them all. Now you have a handy list of parameters you can take to your configuration settings for exclusion. If you want to track one of the parameters, but not necessarily in your content report, don’t forget you can always use a Profile Filter if you want to extract a query parameter and put it into another field, like a user defined variable, or just clean up parameters in general.

Be careful to not exclude parameters that actually have importance in identifying content. For instance, a products page may have a ?sku=12345 that specifies which product is being viewed- this is a rather critical piece of information for some types of analysis, and should not be excluded.

Please be aware that users can add whatever parameters they want to your URLs, so you will never have full control here. Tools like Google Translate like to wreak havoc on URIs, but generally account for a very small percentage of page views.

Cleaning up your Content Report is an easy quickwin- it doesn’t take a lot of effort and can make analysis much easier. For questions about identifying content in Google or SiteCatalyst, contact me on twitter- @Jenn_Kunz.