Analytics Talk

Google Analytics & Feedburner: A Love-Hate Relationship

Justin Cutroni — Wed, 25 Jan 2012 17:48:48 +0000

For those that are unfamiliar with Feedburner, it tracks how many people subscribe to an RSS feed, the various applications that access your feed, and how many people take action on your content. It will even track how many people subscribe via email. All wonderful metrics related to interaction with your syndicated content.

Some people, like me, syndicate all of their content via RSS. But others will will only syndicated a snippet of content in the feed in hopes of driving people back to a website where the content lives. This is true for most publishers like Search Engine Land and the BBC.

In this case a feed becomes a source of traffic and must be measured as such. Luckily there is a simple integration with Google Analytics that makes it easy to see how much traffic is coming from a feed.

Feedburner will automatically inject the Google Analytics Campaign Tracking parmeters into your feed. Then, when someone clicks on a link in your feed, the traffic to your site will correctly identified as coming from your syndicated content.

(You can read all about campaign tracking in a previous post if you are not familiar with it.)

It’s important to note that Feedburner will only tag SOME of your links. More on this later.

You can find the campaign tracking settings in the Configure Stats” section of the Analyze tab. Here are the default settings:

Default Feedburner settings for Google Analytics.

Digging into this a bit more, here’s a description of values that Feedburner will insert into the various campaign tracking parameters:

Source: This value is set to “feedburner” by default. It identifies that the visitor came from content that was syndicated by Feedburner. I would not recommend changing this.
Medium: The channel where the feed was distributed. Remember, Feedburner can distribute your content via RSS, Twitter or Email. Feedber alters the value of medium depending on how the feed is accessed. The values will be either “feed”, “email”, or “twitter”.
Campaign: This is just the feeduri and feed name. Because my feed name and URI are the same, I actually simplified this to just be the feed name. But no need to change this.
Content: The application where a click request originates, e.g. Google Reader, Gmail. Can be interesting to see how people are consuming your content.
Term: not used by default

So that’s the good news. We have a tool that measures the reach of our feed on a daily basis and the traffic back to our site from that feed.

Now the bad news.

There are some quirks when it comes to Feedburner. Specifically, not all of the links in a syndicated post are tagged with the Google Analytics campaign parameters. The result is incorrect traffic source data. Let’s look at some data to understand the impact.

Here’s a simple graph of direct traffic to my blog. All of the annotations with start (shown at the bottom of the graph) are dates when I published a new article. You can notice the spike in direct traffic on the day of, or the day after, that I publish the post.

Direct traffic to this site.

Now, let’s focus on Dec 8 and 9, the large spike of Direct traffic and look at some of the landing pages for direct traffic.

Top landing pages for direct traffic.

The top landing page for direct traffic is:

/blog/2011/12/08/the-google-analytics-social-data-hub-more-than-meets-the-eye/index.php

I don’t think anyone is going directly to that page. I do believe that a lot of people are going directly to /blog/index.php. But people are not typing /blog/2011/12/08/the-google-analytics-social-data-hub-more-than-meets-the-eye/index.php into the browser. This is clearly an issue.

Direct traffic can often be caused by links that are not tagged. Depending on server redirects, we often see untagged email traffic, especially from application like Outlook, incorrectly tracked as Direct Traffic. I’m guessing that’s happening here.

So let’s go one step further. Let’s go right to the source of the problem. Here is an email that Feedburner sends to those that subscribe to my feed via email. A quick investigation reveals that the link in the header, which links to the sire URL, is not tagged. So that would increase direct traffic to /blog/index.php.

However, the link to the article page is tagged, which is great news.

A blog post sent from Feedburner, some links are tagged and some are not.

A quick look at the links at the bottom of the page reveal that the links are NOT tagged.

Not all of the links in a Feedburner Email are tagged.

So that link at the bottom of the page, the one to the post “The Google Analytics Social Data Hub – More than Meets the Eye?”, that’s the link that’s responsible for driving a lot of direct traffic to the site.

You may be asking why doesn’t Google record this as referral traffic? Due to redirect, the value of document.referrer, which would normally be the referring site is blank. Resulting in direct traffic.

ARGH!

So there you have it. Feedburner is AWESOME. A fantastic way to track content syndication. But beware, there are quirks. Specifically not all of the links that are in an email are tagged.

Google Analytics & Feedburner: A Love-Hate Relationship is a post from: Analytics Talk by Justin Cutroni

Save Your Ass With Google Analytics Data Alerts

Justin Cutroni — Wed, 04 Jan 2012 15:44:43 +0000

Let’s face it, we’re all a bit “lazy.” I admit it, I don’t check my website data every day. And when I’m on vacation it can be a bigger challenge.

But that’s OK, I use data alerts to stay on top of my data even if I can’t check analytics every day. Are you using alerts?

If you’ve never used Google Analytics alerts they’re fairly simple to set up. You can find them in the Profile Settings.

There are five things that you need to do to set up an alert:

1. Choose a profile to apply the alert to.
2. Select how often you want to monitor the data (daily, weekly or monthly).
3. Identify the segment of traffic you want to monitor (i.e. which group of visitors, like visitors from a particular campaign or geographic region).
4. Choose what metric you want to monitor (Revenue, Visits, Time on Site, etc.).
5. Set a threshold for the alert meaning how much does the metric need to change to activate this alert (ie increase, decrease, etc.).

I divide my alerts into two groups: those that insure I have good data and those that measure the performance of the business. This post deals with the former: alerts that will keep your data in tip-top shape.

Alert #1: 10% Daily Traffic Drop

This first alert is simply there to make sure that I’m collecting data. I’ve noticed, for my site, that my traffic usually never drops more than 10% for a given day when measured week-over-week. So if I see a drop of more than 10% I know that something happened and I need to investigate more.

A 10% traffic drop alert.

Alert #2: Flatline! i.e. No Data

This is a generic alert that identifies when a metric goes to zero. I can’t tell you how many times a client tries to analyze data at the end of a month only to find a data issue. This commonly happens because not every metric is analyzed every day, some metrics are reported monthly.

But I don’t want to wait until the end of the month to find a problem.

So for almost every important metric I will create a daily alert to insure that I’m getting data. Here’s an example alert that monitors an event.

A Google Analytics Alert that monitors an Event

Alert #3: Daily Error Pages

Another metric I like to monitor is error pages, more specifically 404 errors. I want to know if any of my content is generating an error for my readers. So I created a little alert that will alert me when the number of 404 pages is greater than 0.

Monitor 404 pages, and other website errors, with an alert.

Obviously you can change this alert to monitor almost any type of website error, it depends on which errors you are tracking with Google Analytics. The key is that you need to be able to identify your error pages in a Google Analytics report.

As you can see above, my error page has a unique URL (404.html) and a query parameter that identifies the page that was missing. You may need to use a virtual pageview or an event to track your error pages. Once you do you can create an alert.

Alert #4: Non-Domain Traffic aka The Poser Alert

The hostnames report in Google Analytics is a handy little report. It shows the hostname that is in the location bar of the visitor’s browser. On numerous occasions people have ~~ripped off~~ borrowed my content without my permission. They just copied my source code and posted it on their own domain.

I know, classy.

This alert will automatically let me know if my account is getting data from any domain other than my own.

The "Poser" Alert will let you know if someone is poaching your content.

In some cases this alert actually detects something good! I regularly see the hostname translate.googleusercontent.com, which is used when popele use Google Translate to translate the content on my site.

A note from your data therapist

All of these alerts can help. But you’ll still have inaccuracies in your data. The idea is to keep them to a minimum. If you try to eliminate all errors 100% of the time you won’t do anything else. It’a almost impossible. Do the best you can.

If you do have some data issues, and you will, you’ll have to spend some time resolving them when you do your analysis.

Save Your Ass With Google Analytics Data Alerts is a post from: Analytics Talk by Justin Cutroni

Building a Mobile Ecommerce Dashboard in Google Analytics

Justin Cutroni — Tue, 13 Dec 2011 13:54:07 +0000

Recently, at the GAUGE conference, I talked about Google Analytics custom reports and dashboards. During the dashboards section of the talk I walked the group through the process of setting upa dashboard. As an example I created a dashboard for a fictional ecommerce website.

After the talk someone came up to me and asked if I could share more details on the dashboard. So here they are!

My goal with this dashboard is deep-dive on the mobile segment of the business: to focus on the business objectives (conversions), key actions that could lead to conversions AND ancillary data about the mobile experience. This will give us a wide range of metrics that provides a deep understanding of the mobile experience.

This is not a data puke.

Before we begin, some assumptions about the business that will make it easier to build the dashboard.

This is an ecommerce business and revenue is queen!
The business has launched an ecommerce website in hopes of diring more revenue via mobile
There are a number of mobile marketing campaigns that are running and it is critical to measure their effectiveness
The mobile site is ever evolving and the business is always looking for information on how to improve the site

A dashboard is a great way to pull all of this information together. Could you use a custom report? Sure.
But the dashboard does include some nice (but VERY basic) visualizations.

Here it is, the mobile dashboard.

Mobile Ecommerce Dashboard for Google Analytics

The key to creating tis dashboard is the filter option built into each widget. I’m basically segmenting each widget to include only mobile traffic. It’s not that hard to do, just set the Dimension to Mobile and the value to ‘Yes’. (The Mobile dimension is a yes or no flag.)

Filtering a Google Analytics Dashboard Widget for Mobile

That’s it. The widget will only contain data specific to mobile.

Now that we know how to manipulate the widgets so they only include mobile data it’s just a matter of putting the most appropriate widgets on the dashboard.

I’ve divided the mobile dashboard into four sections:

1. Revenue Measurement (outlined in green above)
2. Campaign Performance (outlined in red above)
3. Mobile Device Information (outlined in orange above)
4. Content Performance (outlined in yellow above)

Let’s look at each section.

Revenue, Revenue and Revenue!

The first section of the dashboard deals with revenue. Surprise! There’s not much to explain here. This is an e-commerce site and revenue is their key success metric. You could easily change this to conversion rate if you’re not an ecommerce site. I like the little spark line that shows me a trend.

Google Analytics Mobile Revenue Widget

Now this is where things get interesting, the next widget is Mobile Revenue vs Non-mobile revenue. This is cool if you want to see how mobile revenue compares to overall revenue.

Mobile Revenue vs. Non-Mobile Revenue

The way this widget is a pie-chart widget is to group the metric, in this case revenue, but the Mobile dimension. Like this:

Grouping a Pie Chart Widget

Channel & Campaign Segmentation

Next we continue to look at revenue but now we’re segmenting it my marketing channel. A bit more advanced, but very, very insightful.

This fictional company is leveraging a number of marketing channels, so let’s segment the revenue by medium to determine which ones are generating revenue.

Mobile Channel Revenue

Drilling a bit deeper we can include a table of the top 10 campaigns to quickly see which ones are successful and which ones are not. Again success is measured based on revenue. But if you are not an ecommerce site you can change the widget to measure almost any goal conversion.

Mobile Campaign Performance

Notice I’ve also included Bounce Rate in this table. This makes it easier for me to understand if the poor performance of a campaign might be due to the initial experience the visitor has on the site.

In this case every campaign has $0.00 and a 100% Bounce Rate. Not so good. Time to rethink my landing page experience.

Don’t forget, if you’re using Google Analytics you need to use Campaign Tracking to accurately track marketing activities.

Device Information

In addition to our key business metrics, let’s include some usability metrics that will help guide future development of the site. In this case, because we’re dealing with mobile, let’s include some device data.

Mobile Device Revenue

I know… not another pie chart. But it’s a fast way to show which devices are driving revenue on the site. 38% from the iPad! Maybe we should focus on the iPad user experience?

Just to provide a little context, let’s add a table with the top mobile devices.

Mobile Device Traffic and Bounce Rate

The table helps us understand two things. First, what are the most popular devices that people use to access our mobile site? This information is critical for future development work. Second, I’ve included bounce rate in the table. This metric will make it easier for us to determine if users of a certain device have trouble accessing the site.

Wrapping Up

I know that there are some serious shortfalls with the Google Analytics dashboard. BUT, let’s not look past certain things that are helpful. You get to add almost any metric and dimension. You can segment that data AND you can add some (VERY basic) visualizations. All in all, it doesn’t suck. Too much.

There are two things I wish the dashboard had:
1. The ability to add a simple text area where I can add my analysis and thoughts
2. The ability to add external data, like ad spend

Post Script

Google recently hosted a webinar with Avinash Kaushik promoting mobile marketing and, of course, measurement. You can watch the entire video below. It’s about an hour but well worth it.

Avinash also included a link to a custom report for mobile measurement. A nice compliment to the dashboard above.

Now it’s your turn. What would you add to a mobile dashboard?

Building a Mobile Ecommerce Dashboard in Google Analytics is a post from: Analytics Talk by Justin Cutroni

The Google Analytics Social Data Hub – More than Meets the Eye?

Justin Cutroni — Thu, 08 Dec 2011 11:40:44 +0000

Get ready for the Google Analytics Social Data Hub

You may have heard that Google recently announced a new Social Media Data Hub. This is the nerdy first step in a series of upcoming social media reports that will probably launch in 2012.

Basically, Google will allow social media sites (Digg, Facebook, Twitter, etc.) to send data to Google Analytics. What type of data? Information about who is sharing your content, what content they are sharing, and how they’re sharing it. Basically everything you would want to know about someone talking about your business off of your site.

I’ve read a few of the write-ups and think John Lovett did the best job. You should totally read his thoughts on the new social data hub. Here are a few gems from his post:

Well, I see this as a huge win for marketers, bloggers, publishers and anyone else trying to discern the impact of social media marketing across the multitude of channels and platforms available today.

Google’s new Social Data Hub – coupled with Google’s Social Analytics reporting – has the potential to knock the socks off these unknowing marketers.

If/when Google applies the lens of their analytics tool to this new aggregated data set, look out marketers — you just hit the jackpot!

While the big dogs in social media may take a while to come around, I see this new Hub as a potentially great equalizer for understanding the impact of social media as it relates to referrals for on-site activities which can ultimately lead to conversions and bottom line impact.

If you would like to join the Social Analytics Reporting beta you can sign up here: https://services.google.com/fb/forms/socialpilot/

If you are a social media platform and would like to send you data to Google Analytics you can review the technical specifications here: http://code.google.com/apis/analytics/docs/socialData/socialOverview.html

So get really excited! In 2012 we’ll be able to analyze how people interacts with your content and brand on social networks. Very cool.

The Details Others Missed

But I think there’s a lot more to this announcement than meets the eye.

First, the REALLY big news that I feel has been overlooked is that Google will let other data providers integrate their data into Google Analytics. This is the first time that Google has added a non-Google data source to Google Analytics. (I’m counting Google AdWords as a separate data source, but it’s owned by Google).

Now that’s the big news.

There are some interesting side stories to Google's Social Data hub.

If Google is developing the infrastructure to integrate other well-structured data sources, what’s next? Will they let me import historical data? What about industry benchmark data that I might use to provide context to my website data?

Or how about the ability to import and translate data. For example, maybe I’ll be able to translate product IDs into product names using a standard data import.

Or how about the ability to translate a single campaign id rather than using the standard utm_ campaign tracking parameters (anyone remember utm_id?)?

The ability to import data has been a common request (albeit mostly from enterprises) for a long time. This would be very well received.

The second interesting thing about the new Social Data Hub has to do with privacy. The standard version of Google Analytics prohibits the collection of personally identifiable information. But, according to some of the Google Analytics Social Data Hub technical specifications, Google will require that the username or screen name and the display name appear in the social media data feed.

This could absolutely be PII.

Technical Information about the Google Analytics Social Data Hub

It seems to me that Google may need to change in the standard Google Analytics terms of service.

So at this point we’re left with a lot of questions.

But that’s OK, we’ve got some time to speculate.

NOTE: ideas and opinions above are my own. While I will be joining the Analytics team in January, I have no current knowledge of Google’s master plan

The Google Analytics Social Data Hub – More than Meets the Eye? is a post from: Analytics Talk by Justin Cutroni

Going Google

Justin Cutroni — Thu, 01 Dec 2011 19:16:49 +0000

Hi everyone, just a quick post to let you, the blog readers, know that I’ve gone Google. Starting in January I’ll be part of the Google Analytics team.

I wrote a small post on the Cardinal Path blog, but wanted to reach everyone reading this blog and add a little more detail about what I’ll be doing.

[ For those that saw the previous post, sorry for the duplicate content. ]

Before I tell you about my new role, I want to take another opportunity to that the team at Cardinal Path. David, Alex, John, Corey and Dave (in no particular order) have assembled a fantastic team and created a unique place to work.

Many people don’t know all the stuff that Cardinal Path is doing. But I can absolutely tell you that it’s some really advanced stuff, like measuring entire industries using Google Analytics. It was a really hard decision to leave…

With that said, I’m very excited to join the Google team! I obviously love their product and think they will have a significant impact on how companies use data to be more successful.

In my new role I will be externally focused and very hands on with GA. I’ll be meeting customers, going to conferences, blogging, etc. I’ll also help guide some of educational efforts.

My (tentative) new title is Analytics Advocate. I really like this because I’ll be advocating for everyone that uses GA. You got problems? Let me know!

In fact, I promise to resolve the following GA issues in my first week:

1. I will restore organic keywords and remove (not provided)
2. I will eliminate all sampling from GA
3. I will eliminate all tracking code and make the data magically appear in your account.

[ Those are obviously jokes. ]

But seriously, I’m super excited to join a team that can revolutionize how businesses function online.

Thanks again for all the support, comments, tweets, etc. Please stay in touch and make sure we’re connected on Twitter, Google +, or LinkedIn.

Going Google is a post from: Analytics Talk by Justin Cutroni

Path Analysis in Google Analytics with Flow Visualization

Justin Cutroni — Wed, 19 Oct 2011 17:33:08 +0000

Google Recently announced a new feature in Google Analytics, Flow Visualization. These reports, the Visit Flow report, Navigation Flow report, and Goal Flow report are a new take on analyzing how people navigate through content.

Flow Visualization report in Google Anlaytics

For a long time click path analysis was not really possible in Google Analytics. Sure, we had the Navigation Summary and Entrance Paths reports, but these were very limited. This was by design. Most click path reports, no matter the analytics tool, has little to no value. They usually show 9,845 different paths to conversion. How does that help?

The new Flow Visualizations reports hope to remedy this problem and make it easier to understand visitor behavior regarding how they move through content.

Nodes: Foundation of Flow Visualizations

All flow visualization reports are built using nodes. Nodes are groups of pages. The cool thing is that the nodes are automatically created using an intelligence algorithm. For example, nodes will automatically group the same page that may only differ by a couple of query parameter.

Don’t worry, you can create your own nodes, and I’ll show you how to do that in a minute.

The new reports show visitor flow through nodes, and where people drop out of the flow (ie leave the site). The really important thing here is the visualization AND our ability to manipulate the visualization. So if you a specific issue or scenario that you are analyzing it’s easy to drill down on the scenario you want. But the visualization also supports ad-hoc analysis.

These new reports are in the Home > Intelligence > Flow Visualization section.

On to the Visits Flow report.

Visit Flow Report

The Visit Flow report is a nice refresh of the traditional click path report. Rather than looking at clicks from one page to another, we’re seeing visitors moving between nodes. The ‘story’ starts on the left side of the visualization where you can choose a to view a starting segment, like Campaign, Traffic Source, Country, Region, etc.

This is AMAZING! Now you can easily segment traffic through a site based on various dimensions of data! The next time someone asks what campaign traffic did, now you can provide some very detailed flow information.

Connections in blue represent the number of visits that move between the nodes.

Connections in red represent the drop off from a particular node.

How easy is that to understand? The brilliance is the simplicity.

Let’s say you want to focus on a particular segment of data, like the state of Texas. Just choose a dimension from the drop down, in this case Region. Then click on the Texas node at the far left and choose ‘Highlight traffic through here’. The path of traffic from Texas will appear a bit darker.

View the path for a specific dimension of data in the Flow Visualization report.

I know there can be a lot to take in. If you are a bit confused, then perhaps we should reduce the number of paths that are visible. Use the ‘Connections’ slider at the top to view more, or less paths and make the analysis easier.

Alter the number of paths visible in Flow visualization

The reason why click path reporting has sucked for SO LONG was the vast amount of data stuffed into a really crappy display. Google is trying to solve that using this new visualization, the Dimension drop down AND the Connections slider. You have control over the amount of data you are looking thus making analysis area.

Using this interface you can identify where people come from, follow them to various pages and evaluate the bounce rate, and then see what they look at after the landing page.

The interactivity is just awesome.

[ By the way, you can scroll to the right by dragging the visualization when you see the fist. You can also add more steps by clicking on the arrow at the far right. ]

Let’s say you want to learn more about a particular node. Just hover over a node and you’ll see something like this:

Node details in Google Analytics Flow Visualization

The first thing we learn is how many pages are in this node. Remember, an algorithm initially created this node. We can also see how many dropped off and how many moved on. Very useful.

Now, perhaps I want to understand this page a little better. I can click on the node and choose ‘Explore Traffic through here.’ That brings us to the next report

Navigation Flow Report

The Navigation Flow report is similar to the old Navigation Path report in Google Analytics. Now you can see the nodes before, and after, your chosen node.

Google Analytics Flow Navigation Report

Let’s talk about how we can create and edit your nodes.

Click on the small gear at the top of the node. You can use a reg ex, or other basic pattern, to group a set of pages together into a node.

For example, if I’m a publisher, I may want to group all my Sports pages together into a Sports node, like this:

The Name field is the name that will be displayed in the report, it’s nice and human readable :)

The value here is you can group your content together so you can analyze your site your way.

Ecommerce people, want to understand the flow of traffic through your product pages? Group them together in a node.

Publishers people, want to see where people go after the last page in all your articles? Group those pages together in a node.

Another really cool feature of the Flow Visualization reports is our ability to segment the entire graphic. Use the drop down at the top of the report to apply a segment, like new visits, return visits, etc.

Apply a segment to a Flow Visualization

Combine that with the dimension drop down and I can slice and dice the behavior of different groups as they move around the site. Crazy awesome.

Goal Flow Analysis

In addition to the basic flow reporting, there is also a Goal Flow report that provides insight into your conversion paths.

Goal Flow report in Google Analytics. Click to enlarge.

Again, you can choose a dimension of data, here I chose the medium, and view how that traffic moved through your funnels. I hope you have a funnel configured!

NOTE: At this time the Goal Flow report only works for URL based goals and funnels. Events will follow soon.

Notice the loops? Those show traffic that ‘loops back’ to other steps. I think this is a HUGE improvement over the existing Goal Funnel reports. It’s much easier to see holes in the funnel (drop offs) and behavior (looping).

Is this just the beginning?

Hopefully this gives you a basic idea of how the flow visualization reports work and how you can manipulate them. The key here is that you can segment the data to isolate the behavior that you want to investigate.

I’ve got to say, I think this is going to have a much bigger impact on Google Analytics than most people know. Sure, these reports are sexy. And we’ll start to do more path analysis.

But this visualization of data is the key change. I believe we’re going to see Google include more creative data visualizations to help aid analysis. That’s truly exciting.

Path Analysis in Google Analytics with Flow Visualization is a post from: Analytics Talk by Justin Cutroni

Google Analytics Real Time: Real Time Data for Real Time Decisions

Justin Cutroni — Thu, 29 Sep 2011 17:50:23 +0000

The NEW Google Analytics Real Time Reports

Google Analytics now contains a series of real-time reports that measure what’s happening on your site in real time. These reports will roll out in the next 1 to 2 weeks.

I’ve long railed against real-time data. I’ve said that businesses don’t need real time data. It’s very hard to action on time data. I’ve said this on the record!

But here I am, with my tail between my legs, to admit that some businesses really do need real time data. I was wrong. I can absolutely see the need for real time data.

Chartbeat Real Time Report

And if you still need convincing look at the success of tools like Chartbeat. They provide some pretty awesome data that helps business make important decisions WHEN those decisions need to be made.

Real time data can be very helpfull in the following business scenarios:

If you are a publisher, you often need real time data to understand what content is popular right now, so you can optimize the placement of that content, or publicize that content, to optimize ad revenue.
If you are a retailer, you might want to understand, in real time, the launch of a new campaign. This is especially useful if you are using a channel, like social media, that has a very immediate impact.
If you are holding a physical event, you might want to understand, in real time, how people in that location are using your website.

To fill this analysis hole Google Analytics now has a Real Time section of reports, creatively named Real Time. This series of repots offers a subset of data that is processed in real time, literally every second. You can see who’s on your site, how they got there and what they’re looking at in real time.

The data covers three dimensions:

Geographic locations
Traffic sources
Content

I know, there’s no conversion data. Sucky. BUT let’s consider how much data is getting processed every second. Seriously, that’s a lot of data!

IMPORTANT: One thing to keep in mind is that the Real Time reports are NOT filtered. Even if you have a profile filter applied the data is not filtered. I guess that requires a bit too much processing power.

The real time reports are NOT real time data for all metrics, only a subset of metrics. But they are pretty good. You have access to real time stats for:

Visitors
% New visitors & returning visitors
Pageviews
Traffic sources (referrals, direct, campaigns, etc.)
Active pages

Let’s look at the reports and how they solve the above business cases.

Real Time Overview Reporting

Everything starts with the Overview report. This is mission control for Real Time data and gives you a general overview of what’s happeneing.

The Google Analytics Real Time Overview Report

At the top of the report Google shows a second by second view of pageviews. It then aggregates this data and shows a minute-by-minute view. I know, this view is mesmerizing. Try not to wast too much time watching this.

The top of the report also shows the total number of unique visitors on the site (it counts the cookies). Google Analytics then segments this number to show you the amount of new visitors and returning visitors.

Moving deeper into this report we get information about what’s the most popular content right now, where visitors came from (both traffic source and keywords) and a geographic breakdown of where the visitors are located.

With this one report we’re able to answer the business questions we posed above.

Real Time Locations Report

The location report has basically the same geo data as the Overview report. It still show second-by-second data and a breakdown by Country.

The Google Analytics Real Time Locations Report

One thing that is different is the ability to view geography using Google Earth. Does this offer any additional insights? HELL NO! But it looks sexy. The Google Earth plugin will zoom you from from city to city.

Oooooooo! Zoom from city to city with the Earth View

Real Time Traffic Sources Report

The real time traffic sources is literally a dump of your top traffic sources. Again, not too different than the data on the Overview, the tabular data shows the Medium and Source dimensions.

The Google Analytics Real Time Traffic Sources Report

This is especially handy when you launch a new campaign and want to see how it’s working. Think about when that big tweet goes out and you want to see what’s happening on the site.

Or consider the case where you might have an unexpected spike in traffic. This report will help you understand if there is some referring site that is driving a lot of traffic. We still can’t see if there is a lot of conversions (grrrrrr) but at least we can see traffic.

Real Time Content Report

And finally we have a dedicated real time content report. Again, not much new here. You can view how many active users are viewing a specific page or get an agregate view of pageviews over the last 30 minutes.

The Google Analytics Real Time Content Report

Notice how some of the data rows are shaded green and red? Green indicates a row of data that has increased while a row of data that is red indicates a row of data that has decreased. This is a nice touch to make it easier to see things “move.”

So there you have it. Google’s new Real Time feature for Google Analytics. How do you plan to use this to optimize your business?

Google Analytics Real Time: Real Time Data for Real Time Decisions is a post from: Analytics Talk by Justin Cutroni

5 Google Analytics Custom Variables for Ecommerce

Justin Cutroni — Tue, 14 Jun 2011 05:48:17 +0000

I believe that every business can use Google Analytics custom variables. Especially ecommerce businesses. Custom variables inject new data dimensions that are crucial for segmentation. As analysts we need to do segmentation to understand user behavior. And ecommerce sites have certain unique behaviors that are not tracked with a basic Google Analytics implementation.

For those that have not used custom variables before you can get read Mastering Custom Variables for overview.

Now on to the custom variables!

Tracking Coupon Codes and Promotional Codes

I think this is a pretty obvious use of custom variables. If you sell something you probably run various promotions. And you need to track these promotions to see how they perform. Some promotions can be tracked using campaign tracking. I’ve seen lots of people use the utm_content parameter to identify the promotion in a marketing campaign, like an email. But a custom variable works just as well.

When coming up with a strategy think about how you might scale this as time goes on. Do you want all of your promotional codes aggregated together under one variable? You could do something like this:

_gaq.push(['_setCustomVar',1,'PromoCode','',3]);

Or you could get fancy and use different custom variables to bucket groups of promotions, like seasonal promotions. For example, if you lots of promotions during the holiday season you might want to create a custom variable named HolidayPromos and then a unique name for each of the codes, something like this:

_gaq.push(['_setCustomVar',1,'HolidayPromo','Free2DayShip',3]); _gaq.push(['_setCustomVar',1,'HolidayPromo','FreeWrapping',3]); _gaq.push(['_setCustomVar',1,'HolidayPromo','10perOff',3]);

The above code would need to appear on your receipt page. And remember, the slot, or index, in the code above may be different for you. It all depends on your use of custom variables.

You might be wondering why I decided to go with a page level custom variable here. Remember, Google Analytics will sessionize a page level custom variable. So even though the custom var will only fire on the receipt page the data will be applied to the entire visit.

Tracking Payment Method

Remember, we study visitor behavior to understand the impact on business. One of these behaviors is how people pay for a purchase. Is there a difference between a visitor who pays with a credit card vs one who pays with PayPal? Does one spend more, on average, than the other? You’ll never know unless you capture payment type and review metrics like average order value and conversion rate.

To capture payment type use a page level custom variable. The resulting GA code will look something like this:

_gaq.push(['_setCustomVar',2, 'PaymentType','',3]);

Don’t forget to replace with the customer’s payment method.

Tracking Shipping Method

Like payment method, it’s interesting to see what shipping method people choose with various products. Why? Perhaps people who buy certain products choose certain types of shipping. If so, maybe you can build a new promotion using this information. Could there be no insights here? ABSOLUTELY! But you’ll never know unless you have some data and do a bit of analysis.

_gaq.push(['_setCustomVar',3,'CustType','Repeat',1]);

Tracking Repeat Customers

I remember reading Eric Peterson’s book Web Analytics Demystified a looong time ago. Besides being one of the first books on analytics it was exceedingly actionable. One of the ecommerce key performance indicators Eric talked about, and rightfully so, was the repeat-buyers.

The behavior of repeat customers is different than first time customers. This segment of customers usually takes less time to purchase due to a knowledge of your products and services. Normally it costs you less money to get these people to convert. So it’s a good idea to understand what marketing they respond to and how they use your website.

To track repeat customers in Google Analytics you must use a visitor scope custom variable. Remember a visitor scoped custom variable persists on the visitor’s computer as a cookie. The trick is when you set the custom variable.

Most people think you can set the custom variable when the transaction happens, like this:

_gaq.push(['_setCustomVar',4,'CustType','Repeat',1]);

But in reality this will not work. When you set a visit level custom variable the value gets applied to the CURRENT visit and all future visits. So you need to wait until the SECOND purchase before setting the above custom variable. Then it should work just fine.

[UPDATE: Elizabeth Brings up a good point in the comments. This method will only work if the visitor comes back and makes a second purchase on the site. You can tweak the above logic and set the custom variable on the visitor's return to the website, rather than when they make a second purchase. While this is not perfect it is a workaround.]

I should note that this is an AWESOME custom variable to use in an advanced segment. Actually, they’re all great to use in Advanced segments, but segmenting repeat buyers is especially useful

Purchase History

This is where things get a little more complicated. Tracking things like purchase history requires a bit of configuration on the server side, meaning you or your nerds need to create some code to categorize customers based on the number of purchases they’ve made in the past. Rather than track every single purchase I prefer to bucket the purchases, like this:

1 to 3 purchases
4 to 6 purchases
7 + purchases

You need to have the logic on the server to review the custom’er purchase history and set the custom variable accordingly. The GA JavaScript will look something like this:

_gaq.push(['_setCustomVar',5,'PurchHistory','1-3',1]);

Now you’re probably thinking that there is some duplication with the previous custom variable, and you’re right. The repeat customer variable is a bit more generic and gives you a quick view of new and returning customers. The purchase history variable is geared towards deeper analysis of customer behavior.

So there you have it, five custom variables for ecommerce websites. This is by no means an exhaustive list, but I think these can help any commerce based business to better segmentation and analysis.

Are you using custom variables on your ecommerce website? If so I’d love to hear how!

5 Google Analytics Custom Variables for Ecommerce is a post from: Analytics Talk by Justin Cutroni

Mastering Google Analytics Custom Variables

Justin Cutroni — Wed, 18 May 2011 12:39:43 +0000

I’ve got a stack of posts that I want to write, and realized that the all deal with Custom Variables. So, to make sure that we’re all on the same page when it comes to custom vars, here’s my guide to Mastering Google Analytics Custom Variables.

For those of you that have not used custom variables, CVs are a way for you to insert custom data into Google Analytics. What kid of custom data? Almost any kind of data. As long as the data is available to you in the source code of a web page you can pass it to Google Analytics via a custom variable.

There are 4 parts to a custom variable:

1. The name of the variable
2. The values for each variable
3. The index or slot of the variable and the scope of the variable
4. The scope of the variable

Name & Value

Custom variables are name-value pairs of data. The name is also called the “key”. To create a custom variable you define the name of a custom variable, like Favorite Baseball Team, and then assign it different values, Red Sox, Braves, Giants, etc.

Google Analytics will show you a list of all the custom variable names in a list and then let you drill down into the list and see all of the values.

Here’s an example. I use a custom var named “Year” to track the publication year for all my posts on this blog. I can view which year had the most popular content by finding “Year” in the Visitors > Demographic > Custom Variables report.

Then I can click on “Year” to a get a list of all the values:

Custom variables can also be used in custom reports and advanced segments. The name of the custom variable becomes the “Key” dimension and the value of the custom variable becomes the “Custom Variable Value” dimension.

Index or Slot

The index is a way to organize your custom variables. Index is also referred to as “slot”. At a basic level, you get 5 custom variables. But this can actually be misleading. Think of the index as a parking lot with 5 parking space. You can put or “park” a custom variable in each space.

You can technically have more than 5 custom variables, but we need to discuss the next concept, scope, and how it impacts the index.

Scope

The key to mastering custom variables is understanding the scope. The scope of a custom variables determine how long the custom variable will persist.

If we use the parking lot analogy, the scope determines how long a car will stay parked in the custom variable parking lot.

There are three different scopes for Google Analytics Custom Variables:

Page Level: A page level custom variable will only persist for as the visitor is viewing the page where the custom variable has been set. Once the visitor moves to a new page the custom variable will expire.

Visit Level: A visit level custom variable will persist for the visitor’s entire visit. Once the visit ends the custom variable will expire.

Visitor Level: A visitor level custom variable will persist for 24 months as a cookie on the visitor’s machine until the visitor deleted her cookies.

Where scope really gets complicated is when we use it with the index. Remember, you have 5 slots that can hold a custom variable. Once you place a custom var in a slot that SLOT BECOMES FILLED and you can not place another custom var into the slot.

Scope and index work in tandem to determine how many custom variables you have available at any given time.

Let’s start with a visitor level custom variable.

When you place a visitor level custom var in a slot that slot remains filled until you delete the custom var. Remember a visitor level var is stored as a cookie so you have to actually delete the cookie. So, if you set a visitor scoped custom variable in slot 1 you can NEVER use slot one again. Unless you want to erase the custom var you set in slot 1.

Every time the visitor comes back to your website slot 1 will be filled because there is a cookie (named __utmv) on the visitor machine.

PARKING ANALOGY: There is a car in parking space 1. The car has no tires… and no engine… it’s not going anywhere soon… unless it gets towed.

When you create a visit level custom variable and place it in a slot, that slot remains full for the entire visit. Once the visit ends that slot opens up and you can place another variable in that slot.

Unlike the visitor scope custom variable there is no cookie. So when the visitor comes back to your site that slot is open.

PARKING ANALOGY: There is a car in a parking space 1, but just for the day. The spot will be vacated at the end of the day and someone else can park there.

When you create a page level custom variable and place it in a slot that slot remains filled until the visitor moves to another page. Once the visitor moves to another page the slot opens up and you can place another variable in the slot.

PARKING ANALOGY: There is a car in a parking space 1, but someone is just running into a store. The engine is idling and the spot will open up in 5 minutes.

Let’s look at a couple of examples:

Example 1: A visitor on a news site logs in. I set 5 visitor scoped custom variables. This means that whenever the visitor comes back to the website ALL five slots are filled. I can never use any other custom variables unless I erase or over-write one of the existing variables.

Example 2: A visitor is on a blog. Each blog post is categorized 3 ways using a page level custom variable. on every page I set the same 3 custom variables. When a visitor logs in I set a visitor custom variable to identify them as a member. So now I have 3 page level variables and one visitor level variable. The slot that contains the visitor level variable will always remain full, so I need to make sure that I always place my page level variables in the same slots.

Example 3: A visitor logs into a news site. I set 5 page level custom variables when they log in to record various pieces of information about their membership. One the next page I fire of 5 different custom variables to record information about their past browsing history. In this senario I have actually set 10 custom variables. How? Because they are all page level custom variables. The slots associated with a page level custom var open up when the visitor moves to a new page.

Hopefully this explains how you can technically have more than 5 custom variables.

The Code

Like everything else in Google Analytics, you implement Custom Variables using JavaScript. All of the topics we discussed above, index, name, value and scope, are all part of the JavaScript.

Here’s the standard Async code snippet:

_gaq.push('_setCustomVar',index,'name','value', scope);

The index is a number, from 1 through 5.

The scope is also a number. A value of 1 indicates a visitor scoped custom variable, a value of 2 indicates a visit level custom variable, and a value of 3 indicates a page level custom variable.

The name and the value are just plain text. Whatever you enter into the code above will be pulled into Google Analytics.

Where do you put this code? That’s the hard part. You place this code when you want to create a custom variable. You may want to categorize all of the pages on your site using a page level custom variable. In this case you might place the custom var code in the standard GA code snippet, like this:

Or, if you’re going to identify someone as a ‘member’ of your site, you might place the code on a page after the visitor logs in. Like this:

But you can also attach the code to visitor action, like onClick events.

You can also create custom variables for mobile devices using the iOS SDK and the Android SDK. How cool is that!

And some of the super nerds I work with at Cardinal Path have been able to hack custom variables and set them using the Google Analytics Mobile Tracking code for low-end mobile devices.

Regardless of the platform that you’re tracking, you can probably use a custom variable.

Super Nerd Stuff

Custom variables are not without their limitations and oddities. Here are a few things you need to be aware of when implementing:

1. What happens if you place a custom variable in a slot that is already filled? The last value placed in the slot is applied to the visit.

2. Custom variables are sent to Google using the same invisible image request. In the old days (ie two months ago) the size of this request was limited to 2048 characters by the browser. Because this limitation can really restrict data collection, Google decided to limit the size of your custom variable. This means that the name – value combination must be less than 64 characters. I know, this sucks.

BUT, Google has since changed how it collects data. The size of the image request is now 8000 + characters. So, in theory, Google could kill the 64 character CV limit. But they have not…

~~3. Custom Variable processing lags the standard data processing by about 24 hours. However, if you add a custom variable to a custom report it will be visible. I know, completely weird.~~ This is really only for very, very big sites, where data processing can lag in general.

4. Page level custom variables are more-or-less the same as an event. When you create an Advanced Segment using a page-level custom variable, GA will return the number of visits that included that custom var. So, if you don’t have enough slots available you may want to consider using an event.

5. When you set a custom variable the data is sent immediately back to Google Analytics via an image request. This means that if you set a custom variable, on the last page of a visit and AFTER the pageview is recorded, that custom variable will NOT be collected by Google Analytics. If you can, put your custom variable code BEFORE _trackPageview().

That’s ALL I have to say about custom variables. Hopefully this gives you a good baseline understanding of how they work and how to implement them.

If you’re using custom variables leave a comment. I’d love to hear how you’re using them.

Mastering Google Analytics Custom Variables is a post from: Analytics Talk by Justin Cutroni

Merging Google Analytics with your Data Warehouse

Justin Cutroni — Fri, 06 May 2011 01:37:24 +0000

Many of the projects that I’ve been working on over the last 6 to 9 months have evolved to include more and more data integration. Specifically companies are looking to import more Google Analytics data into other systems to do various types of analysis.

Data integration is nothing new, companies have been doing it for a long time. I’ve written in the past about integrating Google Analytics with CRM data.

Other analytics vendors have been supporting this functionality for a while. But I think as more organizations move to Google Analytics they’re looking to get the same functionality as their other tools. Hence this uptick in data integration.

So I figured this would be a good time for a high-level overview of the most common way to integrate Google Analytics with a data warehouse.

What is a Data Warehouse?

In reality a data warehouse is just a big database that pulls from lots of different sources. A businesses would build a data warehouse to do more complex types of analysis. Other types of data you might find in a data warehouse is customer data, purchase history information or demographic information.

When all of this data is put together you can do some interesting types of analysis. For example, you can do better analysis about online behavior and offline conversion. Or tie long-term purchase history to online behavior.

Another benefit of building a data warehouse is the ability to create very custom marketing segments. Adding information about conversion behavior and marketing activities can help augment historical sales data and create new marketing programs.

Gary Angel wrote a great post on some of the reason why you would want to build a data warehouse. Avinash Kaushik also wrote an interesting counter-point, why you might not want to build a data warehouse.

My opinion, this is very useful, but do it in an agile, flexible way that does not take years. This stuff changes too fast to rebuild.

Almost all data integration projects revolve around a primary key. A primary key is a unique number that exists in different data sets. Because this number exists in multiple data sets you can connect the data sets using the key.

To add Google Analytics data to a data warehouse you need to add some type of primary key to Google Analytics. In most of the work that I’ve done this key is a visitor ID. This anonymous identifier usually comes from some other system like a CRM.

When we add the customer ID to Google Analytics we store in a visitor scoped custom variable. This means that the ID is stored in a cookie on the visitor’s machine. We normally set the cookie when the visitor makes a purchase or logs into the site. Basically any time we can positively identify the visitor.

For the sake of this example I’m going to use a little piece of JavaScript to create a unique ID for visitors. I’m actually going to extract a unique ID from the Google Analytics __utma cookie. Then I’m going to set the unique ID in a custom variable, specifically in Custom Variable slot 5.

NOTE: The function _ugc() is a generic function that get’s a cookie value. In this case it’s extracting part of the __utma cookie.

Once the ID is in the custom variable we should start to see data in Google Analytics, specifically the Custom Variables report. Here’s the custom var:

And here are all the visitor IDs:

I know what you’re thinking, “You can’t store personally identifiable information in Google Analytics!” But this isn’t personally identifiable information. And besides, this is the same as the transaction ID stored in the ecommerce data.

Now that we’re done debating PII, we need to merge this data with other data. This is where things get complicated. The rest of the process is all programming. And all the programming is custom. The language you use, how you store the data, it all depends on your IT department and their platform of choice. The rest of this post is meant to be a high-level overview.

First, let’s extract the data from GA via the API.

This query will generate a list of all the unique IDs stored in the custom variable. The key dimension in this query is ga:customVarValue5, that’s the value of the Custom Variable in slot 5 which holds the IDs. I’m using the Data Feed Query Explorer to test these queries.

The basic query is something like this:

https://www.google.com/analytics/feeds/data? ids=XXXXXXXXX& dimensions=ga:customVarValue5& metrics=ga:visits& start-date=2011-04-20& end-date=2011-05-04& max-results=50

And the data coming back would look something like this:

So where do you put this query? You need to create some type of code that runs automatically. You might pull data from Google Analytics daily or weekly. It all depends on the volume of your data and your specific needs.

Once I have a list of IDs I can create some looping logic, again part of an automated program, that iterates over the list of IDs and makes an API request for each ID number found above. This second query will get detailed information about each individual ID.

The secret to the second query is adding a custom segment that includes the ID number. Look for 1041533899 in the query below. That’s the ID number I pulled from the first API call above.

https://www.google.com/analytics/feeds/data? ids=XXXXXXXXXXX& dimensions=ga:customVarValue5,ga:date,ga:source,ga:medium,ga:keyword,ga:pagePath&metrics=ga:visits& segment=dynamic::ga:customVarValue5==1041533899& start-date=2011-04-20& end-date=2011-05-04& max-results=50

With this query I’m getting the data, the traffic source, keyword and all pages that the visitor viewed. I could also pull things like revenue, conversions… But I’m looking for data that I don’t already have via some other system. So I would stick to things that are happening on the site, like where the visitor came from and what they did on the site (watch a video, use a calculator, etc.)

Once this query comes back it’s time to do the data integration. You might want to manipulate the data before you store it in a database or you might choose to insert the raw data. Again, a lot of this depends on your specific environment.

The important thing is that you now have the data. Integrate.

Gotchas To Watch For

There are some definite gotchas when implementing this type of soltion. Most notably, you need to deal with data sampling applied via the API. From the Google Analytics API docs:

Google Analytics calculates certain combinations of dimensions and metrics on the fly. To return the data in a reasonable time, Google Analytics only processes a sample of the data. In these situations, the metric data returned in each entry includes a confidence interval.

So massively huge data sets might need more frequent queries. Or you might need to break the data down into multiple profiles and then query it via the API. Again, this is what makes this type of solution so custom.

Another limitation is that each query is limited to a maximum of 7 dimensions and 10 metrics. But you can get around that with some creative queries.

Thanks for sticking through this rather vague post. I know it lacks some detail, but this is a very specific technique that can differ from one client to another.

Merging Google Analytics with your Data Warehouse is a post from: Analytics Talk by Justin Cutroni