You probably already know about the Funnel Visualization and Goal Flow reports in Google Analytics. They’re a great way to understand how users complete (or don’t) some kind of process on your website, such as filling out a series of forms, like a registration or checkout.
Sometimes, though, there isn’t a clear path. On this site, for example, we have a contact form that doesn’t just appear on one page, it appears in lots of pages, and this isn’t an uncommon feature of lead generation sites. Likewise, sometimes people say things like, “Well, page X is our goal. But you can actually get here either by going A > B > X, or by A > P > Q > X, depending on what options you choose.” How do we know which way people got to X?
The Reverse Goal Path is a report that helps fill in these details. You’ll find it under Conversions > Goals in the left-hand navigation in Google Analytics, and like all the goal reports, you can select a particular goal you want to see from the drop-down at the top. It’s very simple: it gives you the goal completion URL and the URL of each of the 3 pages that came immediately before. You don’t have to predefine a funnel or anything, it simply looks 3 pages back in the visit and tells you what they were.
So here’s an example from our contact form. The first column is the “Goal Completion Location”, which in this case is always /about-us/contact/thank-you/. Then each of the subsequent columns walks back one page, telling us whether someone was on the home page, the contact details page, the client list, etc. No funnel necessary!
To sort out this information, note that you can use the advanced filter. So if you’re only interested in one particular path or page, you can narrow down the possibilities you’ll see here.
We know you’re eager to start paid search; it can be a crucial way of bringing potential customers to your site. But there are a few things you should make sure you have in place to be successful.
1. Work the Numbers
Stop. Do not pass go. Do not deposit $200 in your AdWords account (yet).
First, figure out what your conversion is — a sale? a lead form submission? Then you have to try to figure out how much money it makes sense to pay to bring people to your site so that you get more value from that conversion than you spend on the advertising.
You can go at this two ways. If you know the value of the conversion (you sold a $100 widget), you can work the ROI calculation backwards to figure out what a reasonable cost per conversion and cost per click might be. Alternatively, if the value of the conversion is less well-defined (like in lead generation), you might simply pick a reasonable target for cost-per-lead.
As the avid users of AdWords know, Google Analytics has a great report that pulls in cost data from AdWords. If you have an ecommerce site or currency values assigned to your goal conversions, it’ll even calculate ROI.
A while back, Google Analytics announced new support for importing cost data from other sources: think Bing Ads, Facebook advertising, etc. This is great! It puts all the power of those AdWords reports to work on your data from any kind of advertising. (more…)
As a followup to my post on interpreting Language data in Google Analytics, here’s some insight into locations as well.
You can find the Locations report under Demographics in the Audience section. Google Analytics determines locations from a visitor’s IP addresses and where internet service providers assign those ranges. (If you remember the dark old days of web analytics when you could look at a report like this and you saw that 80% of US web traffic came from Virginia — because that’s where AOL was located — you can rejoice that these reports are much more accurate.) (more…)
The Languages report is among the most cryptic of the reports in Google Analytics. It looks like you need a secret decoder ring to figure out what it’s telling you. Here’s some guidance on what those codes are and what they mean.
What are they?
These language codes represent a language and optional country variant. (We’ll look at where GA gets these momentarily.)
The codes aren’t specific to Google Analytics; in fact, they’re based on two ISO standard specifications: (more…)
Don’t have a mobile site? That doesn’t mean you have no mobile visitors. In fact, Google Analytics is already measuring visitors from smartphones and tablets to your site, and you can use this data to figure out what’s important to these visitors and how well your site is working for them.
You can see mobile visitors in the Mobile reports under Audience. First, there’s the Overview report, which just says “how many visits came from a mobile device” (and that includes tablets):
As you may know, Google Shopping search (aka Froogle, aka Google Product Search) recently ceased being a free service and was rolled into AdWords. It still works essentially the same way: it starts with you uploading information about your products into Google Merchant Center. But now, instead of those just showing up in organic product results, they only appear as sponsored listings if you connect your Merchant Center to your AdWords account and choose to display them.
Data about products shows in paid listings in a couple of ways…
(1) In what’s called a “product extension” to an existing AdWords ad (which has been around since even before the change to an all-paid model).
In Part 1: How to Implement, Brian told you all about how to get an iFrame app or tab set up in Facebook. Now I want to talk about how we can track it.
In the past, there were a number of methods for trying to track Facebook using Google Analytics. None of them worked particularly well (for a bunch of boring technical reasons like image caching and cookie domains). Now, however, since we’re putting our very own pages on Facebook via iFrames, the situation is much improved.
Before I go any further with the How, let me be clear about the What:
- We can track iFrame applications on canvas pages or on tab pages in our Facebook profile. This includes any interaction people take within the iFrame, as well as information our app can get from Facebook through its SDK (such as whether they “like” us already or not). We’ll get the same tracking on the iFrame pages as any other page on our own website.
- We cannot track behavior on non-iFrame pages on Facebook — even something on our profile if it’s not an iFrame, like your Wall or Info page, for example. And if someone gets to our pages simply by browsing from elsewhere on Facebook, we don’t know where exactly they came from (Facebook obscures this for privacy reasons).
Put the regular Google Analytics tracking code on the pages you’re including in your iFrame. Here are some guidelines about additional things you may want to keep in mind:
- You may want to create a filtered profile that includes just the pages that are on Facebook, so that you can easily track their traffic separately.
- If the pages for your app are on your regular site’s domain, they share the same cookies that your regular site does. This means GA already recognizes a returning visitor, uniques get counted correctly, etc. Basically, the Facebook app functions as an extension of your site, even though folks are seeing it on Facebook.
- If there are interesting things people can do with your app (and there should be!) set up goals, events, or other GA methods to measure them as appropriate. You could, for example, set a custom variable for all the people who’ve “liked” your page, or even just visited your Facebook tab before, so that you can connect that fact to all the conversions that happen over on your site.
- You may want to make an alteration to the tracking code as described below.
One tactic that’s becoming more common is to use social media as landing pages for advertising and marketing campaigns. For example, you might run promotions that link to your app or tab saying “Try our app and enter for a chance to win X” or “Like us on Facebook and get a free shipping coupon” or whatever.
What we commonly do in Google Analytics is use campaign-tagged URLs to measure these kinds of sources of traffic. We can do this with Facebook, too, but we may need to be a little tricky.
If you are sending people to an app directly (that is, to a canvas page with a URL like apps.facebook.com/my-app-name), you can include campaign tags in the landing page URL and they are passed through to the iFrame page. No problems there.
If you are sending people to a tab page (that is, to a tab within your profile with a URL like www.facebook.com/my-page-name?sk=something, for example), Facebook obscures the referrer to the iFrame page. It’s always something like static.ak.facebook.com/platform/page_proxy.php, and the campaign parameters don’t get passed through. (Facebook does these things, not to make your analysis difficult, but for privacy reasons.)
However, there is a solution for tracking campaigns linking to tab pages, and it’s a pretty simple one. There are two parts to making it work:
- Create a page on your site that redirects to the Facebook tab, and link to this page from your ads with the appropriate campaign URLs. On this page, run the GA tracking code before the redirect.
_addIgnoredRef(“static.ak.facebook.com”) to the tracking code on your iFrame page(s) in your Facebook tab.
In step 1, when a user lands on this page, the GA tracking code runs, sees the campaign tags, and records the campaign values into your cookies. Then we send them along to the Facebook tab.
In step 2, when the user gets to the Facebook tab with the iFrame, the cookies already exist with the right values (and since the iFrame pages are on the same site as the original redirect page, there’s no problem with sharing those cookies). However, what we don’t want to happen is for GA to see the referrer for the iFrame page and say “Oh, this is a referral from Facebook” and overwrite the campaign information that’s already in that cookie.
So, we use
_addIgnoredRef, which is a function in Google Analytics that just ignores a certain referrer. By including this, referrals from static.ak.facebook.com (that is, to all our iFrame pages) will simply be treated as direct and not overwrite any information that’s already in the campaign cookie.
Here’s what the code should look like, depending on which flavor of the Google Analytics tracking code you’re using:
// asynchrounous version
// standard version
This should come after you specify your account number but before the _trackPageview (because that’s the point at which the cookies get written, so we have to tell it to ignore the referrer before that).
Then, all our campaign parameters work out, and we don’t get static.ac.facebook.com overwriting any of the campaign info.
You get all the same data in GA you’d get for any page on your site, because the iFrame pages are pages on your site. You can also include them in goal funnels, use them to define advanced segments, etc. Your Facebook app or tab basically becomes just like any other page in your GA data.
One of the features of the new Google Analytics is being able to use your events as goals. This was an often requested feature that is finally making its debut.
What are events?
First, let’s review: what’s an event? Event Tracking, in a nutshell, is designed to capture all of the non-pageview stuff that we might be interested in on a site. By default, Google Analytics captures just when pages load (through the regular tracking code on every page), but it doesn’t capture things that happen within pages, like clicks on downloads, or AJAX elements that bring in new content without a reload, links to third-party websites, or plays of videos embedded in the page. Basically, anywhere someone clicks or otherwise interacts with the site, we can track.
Those of you who have been around the block with Google Analytics may also know about “Virtual Pageviews”, which used to be the only way to track these kinds of clicks. It added a pageview, which showed up alongside all your “real” pageviews in the Top Content report, and added to the total number of pageviews to your site. This is as opposed to events, which have their own separate set of reports and get tallied up separately. Additionally, there’s only one piece of information we get to specify for the virtual pageview (an imaginary URL), while events give us more categorization options (up to four pieces of information called the category, action, label, and value).
Events as goals?
Google Analytics lets us set up goals to tell it what we want people to do when they come to the site (whether it’s buying something, submitting a form, etc.). We can even set up funnels that tell us about a process that leads up to a goal.
It used to be that Google Analytics only allowed us to specify goals by a URL. So with goals that were pageviews, no problem. But what if we wanted to measure a click, like a download or an outbound link? Well, there were always virtual pageviews, but that inflated the pageview numbers for our site. So tracking these kind of clicks became an exercise in trade-offs:
- Do I want the click to count as a pageview, or not?
- Do I need to use the click as a goal (or in a funnel)?
- Do I need the extra categorization options available with events?
Now, however, you can use events as goals. So even if I’ve used event tracking instead of virtual pageviews to track my PDF downloads, if I want to set up a goal, that’s OK, I can do it.
Here’s what the goal setup screen now looks like to set up an event-based goal:
The Google Analytics Blog has a pretty good run-down of the options for setting up an event-based goal.
What doesn’t it do?
This is great, because it gives us a lot more flexibility with events than we once had, and makes moot some of those trade-offs between events and virtual pageviews I discussed above. However, there are still some limitations; primary this one: with event-based goals, there are no funnels. There’s just the goal. So unlike page/URL-based goals, I can’t specify some ordered steps that visitors go through to get to the final goal.
In my opinion, the ideal way this would work is for Google Analytics to allow us to mix events and pages in a funnel and goal setup. Suppose I have a funnel that looks like this:
- User loads the white paper download page (Pageview: /downloads)
- User selects a download and loads a request form (Pageview: /downloads?file=1234)
- User fills out some contact information and submits in an AJAX form (Event: category/request, action/submit, label/1234)
- User gets a link to the PDF download and clicks it (Event: category/download, action/click, label/1234)
Notice I have a mix of URLs and events in this sequence. Ideally, I’d love to set up a funnel that lets me do this, and specify any combination of pageview or events in the steps of my funnel. You can’t do this (yet, at least).
The little elves in the Google Analytics factory are always making improvements, but this is a biggie. They’ve been working on this under wraps for a long time, and today Google Analytics finally pulled back the sheet on a new version. It introduces a new interface and builds a platform for further improvements going forward.
There are lots of new things, and we’ll be covering many of the features in detail over the coming few weeks. Here’s a run-down of some of the highlights:
- Dashboard with improved customizability. Even though I just wrote a couple of weeks ago how the GA dashboard might be better than you thought, now it’s even better. You get to choose the format of widgets (charts, tables, single metrics) and you get to title them yourself with something meaningful. And, you can create multiple dashboards and use them for different profiles. So far conspicuously missing: the ability to export or email the dashboard.
- Improved organization of reports. The report navigation is re-organized to make a little more sense, grouping together similar reports and making similar data accessible right within a single report instead of multiple similar reports.
- New report design. It does all the same kinds of things as before, but with a streamlined interface. It also has some little nuggets of improvements we’ll cover later.
- Pet peeve yay! When you navigate around and switch accounts or profiles, GA remembers better where you are — which report, which date range, even which advanced segments. There are exceptions, though — Robbin found that when you switch from custom reports to regular reports, your advanced segments get turned off.
- Speaking of advanced segments, Pet peeve 2 yay! You can now apply multiple advanced segments (still up to 4 at a time) but you no longer have to select “All Visits” as one of the four.
- New, improved custom reports. The ability to save a filter with a custom report, among other improvements. Currently, my “old” custom reports aren’t showing up here, so not sure what the migration plan for those is.
- Rejiggered management interface. Probably the least sexy but most important part of this all. The account management interface is re-arranged to make a bit more sense of account, web properties, and profiles and allows for better management of shared items between users (like advanced segments and custom alerts). Although it’s not very exciting (and it’s not all there yet), this lays the foundation for better account management features and sharing of customizations between users.
With all the changes, you might be worried that everything you know about Google Analytics is going out the window and you’ll have to learn it all over. Don’t fret: almost everything you already know is still here. In some cases it’s a little rearranged or streamlined, but your favorite reports are still available and all the same data is still there. There’s even a report finder to help you find your old reports in the new version.
I Want It!
You may or may not be able to see this now. Google is rolling out beta access in waves over the coming weeks. When you get the option, a link will appear at the top of your GA reports that says “New Version”, like this:
For some time, while this is still a beta, you’ll have the ability to switch back and forth between the new and old versions — so just in case there’s something you used to know how to do but haven’t figured out yet in the new interface, don’t worry, you can still do it.
Most importantly, remember that it’s a beta. Although the Google Analytics team, Google Analytics Certified Partners, and others have used and given feedback on this interface, the GA team will be closely monitoring how a broad spectrum of users make use of this new version, and the feedback they give, to continue to make enhancements and correct issues.