Archive for the ‘Google Analytics’ Category
Posted on February 9, 2012 by Sayf Sharif
Before I even start talking about this, let’s go to code.google.com for the official recommendation on where someone should place their Tracking Code on their webpages…
The Analytics snippet is a small piece of JavaScript code that you paste into your pages. It activates Google Analytics tracking by inserting ga.js into the page. To use this on your pages, copy the code snippet below, replacing UA-XXXXX-X with your web property ID. Paste this snippet into your website template page so that it appears before the closing </head> tag.
The Google Analytics Asynchronous Tracking Code
Ok! Thanks for reading, see you next time!
Just kidding, of course it’s not that simple.
So seriously, where should I put my Google Tracking Code?
We actually get people asking us about this a lot. It’s one of the first items in our audits that we look at. What version of the tracking code are you using, and where is it on the page. There are plenty of variations, but the most common one if it’s not completely up to date, is having non-Asynchronous (or ‘traditional’) tracking code, which is placed at the bottom of the page. So when the first item in our audit says “We recommend you update to the Asynchronous tracking code, and move it’s placement into the <head> of your document, rather than at the end of the <body>” people get worried.
Is it bad to have the Google Tracking Code at the bottom of the page? I read that you should put it there at the bottom, rather than up in the head because it makes your site faster.
Should you place the tracking code in the <body>?
The quick and dirty answer is that yes it’s safe to put the new code really anywhere on the page, and for 99% of users, you’ll want to use the Asynchronous code and put it in the head of your document. There are a few exceptions/alterations which I’ll note in a minute.
The less quick part of that answer is that it WAS bad to put the traditional Google Tracking Code in the head of your webpage in the past, so if you read some book or blog purporting to speed up your website extolling the virtues of putting the Google code at the bottom of the page, then they may have been correct once, but they aren’t anymore. The speed of the internet, and all that jazz.
Google released the Asynchronous Tracking code on December 1st, 2009. Prior to that point all we had was the traditional code, and it worked like most other basic JavaScript code. That is to say that it would go one line at a time. So when your browser loaded up a line of code, it would load that line only, and then wait till that line was fully loaded. Then, and only then, would it move to the next line, and then load that line, etc. Like a single conveyor belt. The problem with that design though, is that if you ran into a snag the entire page would hang. So if the Google Tracking Code back then was placed at the top of your webpage in the head of the document, then the speed your site loaded was partly determined by how quickly Google sent you that code. If it took Google 10 seconds to send you that code, that was 10 more seconds your visitor had to wait to view the page. That’s why it was recommended to put that code at the very bottom of the page. That way if it stalled in loading the files from Google, at least your page was loaded first.
The Asynchronous code though works differently. Rather than say a SINGLE conveyor belt, now there are multiple ones, and the rest of your page can load up regardless of how long it takes to retrieve data from Google. The tracking code loads up on its own conveyor, while the rest of your site loads on another.
And on top of that the Asynchronous code is designed to be downloaded only once from Google, and then it’s served from your cache (i.e. it’s saved on your computer and you won’t have to download it again), which makes it that much faster.
You lost me poindexter, what does that mean for me?
It means the asynchronous tracking code averages a 5% improvement in tracking data, with some sites showing 10 and even 20% improvement in their data. If you use Adwords, it closes in on 100% accuracy with the asynchronous code.
The asynchronous code is faster, and therefore you get better more accurate numbers as to how many people are actually visiting your site.
What if I have events or things happening on the page, where I need to record user actions, and the tracking code hasn’t loaded yet?
Well, that problem would also happen if you had the non-async code firing at the bottom of the page, but with async it’s much better. Even if it takes time to load the ga.js file from Google, it’s already set up the tracking variables on the page, and will store the events you perform before the actual file is loaded. Once the file loads, then all the events backlogged will be sent to Google. It’s not PERFECT, but for the most part it will capture events that happen prior to the Google tracking code has even finished loading, and send them after the code has been loaded.
So do I need to move it to the head of all my pages? I have a lot of pages, and that’ll take a lot of time.
You can put your tracking code anywhere, but it's better in the <head>
Nope. You can put it anywhere you want really, and It’ll run anywhere on the page whether it’s in the head or the body. It’s recommended you put it in the head though, so it can be as accurate as possible.
You see, the Pageview is recorded only after that code is loaded up. So the sooner you load the code, the sooner that Pageview is recorded. Let’s say you have a big blog page, and it’s a slow loading one, taking even 10 to 20 seconds to load everything up. If your Google Code doesn’t start until the end of the page, it can get held up, just like the old non-asynchronous code used to hold up OTHER lines of code. Except now it’s holding up the tracking code. If a visitor to your site hits the page, and then leaves it before the tracking code fires the Pageview, then you lose that visitor. They now become a new direct visit to whatever page of the site they landed on. This can make all sorts of data on your site incorrect.
So it’s best practices to use the Asynchronous code in the head of your page, it won’t slow down the rest of your page from loading, and by having it there it won’t GET slowed down by the rest of the webpage either, so it’ll fire sooner, and you’ll get a more accurate count of what pages your visitors visit.
So what are the exceptions? When is it BAD to run the tracking code up in the head?
I mentioned before that there ARE a few exceptions. One is if you’re setting custom variables on the page.
If you set a Custom Variable on your webpage then it will essentially sit on your page, waiting for either a pageview to be tracked, or an event to be called. If you set a custom variable on a page and don’t track a page or an event after it, that custom variable will NOT get passed to Google. Sometimes you might not be tracking any events on a page, but you’ll want to set a custom variable. Because of how code is delivered, it’s possible that custom variable might only get generated AFTER the head document. Usually a page can be coded so that these variables can be determined before the HTML is delivered and then you can have the custom variables created in the head of the document as well. Maybe it could theoretically be put in the head, but the developers didn’t build the page that way, and you’re not willing or able to have them redo everything. In those cases you can set a Custom Variable anywhere on the page, and then rather than tracking the pageview in the head of the document, you remove this line:
_gaq.push(['_trackPageview']);
from the Asynchronous code, and then insert it later in the page wherever you like, after the custom variables are set. That way the code loads up, it doesn’t interrupt the page load, and you can then track custom variables on the page itself anywhere they appear, as well as retaining the benefit of loading the tracking code early.
HOWEVER, this can also reduce accuracy, because if a user navigates away before that trackPageview is called, then you’re facing the same problems that the traditional code presented in the first place. Another option would be to use Event Tracking. An event being fired will also submit that queued custom variable, so you could fire an event tied to that custom variable. Essentially a throwaway event.
_gaq.push(['_setCustomVar',1, 'Status', 'Logged In']);
_gaq.push(['_trackEvent', 'Custom', 'PageLoad', 'Setting Logged In State',0,true]);
A couple notes on this:
First we’re setting the Custom Variable, we’re assigning it to key space 1 (of 5), and we’re calling it Status, and setting the value to Logged In. That’ll sit there until an Event or Pageview is tracked.
So we do the event. We set it to a Custom category group, we definte the action as PageLoad because a user isn’t specifically interacting with this event. Then we set the Label as to what the event is doing. We add a 0 to the value (you don’t have to add an actual value there if we’re not using it, but I’m personally uncomfortable passing nothing). We also then set the non-interaction value to true. This is also key if you use an event here. If you don’t set it as true, then the event is considered a page interaction, and it will affect your bounce rate from the landing page. Essentially rather than someone coming to your page looking at it and hitting the back button being considered a ‘bounce’ It would not be considered one because the user ‘interacted’ with the site. So we set this to true, so that isn’t considered in that respect.
But wait, I read something on Google’s own support pages that said I shouldn’t do this?
You mean this page?
Yeah, you don’t believe everything you read, do you? That’s old outdated support information.
So if we update is it going to change my data? Like am I all of a sudden going to see more pageviews or something?
It’s possible. It depends on your site, where the code was, what sort of speed and pageload times you have. By updating you should see the data you’re getting change, maybe a little, maybe a lot. But it’ll be MORE ACCURATE data. Here we tend to side with getting the data to be as accurate as possible, even if there is a bit of a break in the levels of reporting.
If I don’t update, will my site continue to track data?
Sure. It probably won’t be as accurate, but depending on your site it’s conceivable it’s not a huge data difference. The main functions are all loaded from the same place, the ga.js file. The main difference is how it loads, how fast it loads or is even cached in your browser, and therefore the accuracy of your data.
So what should I do?
If you’re NOT using the up to date Async code you should update to using that. You’ve really got to have some serious things going on to NOT update. Does it need to be in the head of the document? No, it won’t kill you to have it at the bottom of the page, but if you CAN move it to the top, then you should because it’ll be faster and more accurate. If you don’t know of a reason to keep using the non-async code at the bottom of the page, and you’re not using custom variables… Then really there is no reason to NOT update it and move it to the top of the page. You’ll have more accurate data, you’ll get newer and better tracking features, and more. Come on. Everyone’s doing it.
View Comments (No Responses) | Categories: Google Analytics
Posted on January 26, 2012 by Dorcas Alexander
After you learn about campaign tagging for Google Analytics, you may be excited that you can add all that extra information to a simple little link – so excited that you want to put campaign tags on every kind of promotional link that leads to a web page on your site. But there’s one kind of link that should never get campaign tags. You should never put GA campaign tags on internal banners or on-site promotions that lead from one page of your site to another.
Why You Shouldn’t Use GA Campaign Tags for Internal Promotions
Imagine this sample scenario: A visitor clicks an email campaign link from your latest marketing effort and lands on your site. Google Analytics records the traffic source and starts collecting data for the visit. Of course you hope that the visitor will continue to view pages on your site and maybe even convert on an important goal like registering for an upcoming conference or buying your latest e-book. When they do, you’ll be able to attribute that conversion to the campaign and evaluate that campaign’s success.
But what happens if the visitor clicks an internal banner with campaign tags before they convert? Google Analytics records a new traffic source and starts a whole new visit. So now you have at least two problems: You’ve split what was really one visit into two visits, skewing your data. And you can’t tie the original email link directly to the conversion, because the conversion happens in a separate visit.
To track internal promotions without splitting visits and losing credit for conversions, try one of these instead:
- Add your own campaign parameters (not GA campaign tags) to the links and view the data in your Content/Pages reports
- Use event tracking when a visitor clicks an internal banner or promotional link and view the data in your Content/Events reports
Alternative #1: Add Your Own Campaign Parameters
The first method involves making up your own tags, ones that GA won’t recognize and will pass right along into your Pages reports with the rest of the URL. Instead of utm_source or utm_medium, for example, you might simply add something like “from=promo” to the target link:
http://www.anything.com/buy-ebook.html?from=promo
Or you could use a more detailed scheme if, for example, you run internal promotions with many types of links in different places. So you might have one parameter similar to campaign name, like “campname=e-book”, and another parameter that describes the links, like “camplink=home-page-banner” or “camplink=side-nav-feature”:
http://www.anything.com/buy-ebook.html?campname=e-book&camplink=home-page-banner
http://www.anything.com/buy-ebook.html?campname=e-book&camplink=side-nav-feature
As long as you stay away from Google Analytics utm parameters, these types of URLs will appear in your Content/Pages reports and you can tell by the number of pageviews exactly how many times a visitor clicked the tagged link to arrive there.
Alternative #2: Use Event Tracking
The second method involves adding a bit of code to the link on the page. Inside the anchor tag (a href=”…”) include an onclick event like this (a href=”…” onclick=”…”). And in the onclick event, add the event tracking code using an event category and action like “internal promo” and “home-page-banner”:
onclick="_gaq.push(['_trackEvent', 'internal promo', 'home-page-banner', this.href]);"
After the event category and action it’s a good idea to include the optional event label. For the label you can simply write the target (href) of the link, using this.href.
View this data in your Content/Events reports by drilling into Top Events through the “internal promo” category, where you can see the how many times someone clicked each of your different internal promotional links.
Combine with Custom Variables for Goal Data
Okay, so where’s the goal data? You may have noticed that Google Analytics has Goal tabs in Traffic Sources reports, but not in Content reports. The whole point of these alternatives was to keep your original traffic source intact so you could tie it to a conversion. But you probably also want to know how well your internal promotions lead to conversions, too, right? Of course you do.
Well, there’s another set of reports that has Goal tabs, where you can combine conversion data with a set of dimensions that you define, and that’s the Audience set of reports. You can write a custom variable with the parameters or event data you created in either alternative described above. And then you can easily compare goal conversion data in a single table that lists all your internal promotions.
The thing to remember when writing custom variables is that the data needs to piggyback on a _trackPageview or _trackEvent call.
For the event tracking alternative, add _setCustomVar to the onclick event, like this:
onclick="_gaq.push(['_setCustomVar', 1, 'internal promo', 'home-page-banner', 2]);_gaq.push(['_trackEvent', 'internal promo', 'home-page-banner', this.href]);"
For the other alternative where you make up your own campaign parameters, I suggest adding _setCustomVar to the page that’s the target of the link, right before the usual call to _trackPageview. You can use a little Javascript to read the URL and write the custom variable according to the campaign parameters that appear there. For example, if the URL is:
http://www.anything.com/buy-ebook.html?campname=e-book&camplink=side-nav-feature
The resulting custom variable code (placed before the call to _trackPageview) could be something like this:
_gaq.push(['_setCustomVar', 1, 'e-book', 'side-nav-feature', 2]);
In both cases I’ve set a session-level custom variable (indicated by the number 2 above), and I’ve set the custom variable to slot number 1 (out of 5). If you are already using that slot then you’ll need to assign it to another one. Read our post about how to keep track of custom variable slots and scopes for more guidance.
No More Split Visits
Avoid the split-visit problem. Keep visit data together by keeping internal and external promotions separate. Track your external campaigns with GA’s utm parameters and try one of the above alternatives for internal campaign tracking. And tie both external and internal promotions to conversion data to evaluate the success of each.
What methods do you use for tracking internal promotions? And how do you tie them to conversion data? Please share in the comments.
View Comments (5 Responses) | Categories: Conversion Science, Custom Variables, Google Analytics
Posted on January 11, 2012 by Jim Gianoglio
Create an account, copy the code, and paste it on every page of your site. Easy, right?
Not so fast.
If you’re just starting out using Google Analytics, you may not be aware of all the advanced code implementations available, much less how to modify the code for your needs. But if you are tracking across subdomains or multiple domains, or if you want to do some advanced tracking with events that’s exactly what you need to do.
To make matters worse, navigating through the labyrinthine administrative interface to find the tracking code snippet can be somewhat daunting. Especially if you’re used to the old version of the interface. And although the code wizard in GA does include several configuration options, the instructions are neither complete nor easy to follow for beginners.
To solve these problems, the team at Raven Internet Marketing Tools has built the Google Analytics Configuration Tool. (Full disclosure: we provided consulting on some of the technical details for this tool, so of course we’re thrilled to see it’s birth). They just launched this free tool, aimed at simplifying the process of configuring your Google Analytics. Out of the gate, there are several specific situations they provide instructions for, including:
- One domain with subdomains
- Multiple domains with subdomains
- Site search setup
- 404 error page tracking
- Event tracking
- Setting up goals
- Tracking Facebook page and referrers
There’s also a URL builder for tagging your URLs with campaign parameters.
Besides just giving you the snippet of code, the GA config tool leads you step by step, asking questions about what you’re trying to track and then providing the code and instructions of what to do with it. It also provides the code in either asynchronous or the traditional ga.js.
This is a godsend for people who don’t deal with GA on a daily basis. Trying to figure the correct code configurations has generally meant wading through a sea of posts in the help forums, where the information is often outdated and inconsistent. This tool takes the guesswork out of the setup, letting you focus on what matters – your data!
Coming from the folks who also created the Schema Creator (for creating structured markup for your site), not to mention their core suite of internet marketing tools, this will be an essential addition to many digital marketers’ arsenals. They’re already working on adding functionality to help with regular expressions, setting up filters and other points of analytics confusion.
Go try this tool out and let us know what you think. Are there any other GA-related instructions you’d like to see added? What is it about GA that is most confusing to you?
The comments are yours.
View Comments (4 Responses) | Categories: Google Analytics
Posted on January 5, 2012 by Phil Anderson
This is part 2 of a multi-part series on increasing conversions from your website traffic. If you haven’t already, you should read part one, which introduces the Infinite Conversion Loop.
The old cliché – “How do you know where you’re going, if you don’t know where you’ve been?” is especially applicable to Analytics. Before you can even hope to get a handle on increasing the conversion rate of your website, you need to make sure you’re actually tracking all of the things that will help you analyze what’s going on!
The most common problem we encounter with customers here at LunaMetrics is an incorrect or incomplete Google Analytics configuration. Here’s a checklist of a few of the things you should definitely be doing before going any further in the conversion loop.
- Is the tracking code on EVERY page (and is it functioning)? To get a complete picture of your website, you need to see how all content is performing, including legacy content, 404 pages, terms of service, you name it. If it can potentially be viewed by a person, I’d recommend putting tracking code on the page.
It’s also recommended you update to the Asynchronous code if you are not already using it. In my experience it provides much more reliable numbers. The second question of “is it functioning” can be tested by looking at your data in GA, and also using an HTTP monitor to make sure the utm.gif is being requested on page load.
- Are sub-domains and cross-domains being tracked correctly? You need to be able to see how people are flowing from one domain to another to assure conversions are being attributed properly.
- Are goals configured, with funnels? Specifically, are they configured correctly? Being able to visualize funnels will be key for analysis.
- Is E-Commerce configured? All E-Commerce sites should have E-Commerce configured (obviously) to track dollar values of transactions. But really any site that can provide a concrete monetary value to an action should have this. Does a confirmed lead generation add to your E-Commerce? What about a donation?
- Is AdWords Linked? If you do any type of AdWords spending, it’s crucial that you link your account to be able to see how well these campaigns are working.
- Are Campaign tags being used consistently and efficiently? Are you even using Campaign tags in your marketing?
- Are you tracking Events? I recommend tracking any high value action as an event. If people are leaving your site for a third-party site, that should be tracked as an event. Downloading a file, clicking a drop down menu, it’s up to you to decide what actions make the most sense as events.
- Is Site Search configured? This is one of the most useful things you can do. If you have a search box on your site, more likely then not a confused visitor will do a search to find what they are looking for. If they still don’t find what they want from your search, you can guarantee this will add to your bounce rate. (On the flip side, often a really useful search box can make up for other navigational problems your site may have).
- Are you tracking Social Engagement? Today “The Net” is much more then the web. If you don’t have a social component to your site, you should consider adding some type of social sharing widget right now. Once you have that installed, it’s important to see how and where it’s being used to get a picture of your engagement. That’s where the GA Social Engagement plug-in comes in.
- Is AdSense linked? If your business relies on AdSense as a revenue, you’ll definitely want to see how it performs on your site.
Now that you have all of this setup, next time we’ll talk about how to analyze this data (beyond page views and visitor counts!) to figure out what’s going on with your site and how you can begin to optimize.
View Comments (1 Response) | Categories: Google Analytics, Web Analytics
Posted on December 30, 2011 by Michael Harrison
Everyone can agree: Google Analytics’ custom variables are a great feature. It lets you label your visitors with all sorts of fun stuff. Male or female? Member or non-member? Cat person or dog person? If you can identify your visitors’ answers to these sorts of questions, you can tag them with a custom variable.
But sometimes website owners implement the custom variable code and start gathering these valuable segments of traffic, completely unaware that the numbers aren’t very accurate. What could be causing such a heinous mistake?
Believe it or not, Google warns against the issue right in those instructions there, but they don’t call it out quite enough for my taste. It’s extremely important that you “call the _setCustomVar() function when it can be set prior to a pageview or event GIF request” (emphasis mine). Here are the details:
In certain cases this might not be possible, and you will need to set another _trackPageview() request after setting a custom variable. This is typically only necessary in those situations where the user triggers a session- or visit-level custom var, where it is not possible to bundle that method with a pageview, event, or ecommerce tracking call.
What exactly does this mean? Well, if a visitor fills out a survey on your site, hits submit, and you run _setCustomVar() after the _trackPageview() of the submission success page, that _setCustomVar() call just sits there in deep space, waiting for another _trackPageview() or _trackEvent() function to carry it along to Google’s servers. If that is the visitor’s final pageview in the session, then the call floats away forever, never to be heard from again.
The worst part, though, is if the visitor goes to another page, then the _setCustomVar() will tag along with any subsequent GIF requests. This means that it may appear as if the custom variable is working just fine, according to the reports in Google Analytics, but the numbers are just inaccurate.
So, to ensure that you are tracking your custom variables as precisely as possible, make sure that you always run the _setCustomVar() function before the calls to _trackPageview() or _trackEvent(). If this isn’t possible–you have an include at the top of every page, for instance, and can’t modify it–then be sure to include a second pageview or event after the _setCustomVar() function, like this:
_gaq.push(['_setCustomVar', 1, 'membership', 'gold', 1]);
_gaq.push(['_trackEvent', 'Tow Truck', 'go', '-', 0, true]);
This will ensure that every single time that function runs, it gets counted. Guaranteed!
Update: Tyson Kirksey, of Vertical Nerve, reminded me to set the event to non-interaction mode so that it won’t influence bounce rate, pages/visit, time on page, etc. I’ve also borrowed his clever naming convention for the event. Thanks, Tyson!
View Comments (3 Responses) | Categories: Custom Variables, Google Analytics, Web Analytics
Posted on December 27, 2011 by Brittany Baeslack
If there’s one PPC practice that should be instilled among all advertisers, it’s to make your brand stand out: not just physically or visually, but behind the scenes as well.
Of course, advertisers want their brands to stand out above the rest, that is a given; but it’s important to keep this same methodology in place when compiling your PPC campaigns (and I’m not just talking about writing an eye-catching ad).
Here’s an example: Imagine you work for an athletic shoe company. If a potential buyer searches “(Your Brand Here) women’s tennis shoes,” you don’t want your generic keyword “women’s tennis shoes” to battle with other brands’ generic keywords in order for your ad to appear. Sure, it’s possible that your generic keyword will trigger your ad as a result of this search, but chances are that any click captured in this way will be much more expensive than a click as a result of a branded keyword. You’re paying more for that click than you should have, and fighting for that click with more competitors than necessary; having brand keywords could have helped your ad show up in a better position while obtaining clicks at a lower price.
PPC gurus know that to develop a successful structure for Paid Search campaigns and accounts overall, product and services should be grouped tightly, in order to ensure potential customers are seeing ads that are relevant to their search queries and landing on site pages that take them where they need (and want) to go. You’d be surprised, however, by how many advertisers group their brand keywords with generic non-brand keywords, assuming that as long as the campaigns and ad groups are specific enough, brand and non-brand keywords will work the same. Moreover, you’d be surprised at how many advertisers don’t bid on brand keywords at all! Always make sure you have brand keywords throughout your account… always! I have seen VERY few instances where not bidding on brand keywords has been the better choice for an advertiser.
The Value of Separation
While the simple example above explains why it’s important to have branded keywords within your account, we still haven’t touched on why these terms should be separated. Just as any campaign in a PPC account is separated from another, brand and non-brand campaigns perform differently, and can therefore be managed differently.
Let’s use another example from the same athletic shoe company: The keyword ‘women’s tennis shoes’ should not be found in the same ad group or the same campaign as the keyword ‘(Your Brand Here) women’s tennis shoes.’ The main reason for why we should do this is obvious: user intent is different, and therefore performance is different. When a user types a brand name into a search engine, whether or not it is long- or short-tail, that person already has that brand on his or her mind. Therefore, a campaign consisting of only brand terms will almost always have a higher click-through rate than generic campaigns, while also likely spending at a lower rate due to the lower price of the keywords themselves.
Put it to Use
As I touched on in a past blog post, click-through rate is the strongest factor in determining quality score, and having a strong quality score is key for PPC accounts. While you can’t see the direct effect of quality score instantly, the strong click-through rate of brand campaigns will earn you some extra brownie points with Google when it comes time to determine CPCs and ad rankings. Mixing brand and non-brand keywords in the same campaigns would not result in the strong click-through rates an all-brand campaign would see. In another blog post I also explained the value and importance of negative keywords, and brand vs. non-brand is a perfect example of such usage. By having brand and non-brand keywords separated, you can ensure branded searches are never triggered by generic (and remember, more expensive!) keywords by setting your brand name as a negative throughout your generic campaigns/ad groups. This will help keep your costs stabilized and also ensure that the best ads are showing up for the right searches.
Split your branded keywords into appropriately relevant campaigns and ad groups just as you would non-brand campaigns. Once this is complete, I recommend giving these brand keywords strong max CPCs to ensure they appear in top rankings. Also be sure that the ads contain your brand name itself in the headline, so that potential customers see right away that you are the company they are looking for.
Thanks to Google’s automated rules tool, you can set a rule to run for these campaigns that will ensure these keywords remain above a certain average position, specified by the advertiser. I recommend setting a rule to keep the average position of keywords somewhere between 1.5 and 1.3, but this should be set based on what you know works for your keywords (and this can be changed at any point in time).
When a keyword drops below the set position, Google will increase the max CPC by the amount of the advertiser’s choice, and will discontinue any bid increases when it reaches the maximum CPC you indicate (if you so choose). These changes can be made based on the time interval of data you choose, but I usually set the rule to run based on data from the previous day, and to run everyday around noon or 1pm. I highly recommend the use of this tool – there are many different ways to set automated rules and they can be updated or discontinued at any time.
Setting up separate brand campaigns will help you efficiently capture additional conversions at a lower cost, while allowing you to separately manage your more expensive generic keywords with results that won’t negatively affect the results of your brand keywords.
View Comments (No Responses) | Categories: Google Analytics, Paid Search
Posted on December 22, 2011 by Dorcas Alexander
What does it mean when “search/organic” turns up as Source/Medium in your Google Analytics reports? It could mean some of your visitors are using the search engine Search.com (yes, there really is a search engine called that), but it could also be bad data because Google Analytics mistakenly attributed visits to Search.com even though they came from somewhere else.
How could that happen? Suppose your site www.anything.com has a search box (of course it does!) so visitors can search the entire site. Unfortunately, the site search engine returns search results pages with URLs like this:
search.anything.com?q=anything
I say, “unfortunately,” because that’s exactly the kind of URL that Google Analytics mistakes for the search engine Search.com.
How Site Search Gets Mistaken for Organic Search
Google Analytics keeps a list of search engines, and it recognizes them by looking for certain items in the referring domain and referring page query string. If the domain contains “search” and the query string contains “q” then GA thinks the referrer is Search.com.
There’s even more bad news. Suppose this visitor originally came to your site from an email campaign, which you cleverly tagged with cool campaign info (newsletter/email), as you should. As soon as the visitor uses your site search, GA mistakenly sees a new traffic source (search/organic)… and starts a brand new session.
This scenario played out recently for one of our clients. The previously documented solution, using _addIgnoredRef, did not work. So we reported it to Google engineers, who reproduced and confirmed the issue and promised to get back to us with an update.
In the meantime, we devised a simple workaround that immediately improved the data. If your data has been compromised by this issue, it can help you, too.
How To Fix It
Our solution is a little script that we include on every page on search.anything.com. The script looks at all the links on the page and if a link goes to anything.com, it appends a parameter to the URL that tells GA not to change the source/medium to search/organic.
jQuery.noConflict();
jQuery(function() {
jQuery("a").each(function(index) {
var link = jQuery(this);
var href = link.attr('href');
if (href.indexOf('www.anything.com') != -1 && window.location.href.indexOf("search.anything.com") != -1)
{
jQuery(link).bind("click", function(l) {
location.href = href + (href.indexOf('?') != -1 ? "&utm_nooverride=1" : "?utm_nooverride=1");
return false;
});
}
});
});
If you’re already familiar with GA parameters you’ll see the key to the script is the parameter utm_nooverride=1, which is more typically used when visitors return to your site from third-party shopping carts, or for ad campaigns where you don’t want to overwrite existing referral data.
In this case, utm_nooverride=1 means GA won’t write a new traffic source (and mistakenly start a new session) just because a visitor uses site search.
Remember you also need to refer to the jQuery library before you call the script, like this:
<script type="text/javascript" src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
Have you come across this issue on your own site or a client’s? If so, how did you handle it? Please share in the comments.
View Comments (No Responses) | Categories: Google Analytics, Web Analytics
Posted on December 7, 2011 by Jim Gianoglio
If you weren’t in Paris today (c’est la vie!), you may have missed Google’s announcement at Le Web. Don’t worry, we’ll fill you in on the details. The announcement unveiled their efforts to collect data from social networks and platforms in an effort to be able to more fully report on social activities related to your site/business/product/etc. that may not happen on your site. For example, wouldn’t it be nice to open up Google Analytics and see which of your content was shared on Facebook, tweeted about, or plus-oned, Dug (or Digged?), Stumbled, commented on or otherwise mentioned?
Social platforms are being invited to integrate their activity streams with Google Analytics. To do this, Google has built a social data hub to make it easy.
The social data hub
The social data hub is a data platform based on open standards to enable social data partners to submit their activity streams, eventually making the data available to Google Analytics users. This means that GA customers will be able to determine down to the activity level – e.g. +1 button, comment, vote – what activities are taking place relevant to their content, when, by whom, and how they help achieve goals.
The social data hub will make it easier to aggregate social data that analytics users are looking for. It isn’t a product in and of itself, merely a standardized process to get data into GA. This will help marketers and publishers easily access and measure all social platforms and actions side by side.
Who’s in?
Google is kicking this off with a respectable list of partners:
- Delicious
- Digg
- Diigo
- Gigya
- LiveFyre
- ReadItLater
- Reddit
- TypePad / SixApart
- VKontakte
(and of course)
- Google+
- Google Blogger
- Google Groups
However, to make any future social reports useful, they have a lot of work to do on the data acquisition side. Measuring social media without including Facebook and Twitter (and arguably LinkedIn) is a lot like measuring SEO without looking at Google, IMO.
Fortunately, this announcement is aimed at attracting more social networks to the social data hub. The benefit, they claim, is that by social networks providing their data to GA, marketers and publishers will more easily be able to see the value of social media to their business, prompting them to use/spend more with those networks. It’s a pleasant spin to be sure, but it remains to be seen who will jump on board.
Eventually, this data will make its way into GA, allowing users to see both on and off-site social engagement with their content, including visibility into social actions such as voting, commenting and sharing, amongst other metrics. This brings us one step closer to analytics nirvana - the ability to connect social activity and conversions.
The technical details
Google will be following the Activity Streams Specification (yes, there actually is one), for describing socially interesting events, or “Activities,” about the people and things an individual may care about. In its simplest form, an activity consists of an actor, a verb, and an object. It tells the story of a person performing an action on or with an object. For example, “Robbin posted a photo” or “Phil shared a video.” Any of the data submitted may potentially be used but it must adhere to the specification.
View Comments (No Responses) | Categories: Announcements, Google Analytics, Social Media
Posted on December 1, 2011 by Michael Harrison
If you’ve been to one of our Google Analytics trainings, you may have heard me say this: tracking visitors from one domain to another is a huge pain in the neck. Whenever someone goes from domain1.com to domain2.com, you have to take their cookie data and pass it over to the second domain via the URL. If you don’t, the visitor generates a new visit and their referral data gets jacked up.
Normally, this is a tedious, manual procedure. After making a minor change to your Google Analytics Tracking Code, you then have to modify every link on domain1.com that takes a person to domain2.com. If you have a few links, no big deal. But what if you have thousands of them?
We’ve posted before about automating the cross-domain tracking process, but a lot has happened since then. Namely, Google Analytics has a sexy new asynchronous tracking code. So we finally got around to creating a script that automatically links domains using the new code syntax.
Not only that, but this script tracks outbound link clicks and downloads, all automatically. They’ll show up as events.
We’re pretty proud of it, and since it’s so darn useful to us, we figured we’d share it with you. Give it a try and let us know how it works for you!
Step 1: Modify Your Google Analytics Tracking Code
First, you’ll need to make sure that your Google Analytics Tracking Code is set up to allow for cross-domain tracking. The _setDomainName and _setAllowLinker methods are required for this to work:
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-Y']);
_gaq.push(['_setDomainName', 'domain1.com']);
_gaq.push(['_setAllowLinker', true]);
Make sure that _setDomainName is set to the second-level domain that the tracking code resides on.
Step 2: Download and Modify the Script
Click here to download the script, then modify the domains and file types you’d like to track.
If I wanted to track the domains lunametrics.com and lunametricsstore.com, I’d modify line 5 to read:
var domains=["lunametrics.com", "lunametricsstore.com"];
And if I wanted to automatically track downloads for PowerPoint presentations, I’d add .ppt to the list on line 6:
var fileTypes=[".doc", ".xls", ".exe", ".zip", ".pdf", ".mov", ".mp3", ".ppt"];
Step 3: Upload Script and Include on Pages
Upload the xdomain.js file to your web server and then reference it on all pages of your site. Place the reference below your Google Analytics Tracking Code:
<script src="/path/to/xdomain.js" type="text/javascript"></script>
Because the script relies on jQuery, you will also have to reference the jQuery library at some point before the call to the script. You can download a copy of the jQuery library and host it on your web server, or just reference the one hosted by jQuery:
<script type="text/javascript" src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
Step 4: Test It!
To make sure the script is working, click on one of the links that takes a visitor from one domain to the other. Check the URL that displays in your browser location field after the new page loads. You should see a string of information in the query string:
You can also view your cookies (I use Firebug and Firecookie). Check out __utmb. The number after the first period is the pageview count. If cross-domain tracking isn’t configured properly, then it will reset when you hit the secondary domain.
__utmz should also maintain the proper referral. If you visit your primary domain directly and then move to your secondary domain, __utmz should still reflect this:
Conclusion
Hopefully this helps you set up cross-domain tracking (and outbound link tracking and file download tracking) on your site easily, without a lot of headaches.
This script was a collaborative effort by myself and Phil Anderson, who did most of the heavy lifting in jQuery. It’s supplied as-is. We’ve tested it internally, but it’s your responsibility to make sure it works on your own sites. And if you notice anything that doesn’t seem to be working, you’re free to correct the code. It’s released under the terms of the GNU General Public License, so feel free to modify and redistribute. We just ask that you keep the copyright notice on the top, and that you share any cool additions with us so we can use ‘em too!
View Comments (16 Responses) | Categories: Google Analytics, Web Analytics
Posted on November 17, 2011 by Christina Keffer
Playing the saddest song in the world...
Over the past few weeks since Google implemented SSL encrypted search results pages that block keyword data for users signed into their Google accounts, SEOs have been pulling their hair and gnashing their teeth. It’s true, and it’s warranted. One of the best SEO KPIs is reporting on the quantity of organic search traffic generated by highly qualified keywords. Now that between 9 and 20% of this data is generic, it’s harder for us to prove our worth and progress. So we’re justifiably upset.
However, as objectively as I can be, I would say that removing data for organic searches has far wider reaching consequences than depriving SEOs of one of their prime KPIs.
One of my friends who owns a great hip hop dance video eCommerce store and I got into a debate last weekend about how it’s not just SEOs who are affected by this change. My argument, which I could not deliver with any eloquence that night, (Friday at 10pm after happy hour and wine at dinner — you do the math.) I will now present here.
Why The (Not Provided) Keyword Hurts the Web
Let me begin by asking a question: Why do webmasters care about rankings? Because rankings=traffic and traffic=some benefit (either monetary or otherwise.) The only thing that webmasters want to do is get their site ranking for relevant terms that drive qualified traffic. To do so, they optimize their sites for those terms.
It is in the webmasters’ best interests to focus on keywords that drive qualified traffic, and to make their site as relevant as possible for this valuable traffic. But how, you may ask, do webmasters know whether they are optimizing for the right things?
What if someone searching for “vice grips” typically wants to buy and someone searching for “locking wrench” typically wants to find out more about the applications for that tool? Both of those words could apply to the same tool, so webmasters look at their conversion data and engagement metrics to find out how to make their site fit the wants and needs of the searcher.
By doing so, they inadvertently give the search engines exactly what they need and want: a page that matches user intent and is valuable to the searcher — who will then use that search engine again because the results were exactly what they were looking for.
The decision to try to rank a product page for vice grips vs. locking wrench has to be informed by keyword data since Google doesn’t provide exact clickthrough data — even through webmasters tools. This data should be statistically significant.
I would hazard a guess, however, that most sites out there don’t have statistically significant traffic over the short term. So even if the site really IS the best result for a specific search, they are already at a disadvantage. Now, however, about 10 – 20% of their already slim keyword data is generalized.
So, the webmaster makes a decision based on personal preference or the opinions of peers in his industry and optimizes his sales page for vice grips. He manages to rank pretty highly for that and can’t understand why people are bouncing so much.
Google, in turn is ranking him appropriately to his level of optimization, but for the wrong keyword and the result is not what the user was looking for so they loose too.
*sigh*
So, why is Google denying analytics users this important information? There is a lot of speculation that it is in an effort to push site owners to depend more on paid search data… up their paid search traffic since they can’t get accurate data through the organic channel anymore.
If this is the case, it seems really short sited to me. The only reason why most people search Google is to get the organic results. Clicking on a paid result is a bonus. If the organic results decline because webmasters don’t have the right information to make education decisions about their site, then Google looses money because people will start using other engines.
If they really are trying to stave off a privacy issue, either present or future, then why is the data still available for paid search? Have people that click on paid links entered into some type of implicit agreement that their search data is less private than those who click on organic results?
Regardless of their motives, the change will detrimentally affect the web in general, search results specifically, and the ability webmasters to make good decisions.
As an SEO, I admit that I’m personally put out by these changes because they make my job harder and who likes that? (See above image.) However, I really and truly believe that the web as a whole will be drastically and negatively affected, especially if more and more people sign in to a Google account while searching.
View Comments (12 Responses) | Categories: Google Analytics, Search Engine Optimization, Web Analytics
Subscribe to this blog's feed
