Save Money On Placements With Google Analytics
Google’s display network can bring you tremendous amounts of clicks and conversions if used correctly. If it is not used correctly, you can quickly spend mass amounts of money and have nothing to show for it.
A couple years ago, I wrote an article on how to manage the display network so you can spend most of your money on sites that are bringing in quality traffic. This is a quick graphic of the workflow that I still use today.
- The ‘Discovery Campaign’ is one of your lower daily budgets, and its goal is to find good placements where you want to spend more money
- The Placement’s Campaign is one of your higher budgets as it only contains sites that are helping you reach your overall goals
While I find this workflow is very useful, the overall problem is when do you decide to block placements? In your AdWords account, the only data you can see for any placement is conversions and conversion rates. The problem with so little data is that if you wait until you have enough statistically significant data to make a decision, you will never find all of the good placements, and spent too much money on bad ones.
There is another way to gain insight into placements with Google Analytics that you can use to determine if a site is sending you quality traffic.
Evaluating Placements with Google Analytics

To have access of this data you need to link your Google Analytics account to your AdWords account. Next, navigate to the placements information under the AdWords reports (found under traffic sources).
If you have goals setup, then you can sort by the goal completions, conversion rates, and other data points to find the sites that are doing well for you.
While this data is useful for adding placements, it can also be useful for finding placements that you want to block even if you don’t have statistical data.
Sort Placements by Bounce Rates
Instead of trying to find sites that you want to add as placements, examine bounce rates to find sites where the traffic is so poor, you don’t want to wait for statistical data.
In this case, we have a handful of sites that have sent more than 18 visitors and have a 100% bounce rate. No one from any of those sites has even gone to a second page, therefore, we will often block these even though we don’t have statistically significant data.
Please note, you don’t want to just block sites if there bounce rates are 100%. You should also double check the ad copy and landing pages to make sure the offers are relevant for that site. If you consistently see high bounce rates for your display campaigns, then you might need to change the offer and landing page before deciding to block placements.
Just remember, a bounce in Google Analytics is a visitor who only went to a single page and then left your site. If someone gets to your landing page, picks up the phone and calls you, finishes an order over the phone and then leaves your site – they will be counted as a bounce even if they spent twenty minutes on the phone with you.
Create Interaction Goals
A quick way of seeing what sites are bringing in good versus poor traffic is to create interaction goals within Google Analytics. With Google Analytics, you can create goals based upon time on site or page views per visit.
If you create goals with these types of metrics, then you can easily examine what sites are not meeting your basic minimum interaction and then block those sites that are underperforming.
Conversely, if you find that sites are bringing in visitors that are spending several minutes on your site, you shouldn’t block those sites until you have enough clicks to determine if those visitors will eventually convert.
By using interaction goals, you can gain another level of insight into the placements where you are spending money, so you can make better decisions about block the sites or spending more money on the sites to gather more data.
If you have various types of goals on your site, I would recommend splitting out these types of goals by goal set. You might have one goal set that is all revenue events, and another one that is site interaction. By splitting these different types of goals out by goal set, then you can see one tab of just interaction goals, and another tab of just revenue goals. That way your revenue goal events will not be polluted by site interaction events and vice versa.
Conclusion
Overall, I like Google’s display network. There is a lot of traffic and conversions to be had from managing it correctly. However, if managed incorrectly, the display network can be a money pit. Therefore, you do need a system for managing the display network so it will perform for you.
However, the patience and money required to always have statistically relevant data is beyond what most AdWords advertisers have. Therefore, when you see sites that have several visits and 100% bounce rates, feel free to block them quickly. When you see sites that have some visitors, and those visitors are spending time on your site, then you should be more patient in determining if the site will eventually be a converting one for you.
By using Google Analytics to examine your AdWords data, you can go beyond just examining conversion rates to also determining interaction rates and gaining another viewpoint into the placement sites where you are spending your money, so that you can spend your budget as wisely as possible.
Save Money On Placements With Google Analytics is a post from: Certified Knowledge
Should Your Paid Search Account Care About Bounce Rates?
My latest Search Engine Column is out, if you missed it – you can read it here.
Most companies measure paid search based upon revenue targets, ROI goals, and conversion rates.
Metrics such as bounce rates are generally left for the web design team to figure out, or the paid search term to obsess about without any clear strategy.
In this column, we will examine bounce rates and put them in the proper context of PPC optimization.
Defining the Bounce
When someone bounces from your website, they are considered a non-engaged visitor. Someone came to your site, didn’t find what they want, and before going to any other pages – they decided to leave. Bounces are often used in usability to try to increase user engagement; however, they can also be used in the world of paid search.
First, let’s define a bounce. In Google analytics, a bounce is a one page visitor. If someone came to your site, spent twenty minutes on the page, and then left, they would be considered a bounce. Some analytics systems considered bounces five second or thirty second visits. You should understand how your analytics system determines a bounce.
A bounce rate is just the percentage of bounces. For instance, if you have 100 visitors and 20 of them bounce from your site, your bounce rate is 20%.
What is a Good Bounce Rate?
This is just as hard a question to answer as, ‘What is a good CTR?’ The reasons are very similar. The most specific the word’s intent the lower the bounce rate as the query will better match the page. The less specific the query, the higher the bounce rate. Of course, the layout of the website has a lot to do with bounce rates as well. Here are some overall numbers:
- 20% or less is amazing
- 20-30% is fantastic
- 40-60% is fairly common
- 60-70% is common for keywords that are a bit ambiguous (TV Sets, Laptop)
- 70% or higher – something needs to be fixed
Of course, you need to temper that with your sites goals and functionality. There are times 87% bounce rates can be good.
When Bounce Rates Don’t Matter
If you take a quick look at this screenshot, what do you think of the bounce rate?
Most will consider 87% too high regardless of the site. While revenue is listed, since you don’t know the spend you can’t tell if the revenue is good or not.
The revenue for this account was generated off of roughly $150,000 in spend. That spend amount makes the revenue look fantastic. It is rare to see such a high bounce rate and revenue numbers on the same screen. That’s why you need to examine the functionality of the site. For NDA reasons, I can’t show the actual landing page, but this is the buying process:
- Paid search to landing page
- On landing page, you can input your credit card
- On landing page, you can:
- Checkout
- Review order
- Navigate through other parts of the site
On this site, most users checkout from the landing page. Therefore, most two page visits are actually conversions. This site has both an 87% bounce rate and a 10% conversion rate.
In this case, bounce rates are not necessarily a prime metric.
Consider this example:
- Searcher clicks on your ad and arrives at your website
- Searcher calls you
- Searcher spends twenty minutes on the phone with you
- Searcher buys a product over the phone
- Searcher leaves your site to check for their receipt in email
In this scenario, the searcher was a bounce according to many analytics systems. When phone calls are involved, someone can be a bounce and a new customer at the same time.
When Bounce Rates Matter
Many sites require a user to navigate through multiple pages before they can check out. In that case, a bounce means a lost customer.
Some sites make money on page views (via selling ads), therefore, bounces are bad for revenue as page views per visitor along with RPV (revenue per visitor) are very important numbers.
When your analytics looks like the above image, it is easy to become complacent about bounce rates. Not too many sites have a campaign that brings in 229,197 visitors with only a 10% bounce rate (row 2 in previous image).
In cases where bounce rates matter, you should not just look at revenue, but also areas of opportunity. First, examine the areas where you have the highest revenue per visitor and buy more traffic on those keywords.
Secondly, you can sort analytics to find your areas of opportunity. Follow these simple steps:
- Examine the metrics by both campaign and ad group (you can use keyword if you desire, but it will be a lot more data to sort through)
- Sort bounce rates high to low
- What most will see is lots of ad groups with a very small percentage of visitors. Therefore, add another filtering.
- Use the advanced filter to filter by a minimum number of visitors based upon your site’s traffic
This now gives a starting place to examine areas where there is little visitor engagement. What often happens is that companies are buying traffic that is higher in the buying funnel than direct sales. Therefore, you cannot necessarily apply typical ROI principles to these keywords. However, you do want to ensure the visitors are engage with your site for these keywords. Utilizing bounce rate reports can help you achieve these awareness goals.
Most Common Reasons for High Bounce Rates
When you see high bounce rates in paid search, it is usually due to one of a few reasons:
- The keyword is very broad and has an ambiguous intent
- The search query does not match the landing page
- Commonly associated with poor account organization or use of broad matched keywords
- The ad copy made an offer that isn’t on the landing page
- The ad copy didn’t accurately reflect what would happen after the click
- The site loads slowly, improperly, is ugly, or is hard to navigate
- The analytics code is not installed properly
- Consumers are taking action from a single page
When you see high bounce rates – do not blame the keyword first. Take a look at:
- Keyword or placement
- Actual search queries
- Ad copy
- Landing page
High bounce rates can occur when just one of those items does not compliment the others. You might be able to just change the offer in your ad copy and see your bounce rates decline if the ad copy was not properly describing the landing page.
Conclusion
Bounce rates may not be a primary metric for most paid search advertisers. Paid search is generally optimized from a revenue standpoint. However, there are only so many tweaks that can occur inside your PPC account before you must examine other metrics to continue improving your paid search profits.
Once you branch out from your account settings to examine your website and landing pages; then you significantly expand the number of metrics you can work with that will help you optimize your account.
One of the best places to learn more about your paid search account’s performance is by examining bounce rates. Find areas of your account where the visitors are not becoming engaged in your site and test variations of ad copy, keywords, and landing pages to try and lower the bounce rates.
Just remember, bounces rates don’t always matter. If your primary metric is a phone call you might completely ignore bounce rates and instead focus on pages that don’t lead to calls.
When bounce rates do matter, then remember: when someone bounces off your website, you lose a potential sale.
Every time you turn a visitor from a bounce into an engaged user, you have a chance at increasing your profits.
Should Your Paid Search Account Care About Bounce Rates? is a post from: Certified Knowledge
Converting To Asynchronous Code

There's a pretty strong push now for everyone to move to the new Asynchronous Google Analytics Tracking Code. It's the only code that's available from the interface now, and nearly all of the documentation includes examples of this as the primary code to be used. Converting your code to the new async code might seem like it's just a hassle, but there are benefit to using the new code. Because the code loads asynchronously, there's no longer any danger that it will interfere with the loading of the rest of your page. This means that the code can now be placed up in the header of your pages rather than right before the closing </body> tag. The result is that you'll be able to track a greater percentage of your visitors than your were previously, which will improve the accuracy of your reports in Google Analytics. Now if your setup isn't too complex, converting won't be too big of an issue. Your old code might look something like this:
Notice that the only modification on this code from the standard code is the line for subdomain tracking. The approach to converting something like this to the new asynchronous code is pretty standard:
Google has provided several migration examples if you need more information. But what if your code is a bit more complicated? Perhaps you've added initial referrer tracking to your Google Analytics Tracking Code:
The trouble with this type of modification is that it includes a bit of logic in addition to the standard tracking method calls. Something like this certainly looks possible:
This will work just fine for this example. But your code most likely looks very different and may have even more modifications. The benefits of the asynchronous code certainly sound nice, but do you really have the time and resources to change the code, test it, and then figure out where you missed a bracket or comma? Fortunately, there's a fairly straightforward way to convert just about any traditional Google Analytics Tracking Code snippet to the asynchronous code:
I personally like this style a lot for several reasons. It can turn the conversion process from a 1 to 2 hour project to a 10 to 20 minute project. There are also far fewer chances to make mistakes. Rather than having to change every single line, you can follow a few simple steps: 1. Start with the following code:
2. Copy everything between "try {" and "} catch(err) {}" from your old code and put it where it says "// Put your code here." If your code is old enough that it doesn't have a try...catch block, just copy everything between the the last opening tag of your Google Analytics Tracking Code. 3. Replace "_getTracker" with "_createTracker". If you have multiple tracking objects, in addition to pageTracker, like a secondTracker, then you'll need to change the _getTracker lines for these objects a bit more. Something like this should work: secondTracker = _gat._createTracker("UA-XXXXXXX-Y", "secondTracker"); The "secondTracker" in quotes could be anything at all, but using "secondTracker" might make it easier if you have to reference this later on. If you have additional code, such as ecommerce code, you can convert these according to the migration examples. You can also follow the following steps: 1. Start with the following code:
2. Copy your additional code, minus any script tags, and paste it where it says "// Put your code here." 3. If the code used pageTracker as an object, then you're done. If the code uses secondTracker instead, then you'll need to change the "var pageTracker._getTrackerByName();" line to the following: var secondTracker = _gat._getTrackerByName("secondTracker"); You can also just add this line if your additional code uses both pageTracker and secondTracker. One thing that's worth noting in the all of the above async examples is that no where is pageTracker or any other tracking object declared as a global variable. This means that if you have any onclick events that use pageTracker, you'll need to update them as well. While this might seem like another pain to go through, it's actually very necessary to ensure that ga.js has loaded, the tracking object has been created, and all methods already applied to it have been run, in order, before the onclick event can run. The benefit is that you no longer have to use try...catch blocks, checks for object existence, and recurring setTimeout statements to ensure that everything works properly; it's all taken care of for you in a much more robust way. So let's say you had an onclick event like this: onclick="pageTracker._trackEvent('Videos', 'Play', 'Marketing Video', 10);" You would have two options for converting this to async: 1. onclick="_gaq.push(['_trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" 2. onclick="_gaq.push(function () { var pageTracker = _gat._getTrackerByName(); pageTracker._trackEvent('Videos', 'Play', 'Marketing Video', 10); });" Which option should you go with? Option #1 is usually best for simple onclick events like the one above. For longer, more complex onclick events, especially if you're setting them dynamically, option #2 makes a lot of sense since you can simply wrap all of your statements and simplify your conversion process. As a final note, if you need to use secondTracker or some other tracking object, this can be done option #1 style like this: onclick="_gaq.push(['secondTracker._trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" The name preceding _trackEvent in the must match the name you passed to _gat._getTrackerByName. For example, suppose your converted Google Analytics Tracking Code had the following statement: secondTracker = _gat._createTracker("UA-XXXXXXX-Y", "tracker2"); The correct way to reference this in your option #1 style onclick event would be the following: onclick="_gaq.push(['tracker2._trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" The reason you use tracker2 instead of secondTracker is that tracker2 is the name that the tracking object was registered under, while secondTracker is simply a local reference to the tracker2 tracking object. You can avoid this confusion by simply using the same name for both as shown earlier. Also note that we didn't register a name for our local pageTracker objects, so these use the default tracking object, which is referenced without a name in option #1 style statements. Feel free to leave comments if you have additional situations that steps don't seem to address. Also, while the above steps may be enough to fully convert your code, you may still want to consider purchasing support to do this, especially if you have a more complicated setup.
Funnels on the Fly in Google Analytics
So there you are - you're all ready to put more oil in your car, or maybe you're trying to fill your sugar jar. Maybe you're all set to do some ironing, but you need to put some water in the iron. Whatever the reason, it immediately hits you that you'll be needing a funnel - but... OH SNAP!
You don't have one. Or you can't find it. What do you do? You improvise of course!
Quickly and with a MacGyver-like moment of inspiration, you grab a 2-liter bottle from your recycling bin and cut the top off. Phew - that was a close one! Now you won't have oil on your driveway, or water all over your bedroom carpet, and you can go about your day feeling like a secret genius.
Now, a funnel would have still been the best tool for the job, but sometimes it's just not available. What the heck does this have to do with Google Analytics?
Well, Google Analytics has a great built-in Funnel Visualization report, but the problem is that it only works if you have the foresight to build it ahead of time. Funnels are never retroactive - they will only start working the moment you create them. What if you have multiple landing pages? Moreover, what if you only want to look at AdWords traffic? Well, you would need a separate profile in addition to a properly set up funnel, and all of this has to be set up ahead of time.
The problem is that often you won't know what kind of funnel you need until it's too late. Having 20 goals in Google Analytics is great, but you could have a million and it wouldn't make a difference.
The good news is there's hope. That hope is called Advanced Segments. Here's how you do it:
Step 1: Define the funnel.
This part is pretty straightforward. Lay out the path you are trying to get information on, along with any other parameters (AdWords only, US only, etc.), like this:
Step1: /consumer/special/index.html (Landing Page)
Step 2: /order.html
Step 3: /cart.asp
Step 4: /checkout.asp
Step 5: /bonus.asp
Step 6: /order-receipt.asp
Step 2: Create a new Advanced Segment.
First, make sure you change the calendar so that you're looking at the date range you want to analyze. Then click on the 'Advanced Segment' link in the left navigation:
Then click on 'Create custom segment' in the top-right:
Now you're ready!
Step 3: Results!
Let's start with just the landing page. I recommend doing a few things to the segment. First, use 'Page instead of 'Landing Page' and 'Contains' as the match type. Give your segment a name, and then click the 'Test Segment' button:
Make a note of that number - I usually do this in a spreadsheet (see below), although I have plans to use the Google Analytics Data Export API for this.
Next, by adding a second page, we can then see how many people looked at both in the same visit. You can do this one page at a time. Let's use the /checkout.asp page as an example:
Once you've done this for all of your pages, you'll have your improvised funnel report:
Finally, if you want to further segment the funnel, you can repeat the process with an additional condition. Here's the same segment we did before, but just for AdWords traffic:
By doing this analysis, you will get a real feel for how your actual funnels are performing and be able to take better benchmarks before running tests. Plus, you can feel like a secret genius.
7 Common (Newbie) Google Analytics Mistakes
Everyone's new at some point right? Well if you're just starting out with Google Analytics, here are a few things you can watch out for to stay ahead of the game.
1. Missing Page Tags
Probably one of the most common mistakes that can cause problems in your Google Analytics data is missing page tags. Yes, the Google Analytics code needs to be on all pages of the site. It doesn't matter that someone in sales told you that "all we need are metrics from one or two pages." You're setting up Google Analytics already, so you might as well do it right and get accurate data. If any of your sites pages are missing the Google Analytics Tracking Code, you'll start seeing self referrals (where the real source information is overwritten with your site information) and a variety of other issues will occur as well. Comb through the site a few times and make sure you aren't skipping any pages and that every page will register with Google Analytics.
2. Mixing urchin.js and ga.js code
For those of you inheriting Google Analytics projects, you may be faced with the task of maintaining or updating a site that was previously tracked using the urchin.js version of the tracking code. Although Google states it is possible to use both the urchin and ga versions of the code as long as they aren't on the same page, my suggestion is to update the entire site to the new ga.js version of the tracking code. Mixing the two can cause some complications that are better left avoided. Save yourself some future headaches and update everything at once. Plus you'll get some cool new features with ga.js anyway, so why wouldn't you want to upgrade?
3. Not setting up ecommerce correctly
I've had numerous people come to me asking why they aren't seeing any ecommerce or revenue information within the Google Analytics reports. Aside from enabling ecommerce reporting in the Profile Settings, there is actually a separate script you'll need to setup on your site in order to get ecommerce working. Just grab the code and have your developers work their magic to get the dynamic transaction level variables passed into the ecommerce code for Google Analytics. Can't get all those fields? Read more about which variables are required and how to set up ecommerce.
4. Goal Conversion Setup 
An important aspect of effectively using Google Analytics is to track the conversions that take place on your site. Aside from ecommerce you can set up goals within each profile to receive data on desired actions your visitors make on your site. I've seen some strange things when it comes to goal setups, but one of the most common is repeating the goal step in the funnel. After specifying the goal page, you don't need to repeat that step again in the funnel. Hopefully since Google added the "+ Yes, create a funnel for this goal" expandable selection this will help make this task a little clearer.
Also, be mindful of the match type you're selecting. Even with the helpful example next to the Goal URL field, I still see people that enter in the hostname in addition to the URI. If you're unsure about which match type you should use, the interface provides a link to an explanation of when you would each of the match types.
5. Campaign Tags Missing
If you're doing online (and even offline) marketing, you'll need to make sure you're tagging your URLs correctly in order to see metrics from those marketing efforts within Google Analytics. Typically by default in Google Analytics your paid traffic sources (with the exception of Adwords) will come in as a referral, so you must tag your URLs with the Google Analytics tagging parameters in order to see the correct referral information. To tag your URLs you can use our builder tool to generate the destination URL. By adding the necessary query parameters Google Analytics will attribute the visit information to the correct source. For Adwords users, just make sure Auto-tagging is enabled and Google will do the rest for you.
Tagging your URLs is also useful for other marketing efforts, like auto responder emails, offline campaigns, and banner ads. Without tagging your marketing efforts you'll be missing the opportunity to track the progress of your investments, so it's important that these steps are taken to get your Google Analytics data reporting accurately.
6. The Misuse of Filters
Filters can be applied to the information coming into your profiles to manipulate the final data in your reports. However, having an incorrect filter can severely impact the accuracy of your reports. When filtering out your office IP addresses make sure that you are using the correct regular expression. When creating include and exclude filters think carefully about what you're including and excluding. Include filters act as include only filters and will only include the information you specify into your reports. If your reports suddenly drop off and no changes were made to the site, check the filters that are set up on the profile to see if you are accidentally excluding your traffic. Carefully monitor any new filters because once the data has been manipulated (correctly or incorrectly) there's no going back.
7. Improper setup for subdomains and multiple domains.
Take a closer look at your site structure when you're setting up Google Analytics. Do you have any subdomains? Does the visitor ever cross over to another domain while browsing the site? Although this topic can be fairly advanced, tracking subdomains and multiple domains is arguably the most common mistake made by anyone setting up Google Analytics on their site. Check out the Google help files for instructions on setting up your Google Analytics Tracking Code to work with subdomains and for multiple domains to make sure you're getting it right.
Need Your Own Google Analytics Greasemonkey Script?
I write most of my Greasemonkey scripts with the idea that they will be useful to as many Google Analytics admins and users as possible.
But what if you need a script that's very specific to your business needs? Or maybe you've heard about the Google Analytics API and you'd like to use it to tie your Google Analytics report data with data from your back end. You might even just need some custom modifications to your Google Analytics Tracking Code and general setup to get that one bit of data that can make or break your business.
At ROI Revolution, we offer support plans that can be used for nearly any type of Google Analytics project you can think up. You can also use your support time to have us help you effectively configure optimal tracking for your business goals, get a second opinion on that those thorny configuration issues, or just to audit your Google Analytics account setup and make sure everything's working just as it should.
And if you just want your own Greasemonkey script, we can make that happen too.
Learn more about our Google Analytics technical support offerings.




