Web Analytics Blog

Universal Analytics – Now Properly Namespaced

Joe — Tue, 21 May 2013 17:25:46 +0000

Universal Analytics – Now Properly Namespaced

Google's new Universal Analytics platform has a lot of great features. We recently wrote about quite a few of them and there are also many great posts by Justin Cutroni that do a fantastic job of explaining the benefits. One feature has flown under the radar and hasn't been talked about as much: the ability to properly namespace. This is partially because the audience that would need such a feature is probably smaller than the mass audience that can benefit from the more publicized Google Analytics Universal Analytics features. This ability drastically changed from the classic version of Google Analytics. Read on to learn why exactly would someone want to do this and how it is useful.

Why namespace your tracker?

The primary reason you'll namespace your tracker is when you have more than one tracker on your site. Let's say you have international sites and you want a web property for just the US site and a separate web property for each country. BUT, it is also important to see aggregated numbers across your entire ecosystem. For that, you'll use a second tracker for a web property that captures all data across US, Canada, Mexico, Europe, etc. There are a lot of benefits to this, and it is easier than ever before to set this up. Here's an example of using multiple trackers and sending data to two web properties: There are a few other reasons why you'd want to namespace your Google Analytics code. Provided below are a few examples that we've encountered:

You are allowing other websites to embed a widget into their pages and you want to track how often this widget has been embedded and by whom. We assume that you have properly notified the users of this widget that you'll be tracking this data of course.
You operate a service like TypeKit or other technology that is embedded into websites but you want to track usage per account or by website.
You are providing landing page assets to a 3rd party that will be promoting your service and want to capture the number of visits to that landing page (again, we assume you are properly notifying them that you'll be tracking data on page visits).

Problem with Classic Google Analytics

The one concern that all three of the above examples have in common is that there may already be Google Analytics code on the website and you definitely do not want to impact the existing Google Analytics implementation and metrics. Prior to Universal Analytics, this was both a real and common occurrence. We constantly came across vendors that were forcing their own tracking on top of a website's existing Google Analytics implementation and unfortunately there were battles for the same cookies and different settings that caused conflicts like having each pageview be a new visit (and more). It was painful to see all of this happen and in some cases more painful to see some vendors that just didn't get it and refused to properly track things without impacting their own customer's data. From a more technical perspective, in classic Google Analytics, the tracker objects were forced to share the same first-party cookie location; this was the root of the problem. There were a few things we could do to combat this, but it was unreliable when you start to scale out to hundreds of websites. Classic Google Analytics does not have a way for you to namespace the actual cookie; only the code itself. In fact, the classic Google Analytics code would continually battle for ownership of the same cookie and this caused attribution issues, visit accuracy issues, and more.

Solution with Universal Analytics

With the introduction of Universal Analytics, Google has increased the capabilities of the product in numerous ways. One specific way is by allowing namespacing of not only the code and function names, but more importantly the actual cookie (note that there is now only one cookie that Google Analytics uses instead of 5 in Classic Google Analytics). So, let's explore the solution from the point of view of a vendor that has a widget that is going to get placed on hundreds of websites. Let's just make something up and say my widget company is called WidgetFactoryXYZ. Step 1 - Create a new Universal Analytics web property. Step 2 - Grab the provided Google Analytics Universal Analytics code that is provided via the interface after creating the new web property. This default code will look like this: Step 3 - Modify the above code to make it properly namespaced so that there is absolutely no way that you can interfere with someone's existing Google Analytics code (both Universal and Classic). Here's where it gets a little trickier, but we'll walk you through each code change required for this:

Yellow Highlight: We first rename the function from 'ga' to '_gaWFXYZ'.
Blue Highlight: This is done both on the main code block as well as for the Google Analytics tracking functions.
Green Highlight: Then, we removed the domain part of the string since we don't know where this code will be placed. Universal Analytics, by default is going to store the Google Analytics cookie on the top-level domain (excluding the leading dot). The next step is to give our custom tracker its own distinct cookie name. For this, I kept it the same as the function name, but it could really be called anything you want as long as it doesn't conflict with an existing cookie - just keep it unique.

By making the above code changes, we've completely separated the logic of the Universal Analytics code from any other on-page logic that a website may already be using. We can be confident now that we're not going to cause any conflicts with the existing setup. For any calls that we make, instead of calling the ga() function like it shows in the documentation, we can just call _gaWFXYZ(). Pretty simple! Note: You may be wondering why we didn't just keep it as ga() and pass in a tracker name. Technically, this works. The reason why I opted not to do this was to first show you the gamut of customization that is available now, and secondly because if that website is using the getAll() method to grab all tracker objects, I don't want them to include mine and send data that I don't want. Another reason in the future is that I don't want to collect any custom clientID value that is stored in the primary GA cookie (just in case it is violating the TOS and contains PII, etc).

Unique Needs?

Do you have any unique Google Analytics tracking needs that you are looking to solve? We help clients with a wide-variety of challenges all the time. Contact our team if you'd like to work with us to solve your unique tracking challenges.

Yellow Pages Group New Zealand Upgrades to Universal Analytics

Joe — Mon, 20 May 2013 23:47:58 +0000

Yellow Pages Group New Zealand Upgrades to Universal Analytics

Using Google Analytics' new Universal Analytics, we are actually able to provide more comprehensive data to Yellow Pages New Zealand than when they were using Adobe SiteCatalyst Analytics. The public beta of Universal Analytics was only recently announced, but we have been using it for months and providing feedback to Google to help shape it into an amazing measurement platform/protocol. We are only at the early stages of what will become of Universal Analytics and how it can be leveraged for offline tracking, tracking across device types (e.g. mobile, tablet, desktop), and much more. In this post, we will share:

Benefits of Universal Analytics
How Universal Analytics is different from the current Google Analytics
What are the current limitations of Universal Analytics
How UA met the demanding business tracking requirements of Yellow Pages NZ
How we leveraged the NEW Custom Dimensions
How we architected a unique implementation with Event Tracking

We will be providing exciting real-world examples of how we are leveraging Universal Analytics for Yellow Pages NZ, but since this is a new product, let's review the benefits of UA (Universal Analytics) to get on the same page.

What are the benefits of Universal Analytics (UA)?

The benefits of Google's Universal Analytics include:

New Measurement Protocol: The new protocol defines precisely how you can get data into GA, regardless of your platform. This means, as an example, that if you are a manufacturer of a refrigerator that is connected to the internet, you could start tracking the number of times that the refrigerator was opened and closed; pushing that data from whatever programming language you wish. Get ready for creative uses that leverage the Universal Analytics platform!
Cross-device Measurement: If you can identify the user (via userID), you'll soon be able to track that person as a unique user instead of a unique visitor which was previously linked to a browser/device. Additionally, you'll be able to see the device pathways that lead to a conversion and how these play into the mix as users hop between devices. At Google I/O 2013, there is a great presentation on this topic and what is coming.
Offline Conversions: The ability to leverage the new measurement protocol to bring in data from non-web data sources allows for the tracking of conversions that occur offline.
Custom Dimensions and Metrics: These replace custom variables. Instead of having just 5 custom variables, you now get 20 dimensions and 20 metrics (Premium clients get 200 of each!). More benefits on these further below in this post.
Faster: The client-side demands have decreased. There is only one cookie (instead of 4-5 previously) and all of the sessionization logic and more is now handled during processing. This means a smaller pixel and a smaller JavaScript library to generate those hits. Another example is that the ecommerce tracking code has been separated from the main analytics.js to reduce its size. The plugin architecture allows you to only include that code when needed (on your ecommerce receipt page).
Flexible Namespacing: This is a feature that has not widely been talked about. You can now control the name of the cookie that UA uses to identify the user (visitor ID). This makes complex multi-tracker situations much easier. Additionally, if they do use the same cookie, you can control other settings at the code-level and in the admin interface about how data is processed.
BigQuery Integration: At Google I/O 2013, the Google Analytics team announced an integration with Google BigQuery that allows access to hit-level clickstream data (similar to our Clickstreamr tool but unlike our tool this solution will require Google Analytics Premium). By having the ability to access the raw data, you can combine this with external data sets and answer more complex business questions.
More to come: As a benefit of the new code architecture and how data is processed, more exciting features are ahead.

How is Universal Analytics Different from the Current Google Analytics?

The classic Google Analytics tracking version (ga.js) varies in quite a few ways. In ga.js, you don't get the following features:

Custom dimensions and metrics
Online/offline data sync
Multi-platform tracking
Simplified configuration controls (via the admin)
New feature releases

Current Universal Analytics Limitations

As of writing this blog post, the Universal Analytics version (analytics.js) does not support:

AdSense integration
Content Experiments
DFA (DoubleClick For Advertisers)
Remarketing

Remarketing is a big missing feature. We are waiting for this to be supported before rolling it out to the majority of our clients. The good news is that according to Google, Remarketing support is coming soon. Likely exciting to your technical team, the Universal Analytics syntax is much easier and standardized. Gone are the days of _gaq.push(['_trackPageview']); and enter the streamlined syntax of ga('send','pageview');

How Universal Analytics Helped Yellow Pages Group® New Zealand

At Blast Analytics & Marketing, we've had access to Universal Analytics for the past seven months under a private beta. During that time, we've been working with many of our clients on migrating them to the new Universal Analytics platform. In this case study, we will be highlighting our Google Analytics Premium client; Yellow Pages Group® New Zealand. As a Blast Premium client, Yellow Pages received measurement strategy, fully customized implementation, and ongoing support from our Google Analytics experts; all included in the cost of Premium. Early on during our discovery process, we found that Yellow Pages had unique and detailed reporting needs. Plus, they were also transitioning from Adobe SiteCatalyst Analytics to Google Analytics Premium. NOTE: We support both analytics tools here at Blast, so we were in the unique position of being able to rapidly understand their current processes and code as well as how to transition to Google Analytics Premium. This isn't the first time we've done this or written about transitioning from Adobe SiteCatalyst to Google Analytics. We've also performed dual-implementations for clients, implementing multiple tools at the same time or in different order -- tool knowledge is one of our unique differentiators.

Meeting Demanding Business Requirements

For Yellow, to meet the business requirements, we have to collect a lot of data that the standard Google Analytics tag just doesn't provide. In the screenshot below, we are looking at a search result page. We searched for 'Restaurants' in 'Auckland, NZ'. In a standard Google Analytics implementation, you'd get the URL of this page. Yellow needs to know more. They need to know who is appearing on the search result page, in what order, and what kind of interactions are taking place. Tracking data at this granularity provides their BI (Business Intelligence) team the ability to perform in-depth analysis about each listing and the performance of that listing.

How we leveraged Custom Dimensions in GA Premium

We leveraged the new Custom Dimensions feature in Universal Analytics and we were able to meet Yellow's reporting requirements. The primary advantage of Custom Dimensions is that they are treated as first-class dimensions. Gone are the days when your custom report said 'Custom Variable Key (02)' and upon report delivery your management looks confused as to what they are looking at. Now, whatever you name the custom dimension, this is what shows up as the dimension name within the report. It is a very simple change but so helpful! By leveraging Custom Dimensions we are also no longer constrained by the 128 character key-value pair limit of Custom Variables. For Yellow, we often have data strings that are 900 characters and are parsed by the BI tool. Yet another advantage of Custom Dimensions is that we can now filter on them via profile filters. This wasn't possible with custom variables. Like custom variables, you still have the ability to send the dimension values at different scope levels (now they are called hit, session, and user levels).

Custom Reports for Custom Dimensions Reporting

When you use Custom Dimensions in Google Analytics, you have to be aware that there are no built-in reports that will show you this data. Instead, you must create custom reports. Here's an example of the custom report setup that we used to show the category names that are often searched: Pretty simple right? We end up with a report that looks like the following (data is obfuscated): We can then break this down by other 'secondary' dimensions such as search term or what type of search result page (a map result page, etc). We are no longer confined by the built-in capabilities of the Internal Site Search reports and its limit of a single category.

How we leveraged event tracking in GA Premium

Yellow had another unique report request. In their previous implementation of Adobe SiteCatalyst, they were able to report on the number of unique times that a visit (session) interacted with an individual listing. You can interact with a listing by clicking to show their phone number, clicking their website, and more. There are a lot of interactions that can take place that qualify for this engagement. In SiteCatalyst, this is accomplished via event serialization where you must give each event a unique and distinct value. This is most often done by specifying a session ID on top of another unique identifier (listing ID in this case). In many cases within Google Analytics, goal tracking is the obvious solution to provide for this reporting need. You can only convert once per goal per session, so it ends up being unique to the session. Unfortunately, if a visitor interacted with four different listings, the goal conversion would only report a total interaction count of one. This doesn't meet our objective and we obviously can't create thousands and thousands of goals! We decided to architect a unique system by leveraging event tracking. Events can be captured with 3 levels of hierarchy: event category, event action, and event label. Don't worry about the description of each, we just care that it is 3 levels deep. Typically, in reporting, you'll drill into the category and view the action and then you can click into the action to view the label; it is a nested hierarchy. When a visit interacts with a listing, we capture the data in the following structure:

Event Category: Listing Interaction
Event Action: {Unique ID of listing}
Event Label: {Interaction Type}

Pause for a minute and make sure you have this structure in your head before you read on... The end result is that we can look at the number of 'unique events' at the category level (Listing Interaction) to determine the number of unique sessions that interacted with ANY listing. Further, and more importantly to meet the reporting objectives, we can click into the 'Listing Interaction' category and query a specific listing ID to get the number of unique events fired for ONLY that listing ID. If we need more granular data about the type of interaction, we can click into the listing ID and get that data. The 'unique events' metric in Google Analytics is always relative to the hierarchy level you are at (it is de-duplicated/serialized). Mission accomplished!

Conclusion

The examples above are just a few of the ways that we've customized Yellow Page's Google Analytics Premium implementation to meet their business objectives. We hope that these examples shed some light on the new possibilities with Universal Analytics. As the features in Universal Analytics continue to expand, we'll be writing several other blog posts that dive into how we are leveraging them for our clients. Let us know in the comments if you have any questions about Google's new Universal Analytics. And if you enjoyed this post, please +1 and share it!

Using Multiple Trackers in Google Analytics

Olaf — Thu, 18 Apr 2013 06:42:18 +0000

Using Multiple Trackers in Google Analytics

Why would you want to use multiple trackers?

In case you didn't know, there are ways to put tracking code on pages that will track to two or more Google Analytics accounts or web properties. It can get kind of tricky but once you understand the concept, it's a breeze. Let's start with having a reason to put multiple trackers on your site's pages. I'll give you two:

Tracking for affiliates - Suppose you have an e-commerce site and the vendor you use for transactions requires tracking transaction information to their own Google Analytics account.
Your company has multiple sites - Perhaps your company has several locations, each with its own domain, and you want both an individual look at each domain and an aggregate look for all domains combined. This is referred to as a "roll-up tracker." A roll-up tracker could be Profile based, Property based or even Account based. Each domain would then track on its own plus to the roll-up.

What if you have multiple sites AND also track for affiliates, would you need to have 3 trackers on some pages? YES Is it possible to track to more than two Google accounts or web properties? the good news is YES!

Do I need a Profile, Property or Account Rollup?

Account Roll-up: In the case of an affiliate, the need for a separate tracker is more like a requirement. The affiliate company will be tracking to their account and your site tracks to your own account. Property Roll-up: A Property roll-up as opposed to an Account based roll-up offers the advantage that since all Properties within an Account share users, filters and data sources, it's much easier to configure these items and assign them to the appropriate Properties without the need to create them multiple times. Having each site on its own Property allows you to easily report only on that specific site without the need for filtering out traffic outside of the specified domain or sub-domain. This comes really handy when you have a large collection of sites. Imagine having to create Include and Exclude filters for 24 sites? However, this advantage presents the disadvantage of not being able to report aggregate data. That's where a roll-up account comes in. Implementing multi-tracking code on the sites to track to separate Properties, will let you see aggregated traffic on your roll-up Property while maintaining the singularity of your site's own Property. Add a filter to show the full domain on your roll-up Property and now you're able to see traffic to all sites within your content reports. Add cross domain tracking to your roll-up account and you're able to see the flow of visitors across the sites. Profile Roll-up: Profile roll-ups don't require multi-tracking code, simply because profiles share their parent Property ID so the code would be the same on all sites. If you have 2 or 3 domains, setting up a Profile roll-up may be the best solution since you don't have to change your code and handling filters is not that complicated. Creating multiple profiles is a lot easier than creating multiple Properties since copying a profile also copies assigned filters, goals and settings while there's no option to copy a Property. Your roll-up Profile would still need to have a filter to show the full domain.

Now that we know what we want, how do we do it?

Although it can get a little tricky when you start thinking about cookie sharing and such, the key to the solution is namespacing your trackers. This presents a little more work for your development team and unfortunately introduces room for error.

Multiple Trackers, The Standard Method

Google provides some brief guidelines into how the code needs to be structured in the "One Push, Multiple Commands" section of their development guidelines - however, they don't really tell you much so here's a good example: [sourcecode language="js"] _gaq.push( ['_setAccount', 'UA-XXXXX-1'], ['_trackPageview'], ['rollup._setAccount', 'UA-XXXXX-2'], ['rollup._trackPageview'] ['affiliate._setAccount', 'UA-YYYYYY-1'], ['affiliate._trackPageview'] ); [/sourcecode] The formula is simple, add a prefix to the Google Analytics command for your additional trackers and duplicate your code for every tracker you need. If you put two and two together, you see how this can be tedious work. You would need to duplicate every _gaq.push you have throughout your site. All Events, Pageviews, Custom Variables, and any other standard tracking commands but worst of them all, your e-commerce code complete with every _addItem command listed. That's where it really gets heavy.

Multiple Trackers, The Blast Method

We believe in simplicity and automation. Eliminating development time and lowering the potential for errors is what drove us to develop this multi-tracker script. The benefits of the script include:

Easy to configure web property numbers and tracker names
Automated setAccount for all trackers
Ease of use by maintaining current method structure
Option to specify tracking on only specific trackers
Ability to modify how data is sent to Google

The Script

To start, we're going to set some array variables at the beginning of your code: [sourcecode language="js"] var GA_Account_IDs = ['UA-XXXXXX-1','UA-XXXXXX-2','UA-YYYYYY-1']; var GA_Tracker_Names = ['main','rollup','affiliate']; var GA_Trackers = []; [/sourcecode] You'll want to enter the actual web property numbers for GA_Account_IDs. For the tracker names, we've set a pretty accurate default set of names. Feel free to change them as you please. The values can be either hard coded or populated servers side. In the example of an affiliate solution, you may be interested in capturing e-commerce transaction pages but not necessarily every page of your site. A server-side script could determine whether or not to populate the affiliate information. Make sure that you always match the position of the UA# with the position of the Name. For example, if you didn't want to track to the roll-up on a specific page, you would enter the first and third UA#s along with "main" and "affiliate" names in the same order. The following configuration is the star of the show: [sourcecode language="js"] var GA_Track = function() { // check to see if list of trackers is set, otherwise set to blank var trackers = (typeof(GA_Tracker_Names) === 'undefined') ? ['']: GA_Tracker_Names; // grab function arguments and put into array args var args=[].slice.call(arguments), c = [], p = [], d; // check for 'bam' for specifying tracker names if(args[0][0]==='bam'){ // if 'bam' is the first item of the first argument, grab the supplied tracker names and put into array trks c.trks=(trackers.length>1) ? args[0].splice(1): trackers; // drop first argument and put the rest into args c.args=args.splice(1); } else { // if no 'bam' is present, use trackers and args as supplied c.trks=trackers; c.args=args; } for (d=0; d p[d] = []; for (var a=0; a p[d][a] = []; for ( var i=0; i p[d][a][i] = []; // if not main tracker and if first argument, insert tracker name, otherwise if main tracker leave blank, if not first argument, skip var r = ( i != 0 ) ? '_': ( c.trks[d] == trackers[0] ) ? '': c.trks[d]+'.'; p[d][a][i] = (r!='_') ? r+c.args[a][i] : c.args[a][i]; } // console.log( p[d][a] ); // debug: _gaq.push( p[d][a] ); // push to _gaq object for GA only } } }; // initiates the GA accounts and populates the Trackers for ( var id=0; id < GA_Account_IDs.length; id++ ) { GA_Trackers.push(GA_Tracker_Names[id]); GA_Track(['bam',GA_Trackers[id]],['_setAccount', GA_Account_IDs[id]]); } [/sourcecode] More on the script will follow, but we have one more step before the task is done.

Code Replacements

As Google officially starts introducing Universal Analytics, moving forward we need to take steps to minimize the amount of work for future migrations. Since Universal Analytics uses a different syntax than Google Analytics, a migration to Universal Analytics would require you to change all existing tracking code and adjust it to the new syntax. However, Universal Analytics is a developing technology and not all existing features of Google Analytics (GA) are fully supported. So the best solution is to implement tracking code via a function that will collect the necessary data throughout the site and then reformat the way the data is sent to Google within that function. The basis of the script is to replace the _gaq.push method with the GA_Track function on the initial Google Analytics code implementation. Right at the very end of the GA_track function, you determine how data is formatted and sent to Google. A sweet bonus is that you can enable the debug console.log and you'll see exactly what is getting sent to Google. On existing implementations, we will take the first step towards a smooth Universal Analytics migration now by changing all the push methods on the site as follows: Example code case: [sourcecode language="js"] _gaq.push(['_setCustomVar',1,'Customer Type','member',1],['_trackPageview']); _gaq.push(['_addTrans', '1234', // transaction ID - required 'Womens Apparel', // affiliation or store name '28.28', // total - required '1.29', // tax '15.00', // shipping 'San Jose', // city 'California', // state or province 'USA' // country ]); _gaq.push(['_addItem', '1234', // transaction ID - necessary to associate item with transaction 'DD44', // SKU/code - required 'T-Shirt', // product name 'Olive Medium', // category or variation '11.99', // unit price - required '1' // quantity - required ]); _gaq.push(['_trackTrans']); _gaq.push(['_trackEvent','page-interaction','cart confirmation','print page', 0, true]); [/sourcecode] With the standard method, you would need to duplicate the code above for each of the trackers. On a site with a roll-up tracker and an affiliate tracker, the code would need to be placed 3 times as shown on the previous example. Instead, all you need to do is replace _gaq.push with GA_Track as shown below: (you'll thank us later!) [sourcecode language="js"] GA_Track(['_setCustomVar',1,'Customer Type','member',1],['_trackPageview']); GA_Track(['_addTrans', '1234', // transaction ID - required 'Womens Apparel', // affiliation or store name '28.28', // total - required '1.29', // tax '15.00', // shipping 'San Jose', // city 'California', // state or province 'USA' // country ]); GA_Track(['_addItem', '1234', // transaction ID - necessary to associate item with transaction 'DD44', // SKU/code - required 'T-Shirt', // product name 'Olive Medium', // category or variation '11.99', // unit price - required '1' // quantity - required ]); GA_Track(['_trackTrans']); GA_Track(['_trackEvent','page-interaction','cart confirmation','print page', 0, true]); [/sourcecode]

Choosing Your Trackers

Using the example of tracking for an affiliate, you would only be interested in tracking transactional pages. The account tracker does not need to be present on all pages of your site. This would be easily handled by simply omitting the tracker UA# and "affiliate" name. However, on the completion page, you want to track if the user prints the page and the affiliate does not care about this data. You would then make a function to listen for the "print" option, or a click on the "print" button and then fire off an event tracker. However, since there have been 3 items already defined on the page; doing a simple GA_Track() call would go to all three. To send only to the "main" and "rollup" trackers, you'll need add an initial array whose first item is "bam" and is followed by the names of the desired trackers. Be sure your names here match exactly how they were initialized. [sourcecode language="js"] GA_Track(["bam","main","rollup"],['_trackEvent','page-interaction','cart confirmation','print page', 0, true]); [/sourcecode] So what if we only have 1 tracker? No problem, just enter 1 UA# and 1 tracker name. The functionality remains exactly the same. The difference being that you can go from 1 tracker to 3 trackers by simply adding the additional numbers/names. You can also go from standard GA to Universal or both, from one location.

Limits

So exactly how many trackers can you send to simultaneously? Well, that all depends. It's hard to imagine a scenario needing more than 4 trackers per site. We would love to hear from anyone who has needed to do so! Limits are set by how many hits can be done in a burst. For regular Google Analytics, this is set to 10 and then it replenishes at a rate of 1 per second. In Universal Analytics, this limit is 20, replenishing at 2 per second. Anything above that will be ignored. Read more about that on Google's Developers pages. Keep in mind, these limits are set for hits, regardless of what type of hits they are. If you initialize your page with 3 trackers, you'll start off with 3 pageviews. If you fire off an Event immediately after, you'll have 6 hits. A burst is any number of hits sent within a second. If you have to send several hits to several trackers, you may need to add some delays.

Use this Free Script

Feel free to use our script on your next project. If you have any questions about implementation, simply post them as comments below. Be sure to share, like and +1 if you enjoyed this post.

How to Enable Real-time Reporting in Adobe SiteCatalyst

Joe — Wed, 03 Apr 2013 21:41:09 +0000

How to Enable Real-time Reporting in Adobe SiteCatalyst

Did you know that Adobe Analytics, SiteCatalyst v15, has a feature that allows you to see near real-time data? If the answer is no, you are not alone. The majority of clients that we work with do not have it enabled. Adobe released the Current Data Reports feature for version 15 back in October 2012, so it is a somewhat recent feature. Unfortunately, and we're not sure exactly why, Current Data reports are not enabled by default. If you didn't see the Adobe Current Data blog post, then chances are you had no idea about this new feature.

What do I get with 'Current Data' reports?

This low latency real-time reporting functionality mirrors the v14 release of SiteCatalyst and provides you with what was taken away (as a result of new data processing algorithms). The page view and instances on the traffic variables (sProps) are available within about a minute (or two). The conversion metrics and instances (eVars and success events) are available after about a 20 minute time lag. With the standard reports, there is a processing delay of approximately 60-90 minutes. This is just the first step that Adobe is taking to give you better real-time/current data in the SiteCatalyst platform. Look for more releases around this topic in 2013. With more current (low latency) data, you have the ability to:

Make faster data-driven decisions during critical times (holidays anyone?)
Quicker access to data for debugging purposes

At Blast, we often use this feature during audits and implementations for double-confirmation that the data is showing up correctly. You should enable and start using this feature if you are looking at data for the current day in Adobe Analytics, SiteCatalyst v15.

What are the limitations?

This may change with future releases perhaps, but currently you cannot apply segments or breakdown data with these 'Current Data' reports. There are also a few v15-only metrics like total time spent that are not available in these reports.

How do I activate Current Data?

To enable this feature for your users, you have to be an administrator. Simply go to Admin > User Management > Groups and you'll see a pre-defined group named 'Current Data Users'. Edit this group and assign your users (likely all of them) to this group. After you've edited the group, users may need to logout and back in and then they'll have access to this data. If you have questions about setting up Adobe Current Data reports, please submit your question below in the comments. If you need more comprehensive Adobe Analytics consulting support with strategy, implementation, analysis, marketing channel optimization, or training don't hesitate to contact us at 1 (888) 252-7866.

Google Analytics Remarketing Boosts Conversion!

Kayden — Tue, 02 Apr 2013 00:22:23 +0000

Google Analytics Remarketing Boosts Conversion!

What is Google Remarketing?

Google Remarketing is a cost effective way to broaden your reach, bring potential customers back to your site, lower your CPC and increase conversions 300-400%! The way this works is you can access the Google Analytics data you have for these customers from their previous visits, like goal completions and pages viewed, to show them targeted ads on the Google Display Network (via Google Adwords) for the products or services you know they have already shown an interest in. Here are some of the highly targeted Adwords campaigns you can create:

Bring back shoppers who placed items in their cart but did not buy - select visitors who shopped specific categories before abandoning their carts
Help close the deal for tentative comparison shoppers - setup your custom list using visitor segments, check how many visitors are on your list, and then activate a campaign on the GDN to show ads highlighting top reviews for the products they viewed/compared
Retain customers who have made a purchase in the past - target customers who have spent more than $500 in the last 30 days and offer them a free gift with purchase
Win new customers in your target market - narrow your list to include Northern California visitors who have watched one of your latest videos

Why Remarketing?

300-400% Conversion Rate Boost (compared to standard ads based on Google 2012 data)
Lower CPA and Higher CTR
Expand your reach and influence users to return to your website (re-engage lost customers)
Connect with exactly the right customers using rich online insights
Deliver targeted GDN ads based on your specific customer segments
Reach more than two million websites on the GDN
Google Analytics tracking code now has built-in compatibility for remarketing. This means that websites using Google Analytics will now only require one tracking code, rather than two.

How does Remarketing work?

Remarketing helps you turn unconverted visitors into new business opportunities. After a visitor visits your site and leaves, they have been added to your bucket of potential users that can be added to a targeted list. When they are visiting other sites, you can show them display ads based on the targeting that you set, which increases the likelihood that they will return to your site and perform a goal conversion. To employ remarketing, you either select from predefined remarketing lists in Adwords or create your own customized lists in Google Analytics. Then you choose from your custom remarketing lists within Adwords and create your targeted campaigns. We will show you how to do this in detail further down in this post.

Drawbacks of Remarketing Tag

Problem: A percentage of your traffic will have tools like the AdBlock browser extension installed that will block loading of the js file from DoubleClick's domain. This prevents you from tracking these users and could adversely impact the quality of your analytics data. This ad/tracking code blocking will typically affect up to 10% or even as much as 70% of your traffic depending on your audience. Solution: We added tracking code detection for many small to enterprise level clients that attempts to load the dc.js, and then 1 second after the page finishes loading, we will fall back to ga.js, if dc.js has not loaded. To learn more about this fallback solution that will maintain the integrity of your Google Analytics data, check out our blog post Prevent Loss of Data with Google Analytics Remarketing Tag.

Six Remarketing Requirements

Before we show you how to setup remarketing lists, there are some important requirements that you need to be aware of prior to deploying Google Remarketing. We have included the requirements below in the order we recommend.

Agree to the Google Analytics Terms of Service (no specific action required except abiding by the stated policies)
Agree to the Google Analytics for Google Advertiser's for Display Advertising policy (no specific action required except updating your privacy policy and abiding by the stated policies)
Get Google Analytics Admin Access (only admins see the "remarketing lists" tab in the GA management UI)
Link your Adwords account (you need to link at least one account) to your Google Analytics account
Update your privacy policy
Update your Google Analytics tracking code

Privacy Policy Remarketing Updates

While we recommend you read the Google Analytics Display Advertising and Remarketing Policies in full; we have attempted to save you time by distilling the updates you need to make to your privacy policy into a simple list.

Disclose that you use Remarketing with Google Analytics to advertise online, and specify the features of Google Analytics for Display Advertisers that you use.
Provide information to your visitors how they can opt out of Google Analytics for Display Advertisers and opt out of customized Google Display Network ads by visiting the Ads Preferences Manager.
It is encouraged that you point your visitors to the Google Analytics Opt-out Browser Add-on.
Follow the Google AdWords Remarketing Policy and its sensitive category restrictions.
Disclose that third-party vendors, including Google, show your ads on sites across the Internet.
Disclose that you and third-party vendors, including Google, use first-party cookies (such as the Google Analytics cookie) and third-party cookies (such as the DoubleClick cookie) together to inform, optimize, and serve ads based on someone's past visits to your website.

Tracking Code Changes

In order to start collecting the appropriate data, you will need to make a minor adjustment to your current Analytics tracking code. Find this code ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘google-analytics.com/ga.js’; Replace with this code ga.src = (‘https:’ == document.location.protocol ? ‘https://’ : ‘http://’) + ‘stats.g.doubleclick.net/dc.js’; This code change is compatible with the synchronous and asynchronous versions. As mentioned above, we highly recommend using our fallback remarketing code detection tracking code solution to avoid any data loss.

Where do I create Remarketing Lists?

Now, let's dive in! After you select your account/profile, go to the admin where you will choose the "Remarketing Lists" tab on the management screen. Click "+ New Remarketing List" Here you will select from one of the four Remarketing types available:

All of my site visitors
Visitors who visited a specific page/section of my site
All visitors who completed a specific conversion goal
Create my own remarketing type using Visitor Segments

Keep in mind that your imagination is the limit for your remarketing lists. You can target users by:

Content viewed
Specific actions taken or not taken
Sequential behavior taken in one session or across multiple sessions
Traffic Sources
Engagement (number of pages viewed or time on the site)
Goals (any, one or multiple)
Visitor characteristics / dimensions

Remarketing List Setup

If you have already completed the Remarketing requirements such as updating your tracking code and your privacy policy, you are ready to continue and create your remarketing lists. However, you can always start playing around with creating your lists before you complete the requirements. You just can't launch your Adwords campaigns until all the requirements are completed. Let's get started with the first remarketing type example...and then we will show you the setup of the other three types.

Example #1: Lists that target all your visitors

This is the most obvious list type and only requires you to customize the list name. Keep in mind that you generally don't want to use "All of my site visitors" since you are missing out on the ability to do more precise targeting which is where the value of Google remarketing comes in. However, if you don't have a lot of website traffic you may be limited to this type since you need to have more than 100 visitors in your list and when you choose a specific page or action it may be less than 100. Don't worry, we will show you how to estimate the size of your list later in this post so you can be sure your lists are usable in Adwords.

Example #2: Lists that target specific page visits

Instead, if you want to target a specific page visit, then you just click the second radio button and enter your page name as shown below. I entered our analytics consulting page "/analytics-consulting.aspx" and gave it the descriptive name of "Analytics Consulting Visitor List." You always want to use a descriptive list name so when you have lots of lists to choose from in Adwords, your list targeting is easy to identify and remember.

Example #3: Lists that target visitors who took a certain action

Now if you want to target visitors who completed a conversion goal, then you just click the third radio button and choose the goal from the drop-down list. In this example, I chose 'Newsletter Sign Up' and gave the list a descriptive name of "Newsletter Subscriber Visitor List." Keep in mind that you need to have goals setup in your profile for goals to be accessible in this drop-down.

Example #4: Lists that target visitors based on visitor segments

Finally, my favorite remarketing list type! This custom remarketing list type is based on visitor segments and offers the most power. The great news is that these visitor segments are reported across sessions. The setup of visitor segment remarketing lists requires several steps shown below. First, click the fourth radio button as shown below and then click "+ Add new filter." Next, click "Sequence Filter" on the top right Then setup your Filter by selecting a goal start for your 'include' and choose 'Greater than' zero. Then click "Add 'and' statement." Use a goal completion (this does require that you already have goals setup in your Google Analytics) and set it to 'exclude' with a 'Greater than' zero setting. Then hit 'Save' and you will see this confirmation screen.

Estimating Remarketing List Sizes

Now you can tweak the list membership duration from the default 30 days to the maximum of 180 days or the minimum of 1 day. You can keep changing the days value and clicking "Get Estimate" to calculate your list size and ensure you have over 100 unique visitors in your list, which is the minimum to use it in Google Adwords. Select the Adwords account that will have access to your newly created Remarketing list. Keep in mind that once you save your remarketing list you cannot change the Adwords account that is associated with the list. Finally, you can see your new Remarketing List under the "Remarketing Lists" tab in the Google Analytics management interface.

Accessing your Remarketing Lists from AdWords

Create a New Display Campaign

Click "+ New Campaign" for "Display Network Only" as shown below.

Name your campaign

Create a descriptive campaign name. We recommend adding "- remarketing" on the end of your campaign name so it is easy to identify your remarketing based campaigns. Choose the radio button for "Remarketing"

Choose your Remarketing List

Click the radio button for "Interests & Remarketing" and select the "Remarketing Lists" tab. Then, you will be able to choose your Google Analytics Remarketing List to target in the ad group creation screen. Click “>>” to add the list to your Selected audiences:

How to exclude people from a list

If you want to remove people from a list, you need to exclude them using "custom combination" lists in Adwords. Access the "Custom Combinations" tab (shown in the screenshot above) and follow these instructions;

Create two Remarketing lists in Analytics (List A - "People who have purchased at least $50" and List A - "People who have purchased more than $500)
Create a "Custom Combination" in Adwords. Under "Users included or interested in" select "any of these audiences (OR)" from List A, and select "none of these audiences" from List B)

Create your ad(s)

Use the Adwords 'Display ad builder' under the Ad tab (shown below), or upload an image, text or video ad that you or a creative resource has created for you. After you create or upload your ad, you can see the performance data for your new remarketing campaign under 'Display Network > Interests & Remarketing' (as shown below). Now, you have the full scoop on how to setup Google Remarketing! You should be able to setup your targeted display ad campaigns within 30 minutes and start driving leads and/or sales at a lower CPC. Any questions, let us know below! Please share, like and +1 if you enjoyed this post. Still hungry for more info? Check out these additional Google Analytics Remarketing resources:

Prevent Data Loss when using Google Analytics Remarketing Tag

Olaf — Mon, 01 Apr 2013 23:05:03 +0000

Prevent Data Loss when using Google Analytics Remarketing Tag

Did you know that you could lose up to 70% of your analytics data by implementing the Google Analytics Remarketing Tag? To implement the Google Analytics Remarketing Tag, the standard Google Analytics tracking code is replaced by a JavaScript file served from the DoubleClick domain. The DoubleClick tracking code (dc.js) uses a third-party cookie to track user activity across websites and the entire domain is blocked by most ad blocking and privacy protection software. When blocked the dc.js tracking code won't load and no data from that session is sent to Google Analytics. Depending on the composition of your audience, anywhere from 5% to a whopping 70% of your website visitors block the DoubleClick tracking code and won't be tracked. Consider these figures:

Ad blocking impacts around 10% of traffic for most websites
In Austria, Hungary, and Germany ad blocking is over 19%
Multiple sources have reported up to 50% ad blocking
In an extreme case, a Google Analytics Certified Partner in Europe reported dc.js tag blocking as high as 70%

With the increasing popularity of the AdBlock browser extension (example shown below) and the announcement that the Firefox browser will block third-party cookies by default (something Apple's Safari already allows), it is expected that Ad Blocking and Privacy software usage will double within the next 18 months. Be aware that these ad blocking numbers are based on our real world experience with clients of various size/type, reports from Google Analytics Certified Partners like us (in the USA, Europe, South America and Japan), and research from third-parties such as ClarityRay (view report of ad blocking with country specific breakdowns). Losing 10% or more of your analytics data dramatically alters the trustworthiness of your data and will likely cause you to make bad business decisions. The benefits of remarketing don't outweigh the risk of compromising your data confidence.

Solution - If Blocked, Fallback to Standard Tracking Code

The good news is that we have a solution for you that has been successfully implemented on our clients' websites; including some of the highest traffic sites on the Internet. The code provided below will allow you to detect whether the DoubleClick remarketing tracking code script was loaded, and if not, load the standard ga.js tracking code. This will prevent you from any substantial loss of analytics data (due to the blocking or failure to load the dc.js script ) and allow you to reap the benefits of Google Analytics Remarketing without substantial data risk. [sourcecode language="js"] [/sourcecode] Although AdBlock and AdBlock Plus have been the two most notable ad blocking extensions causing this problem, it is important to know that their latest releases no longer block doubleclick.net and the dc.js script will successfully load by default. However, other ad blockers are out there that will cause the same effect, and you never know when a new software program, browser extension or browser upgrade will start blocking tracking pixels/cookies. This type of ad blocking and privacy protection is only expected to increase over time. Therefore, it is definitely still worth implementing this fallback solution to safeguard your analytics data. Note: If you are a client of ours and are using the Google Remarketing feature, we'll use this fallback technique to eliminate potential tracking issues. If you are not our client, simply have your technical team leverage what we've provided.

Invitation to Collaborate with Us

We invite you to add this script to your site and collaborate with us in establishing some statistics for this problem by sharing or sending us your resulting "failed" counts. If you have any questions or comments about this Google Analytics Remarketing Tag Fallback solution, please don't hesitate to post them below.

How to Track Downloads & Outbound Links in Google Analytics

Ryan — Fri, 22 Mar 2013 22:11:29 +0000

How to Track Downloads & Outbound Links in Google Analytics

It has been almost 2 years since we published our wildly popular post, How to Track Downloads in Google Analytics. Since Google Analytics does not track file downloads, email, telephone or other outbound link clicks automatically, we saw an opportunity to provide this code to the community. In our original post, we provided some explanations and code examples for tracking file downloads in Google Analytics using event tracking. We decided to revisit our original post and provide a valuable code update that improves performance, makes tracking downloads more manageable and easier to extend.

Dynamically Track Downloads & Other External Links

For those who have a lot of links and would like to dynamically detect clicks on links to file downloads, we have provided updated code below. As before, this code requires the jQuery JavaScript library to be set before the code. We have updated the code to make it more manageable and easier to extend. In addition, we are using the jQuery on() method for attaching the click event handler to links. Since we are using the on() method you will need to use jQuery v1.7+. If you are using an earlier version of jQuery the .live() method can be used instead. The primary benefit of using the on() method is performance. Instead of looping through all 'a' elements on a page after the page loads (takes processing power on pages with lots of links), we instead listen for any clicks on the 'a' elements and invoke our custom JavaScript on the fly. Again, feel free to customize this code to suite your needs. It can be placed in its own .js file and should be placed in the of your pages. This script automates the following:

Tracks file downloads as events for the following extensions: .zip, .exe, dmg, .pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mp3, .txt, rar, wma, mov, avi, wmv, flv, wav (again feel free to modify the list)
Tracks outbound clicks as events if the href value contains http:// or https:// and the domain value doesn’t match the current domain
Tracks mailto email clicks
Tracks Tel telephone clicks

[sourcecode language="js"] [/sourcecode] The script sets download, email and tel link clicks as interaction events while the external site clicks are non-interaction which can be adjusted if desired. As before, the script will detect if the link is opening in a new window or not and automatically uses setTimeout() for 400ms if you are not. This is to allow time for the hit request to process before taking the user to the new page.

Inline Download & Other External Links Tracking

If you'd rather not use the above method to place a single javascript file on your site and automate the tracking for all link elements, you can use the manual inline approach by tagging each link element individually. The inline approach can be time consuming and is not scalable. The original syntax for adding the code inline remains the same. New window/tab For links that open a new window or tab (such as using target="_blank" for example) you will want to use the code below: [sourcecode language="html"]Download my file[/sourcecode] In current window For links that open within the same window, replacing the current page, you will want to use the code below: [sourcecode language="html"]Download my file[/sourcecode] These type of links require a slight delay to allow time for the hit request to process before taking the user to the new page.

Detailed Download & External Link Reports

After all of your hard work you will have event tracking reports with neatly organized data around file downloads, external link, email link, and telephone link clicks. From these reports you can gauge the usage and usefulness of your file downloads and various links. By diving into the download category and selecting event label as the primary dimension you are able to see a report on all of the individual files downloaded from your site. Lastly, since events are associated with the page they were fired on, you are able to apply a secondary dimension of page to find out which page contained the download or external link click that occurred. If you need assistance with outbound link analysis, setup of this tracking code or any other analytics help, don't hesitate to comment below or contact our Google Analytics Consulting Experts.

Google+ Local Is Now Friendlier to Healthcare

Trulie — Tue, 19 Mar 2013 02:16:38 +0000

Google+ Local Is Now Friendlier to Healthcare

We caused a stir and Google responded with two positive changes to their Google+ Local Quality Guidelines that will help people get more accurate contact information for their healthcare providers.

Background

Five months ago, we blogged about the issues we've found with Google+ Local not being friendly to health care. The trend in the Health Care Industry is to have multiple departments and separate centers housed in one facility. These centers are run and managed independently of one another. The Google+ Quality Guidelines at the time allowed for only one listing for each facility. But, with no centralized reception area or phone number, this was often an impossible mandate. [caption id="attachment_3584" align="alignright" width="190"] The Banner Estrella Medical Center in Phoenix offers multiple departments that are run independently on their 50-acre medical campus. Under the old guidelines, only one listing was allowed for the entire location. Ridiculous![/caption] Health Care organizations were being forced to decide between making changes to their real-life business models to fit the Google standard, or risk giving their members and potential members incorrect location information. Each health care organization we worked with had the same concern and each insisted that it had to change. So, we took it to Google. We blogged, tweeted, reached out to other Local Search experts, and used the Google for Business forum to get our message out. We caused a stir, as we wanted to expedite this needed change. Specifically, we reached out to influential local search blogger Mike Blumenthal and asked him to join the cause. He was happy to give us his support since he had also been running into the same issues.

Google+ Changes Local Guidelines

Recently, Mike reported that Google+ has now updated their Google+ Local Guidelines to address the issues we were facing. The guidelines now allow for multiple departments to be listed at one facility: "Departments within businesses, universities, hospitals, and government buildings may be listed separately. These departments must be publicly distinct as entities or groups within their parent organization, and ideally will have separate phone numbers and/or customer entrances." This is the policy change that was needed! Now, Google will reflect actual brick-and-morter locations instead of insisting that they change their business model to Google's predetermined format. We've already begun to list the departments at the health care facilities that we help manage so that searchers can get the best information possible.

Another Positive Change to the Guidelines

In addition to this change that we've been calling for, the updated Quality Guidelines also allow for another positive change that directly affects the Health Care Industry. The new guidelines state: "Individual practitioners may be listed individually as long as those practitioners are public-facing within their parent organization. Common examples of such practitioners are doctors, dentists, lawyers, and real estate agents. The practitioner should be directly contactable at the verified location during stated hours. A practitioner should not have multiple listings to cover all of his or her specializations." [caption id="attachment_3587" align="alignleft" width="232"] Physicians can now have multiple listings for each practice location[/caption] It is encouraging to see Google proactively address the need for an additional Google+ Local guidelines change. In today's world, many physicians practice out of multiple facilities within their organization. This change allows for these physicians to have separate listings for each location as long as their hours are listed correctly. This eliminates the need to choose a "primary" location for physicians. These changes are bringing Google+ Local one step closer to being a reliable, accurate source of information for searchers.

Google Adwords Enhanced Campaigns Shake Things Up

Brian — Thu, 07 Mar 2013 22:57:56 +0000

Google Adwords Enhanced Campaigns Shake Things Up

Google recently announced Enhanced Campaigns, which is the biggest change to come to Adwords in a long time. The news has been accompanied by concern and uncertainty for both advertisers and agencies alike. To help demystify the new updates, we have outlined the most important enhancements and provided guidance on the actions you need to take.

What is it and Why?

Google Adwords Enhanced Campaigns is the latest attempt for Google to capitalize on the increasing shift toward mobile use. Google’s declining search revenue is due mostly in part of mobile’s increasing share of search impressions and their inability to monetize devices beyond desktops/laptops (see Google’s stats below). Campaign structure will be altered to enable targeting across laptops/desktops, tablets and smart phones within a single campaign. Since Google and advertisers alike are aware of the differences in ROI between devices, Google will provide bid multipliers to adjust bids across:

devices,
locations,
and time of day.

Interesting Mobile Usage Stats:

By 2013, more people will use their mobile phones than PCs to get online *
There will be 1 mobile device for every person on Earth by 2015 **
Combined global mobile and tablet search traffic is up nearly 2X, year over year ***
Mobile searches have grown 400% since 2010 ****
95% of smartphone users have searched for local information ***
61% of users call a business after searching and 59% visit the location ***
70% of mobile users have compared product prices on their phones ***
50% of mobile searches led to a purchase ***
40% of email is accessed via mobile (if you aren't optimizing your emails and website for mobile you are in trouble) ***

Sources: * Gartner, 2010 ** Cisco, 2011 *** Google Internal Data, 2012 **** DoubleClick, 2012

Benefits Summary

Google is enabling more powerful bidding improvements to manage your bids seamlessly across locations, times and devices. In addition, ads will be optimized by varying user contexts. This includes showing either a mobile or desktop ad, sitelink, app or other extension based on the user context and device. Lastly, reporting will now include new conversion types such as app downloads and access to detailed call reports (manually dialed calls will no longer be billed).

What has changed?

Targeting: Mobile Phone, Tablet and Desktop targeting can no longer be separate
Reporting: Advanced reporting for phone calls, sitelinks, app downloads
Bidding: Location-based bidding
Extensions: Can be set at at the ad group level, Mobile vs. Desktop, Scheduling options, shorter sitelinks
Phone Calls: Calls are now free from Desktop and Tablet devices
Scheduling: List-based control; Day and Time > Campaigns > Bid Adjustment
Ads: Mobile and Desktop ads reside in the same campaign

Enhancement Details

Targeting

The biggest change that will affect most advertisers is the need to merge existing Desktop and Mobile campaigns since the device targeting will automatically default to 'All Devices' this summer. As you can see in Figure 1A, Google provides you with Mobile device Bid Adjustments, -10% in this example. This change limits your ability to target by device, but at the same time has eliminated the need to duplicate desktop campaigns for mobile device campaigns. Figure 1A: Based on the size of your campaigns, Google has provided several flows that can assist you with the upgrade process.

Reporting

One of our favorite changes include the level of reporting. Google will provide the ability to measure manually dialed phone calls and app downloads as conversions. This changes the landscape for advertisers who track both online conversions and phone calls but had to create custom reports to have both conversion types combined for more accurate views of their efficiency.

Bidding

Advertisers will need to adapt to the differences in performance across devices using bid adjustments at the campaign level. As you can see in Figure 1A, Google provides you with Mobile device Bid Adjustments, such as -10% based on bidding behaviors of similar advertisers in this example. This change limits the need to segment campaigns by device; however, also limits your ability to take device specific actions. Figure 2A:

Extensions

As previously mentioned, advertisers have more flexibility and reporting within enabled Enhanced Campaigns. Ad extensions now can be associated to an ad group (versus a campaign), reported on individually, and be scheduled to only run during specific times. For example, pausing phone extension after business hours.

Phone Calls

A few big changes around desktop and tablet manually dialed phone calls are going into effect. First, phone calls will now be free and can be included as a conversion goal in your reporting. Second, no longer will you need to adjust call metric bids to increase the likelihood of serving your phone extension-enabled campaigns ads with phone call extensions.

Summary

Google’s changes are spurred by the need to adapt to the increase in mobile usage. Google will surely benefit financially from these changes; however, advertisers and agencies benefits may not be realized for some time to come. Since the changes are inevitable, we recommend to begin planning the transition of your campaign structures now. Google has been known to extend deadlines (in this case, the current deadline is June/July 2013), but the sooner you begin migrating your account(s) to the new format, the sooner you can receive the benefits and gain insight on the effects of this change. Never hurts to be an early adopter in paid search!

Helpful Enhanced Campaign links for further research:

Enhancing AdWords for a Constantly Connected World from the Google Blog
Google Enhanced Campaign Upgrade Guide
Google Webinars
About Enhanced Campaigns from the Google Help Center

Can You Trust Your Google Analytics Data?

Ryan — Thu, 21 Feb 2013 12:00:36 +0000

Can You Trust Your Google Analytics Data?

Your data in Google Analytics may not be as accurate as you think. If you have a high volume of visits, your data could easily be off by 10-80%, or even more. Shocking right? It is our fear that people aren't aware of this and could be making data-driven decisions on potentially inaccurate data. So what data can you trust? Well, the short answer is that you can trust data such as visits and pageviews, but you can't rely on revenues, transactions, goal conversions, and conversion rates. In this post, we will do a deep dive into the world of sampled Google Analytics data and helping you understand at what point you should trust the data (or not).

Reasons for Inaccurate Data

One reason for inaccurate data is your implementation; we've focused on that topic in previous blog posts and we also offer consulting services to expertly address those issues. Another reason, which is outside of your control in Google Analytics Standard, is the amount of data you have and your probability to receive sampled data in the Google Analytics reporting interface (or even via the API). We'll be focusing on the latter.

How Does Sampling Work in Google Analytics?

The majority of the Standard reports you find in Google Analytics are not sampled. They've been pre-aggregated by Google's processing servers and no matter your date range you'll be looking at unsampled data. There are though a number of triggers that cause sampled data in GA. The primary reason for sampled data is that your selected date range has more than 500k visits and you are either running a report which is not pre-aggregated and/or you are applying an advanced segment (default or custom). It is very helpful, prior to reading the remainder of this post, to read the details about how sampling works in Google Analytics. To be clear, we are not talking about data collection sampling via _setSampleRate (so ignore that in your reading at the bottom of the sampling article referenced). Data collection sampling is a very straightforward concept in which you are electing to only send a specific percentage of data to GA. In this post, we are talking about the automatic sampling of data in Google Analytics, which exists in both GA Premium and GA Standard (the difference being the availability to run an unsampled query and download the data in Google Analytics Premium). [caption id="attachment_3289" align="alignright" width="283"] Google Analytics Sampling Slider - Set on 'Higher Precision'[/caption]

Sampling Slider

To avoid unnecessary sampling in the interface, make sure you are aware of the sampling slider, and only making decisions based on 'higher precision' data. Where is the Sampling Slider? When sampling occurs, you will see the checkerboard button appear (indicated by the hand cursor in the image to the right) and when clicked it will display the sampling slider (as highlighted in blue to the right). How do you use the Sampling Slider? You move the slider between the Faster Processing and Higher Precision Settings. In the examples, we provided we use two specific slider settings:

50% Slider Setting (default setting) - Balance between 'Faster Processing' and 'Higher Precision' which is the default Google Analytics setting. Data is often under or over reported by 80% or more using this setting. While it is nice to move around the interface faster, we don't recommend this setting or anything further to the left of 50%.
100% Slider Setting (Highest Precision) - The farthest right setting for 'Higher Precision' (same as shown in the screenshot above), which requires a manual override by the user to move the slider to the far right. Data is usually within 10% of actual value. Keep in mind that this setting is 'Higher' not the 'Highest' precision, and does not always yield more accurate data than the 50% default slider setting.

The Problem

When you have a high volume of visits, the quality of your analysis can be hampered by sampled data. Your notification that the data you are looking at is sampled is shown below and will appear at the top right of the report:

When you see this notification, you are presented with two facts about this sampling:

The report you are looking at is based on X visits and that is Y percentage of total visits.
The percentage of total visits that your segment represents (if you don't have a segment applied, this is 100% of your total visits).

So, what is missing here?

It is great that Google gives you this information, but the data point missing is what is the accuracy level of the data (at the report's aggregate level as well as at the row level). Long ago, Google used to show a +/- percentage next to each row of data; unfortunately this important piece of data was removed a while back. Without this data, we fear that people are making data-driven decisions on potentially inaccurate data.

How Accurate is Sampled Data?

To answer this question, we analyzed data across various dimensions and metrics with a variety of sample sizes and then compared it to unsampled data obtained from Google Analytics Premium. One advantage of GA Premium is that when you see the sampling notification bar, you can simply request the report you are looking at to be delivered to you as unsampled data. We've leveraged this feature in this post to deliver to you important insights about sampled data.

Our Approach

First, let's review our approach:

Our tests simulate actual real-world queries.
We were interested in the following metrics: visits, transactions, revenue, and ecommerce conversion rate.
We wanted to view the above metrics by two different data dimensions: source/medium and region/state (filtered for US only).
We built two separate custom reports, one for each data dimension noted above, and then the metrics that matter to us.
A different date range was used for each custom report in order to get different sample sizes, since sample size likely impacts data quality.
Four tests were ran for each custom report:
1. No segment applied sampled data with the sampling slider bar at 50% and another query at a 100% sampling slider bar (this data is sampled due to the dimension/metric combination we selected since it is not pre-aggregated by GA) versus unsampled data.
2. New Visitors segment applied data with the sampling slider bar at 50% and another query at a 100% sampling slider bar versus unsampled data.
3. Mobile Traffic segment applied data with the sampling slider bar at 50% and another query at a 100% sampling slider bar versus unsampled data.
4. Android Traffic (custom segment matching OS = 'Android') segment applied data with the sampling slider bar at 50% and another query at a 100% sampling slider bar versus unsampled data.
Unsampled data was obtained using Google Analytics Premium (not a feature available for Google Analytics Standard).
Since we did this for two custom reports, we ended up having 24 total data queries (3 queries for each test * 4 tests per custom report * 2 custom reports).

The table below summarizes what we know about the sampled data, prior to comparing it to the unsampled Google Analytics Premium data:

As you can see above, the sample sizes are consistent across the various sampled data for each of our two reports. This makes sense as we are using the same date range and just selecting a different segment and sampling bar position. The important thing to note before we move on is that in the order the segments appear above, the % of total visits that the segment represents decreases from 100% (for no segment) all the way down to 4.54% (for the Android segment). In between, we captured a data point at 56% and 14%.

The Results

We performed three separate data quality analyses. First, we'll look at the overall metric accuracy across all data in the report. Then after that, we'll look at two subsets of data (individual row accuracy and top 10 row accuracy). The percentages shown throughout this analysis are variances as compared to to the unsampled data.

Data Quality Analysis #1 - Overall Metric Accuracy

For the Source/Medium data dimension query, the below table contains the results. Let's review the results of the Source/Medium query: Visits:

The visits metric is quite reliable across all samples and sampling slider bar settings (keep in mind we are looking at the overall metrics and not individual rows just yet).
The largest variation was -1.46%. If we were dealing with an unsampled value of 1,000,000 visits, then this variation would yield 985,400 visits. Not terrible by any means.
Increasing the sampling slider bar to 100% (500k visits) did not always yield more accurate data for the visits metric.

Transactions:

Accuracy ranged from -0.92% (quite good) to -11.86% (now we are getting into unreliable data).
1,000 transactions (unsampled) at a -11.86 variation results in 881 transactions in sampled data (119 missing transactions).

Revenue:

The largest variance here was -16.09% and also had a +11.37% in the Android segment. It is important to note that sampled data may be under or over reported.
At a -16.09% variance, $500,000 becomes a sampled value of $419,550. $80,000 unaccounted for in this example is a big problem.

Ecommerce Conversion Rate:

Accuracy ranged from -1.21% to -12.47%

For the US Region (States) data dimension query, the below table contains the results. Let's review the results of the US Regions query: Visits:

The visits metric is reliable just as it was in our source/medium queries.
The largest variation was +0.89% for our Android segment (4.54% of total visits) with the sampling slider set to 100%.
Oddly enough, when the sampling slider was at 50% (250k visitors), the overall data was more accurate. We definitely cannot state that this would always be the case; in fact it statistically should be a rarer occurrence for less visits in a sampled set to yield more accurate data.
At a +.89% variance, 1,000,000 visits becomes 1,008,900 (not bad!)

Transactions:

At a +16.55% variance, 1,000 transactions becomes a sampled value of 1,166

Revenue:

At a +14.74% variance, $500,000 becomes a sampled value of $573,700 (yikes!)

Ecommerce Conversion Rate:

Accuracy ranged from -0.18% to +16.29%

For the Overall Metric Accuracy, we found that the visit metrics presented little concern. We know that the data won't be accurate, so we can live with a peak variance of -1.46%. On the other hand, I start to get concerned with the transaction and conversion rate metric accuracy and then much more concerned with revenue. I believe the problem here is that Google Analytics uses a sample of visits to compute the data and of those that were included in the sample, only a few percent (relative to the ecommerce conversion rate) had a transaction and the revenue values will differ by quite a bit. You can see how the sampling becomes diluted. If you had an ecommerce site where everyone that transacted had the same revenue amount, then I would suspect that the revenue metric would not be off by as much.

Data Quality Analysis #2 - Top 10 Row Metric Accuracy

For the top 10 row analysis, I sorted the data by the metric being analyzed. The objective, as an example, being to show the accuracy of the top 10 revenue rows (which may not always be the top 10 visit rows). For the Source/Medium data dimension query, the below table contains the results of the top 10 rows. The results aren't as accurate as the aggregate metrics. A surprising data point was that the 'Android Traffic' segment had a variance of a +4.77% on the overall metric accuracy, while the top 10 analysis resulted in a -2.44% variance. For the US Region (States) data dimension query, the below table contains the results of the top 10 rows. The results again, aren't as accurate as the aggregate metric analysis.

Data Quality Analysis #3 - Individual Row Accuracy Highlights (within the top 10 rows)

For this analysis, I stayed within the top 10 rows of the metric being analyzed so that I would have more reliable data. I could have picked a row that had 1 transaction unsampled and 20 sampled transactions to show a large variance (there are many examples of these), but I assume we want to pick on more actionable data. The visits metric was usually within +/- 6% for the top 10 rows, but when you get to a more narrower defined segment, there were some larger discrepancies:

A source/medium of 'msn / ppc' had a +49.37% variance
A region of District of Columbia (Washington DC) had a -20.20% variance

For the revenue metric, there were a few highlights (and too many weird variances to share):

Top row #8 reported no revenue for a region when the sampling slider was at 50% and then when the slider was at 100%, it was a +7.94%. Again, this is a top revenue source.
#1 source of revenue was off by -80.02% for a sampling slider at 50% and then at 100% ('higher precision' setting) it was off by -11.52%.
#6 source of revenue was off by -608.25%, missing several thousand dollars of revenue
#5 and #7 source of revenue was over reported by 56% and 47%

Frightening

The results of individual rows vary quite a lot and would make me worry about presenting these results of say paid search or even organic search in an accurate manner. For example, I found one of the top sources of revenue (google / organic) to be under-reporting by 31% when sampled. AdWords was under reporting by thousands of dollars in revenue and in one case, reporting $0 revenue and 0 transactions. That is frightening if you are using this data to make decisions and saying that there are no mobile visitors (as an example) that transact via paid search when there actually is! If you get down to a very granular data row (for example a data row that is only 1 visit in unsampled data), then you will have wildly inaccurate data because you'll be seeing the multiplier of the sampling algorithm. As an example, the data I analyzed contained 1 visit unsampled for a specific source/medium, but in sampled data it showed 23. Why would it show 23? Because 23 happens to be the multiplier. The random sample in GA data included this single visit and all data, including this row, in my sampled results were multiplied by 23. Did I have 23 visits for this specific source? Nope! BONUS TIP: If you want to see what your sampling multiplier is, you can go to a report that has very granular dimensions such as the 'All Traffic Source/Medium' report and then sort ascending on the Visits metric. The smallest value for the Visits metric that you see is likely your multiplier. You could also manually calculate this by taking your known total visits in the date range, prior to any segmentation, and dividing by your sample size (500,000 visits for example). If your date range had 100,000,000 visits (prior to any segmentation or sampling) and you had your sampling slider at 500,000 visits (all the way to the right), then your multiplier would be 200.

Conclusions

In our tests, we found sampling in Google Analytics to deliver fairly accurate results for the visits metric. Google's sampling algorithm samples traffic proportional to the traffic distribution across the date range and then picks random samples from each day to ensure uniform distribution. This method seems to work out quite well when you are sampling across metrics like visits and total pageviews (top-line metrics), but quickly starts to present concerns when only a subset of those visits qualify for a metric such as transactions or revenue. I would expect the same accuracy concerns with goal conversion rates and even bounce rates relative to a page dimension. Additionally, we've seen many issues when using a secondary dimension and sampling.

Be Cautious

When dealing with more granular metrics such as transactions, revenue, and conversion rates, I would be extra-cautious about making data-driven decisions from them when they are sampled. As your segment becomes more narrowly defined and you have a smaller percentage of total visits being used to calculate the sampled data, you accuracy will likely go down. In some cases, it could be accurate, but the point is that you won't know for sure if the visits that mattered were included in the random sample lottery. In addition, be cognizant of the sampling level and only make data driven decisions when the sampling slider is moved to "higher precision" (far right). In data quality analysis #3, this was the difference between under reporting revenues by 11% or 80%.

Your Options

We've just told you that your sampled data is bad and put some numbers behind it to explain how far off it might be. So, what can you do about it?

Option #1 - Go Premium

If you are already using Google Analytics Premium, then simply request the unsampled report via the 'Export' menu. If you are a Google Analytics Standard user, you could upgrade to Google Analytics Premium to get this feature. You can contact us to learn more about Google Analytics Premium features, cost, and what we can do for your business as an authorized reseller.

Option #2 - Secondary Tracker

Another, albeit creative, approach would be to implement a secondary tracker with a new web property (UA-#) in select areas (for example only on the checkout flow or receipt page). If you have less than 500k visits that go through this flow (during the date range you wish to analyze), then you'll be able to get unsampled data with just the pages that you've tagged. Some metrics won't be accurate since you are only capturing a subset of data. For example, time on site and pages/visit would both be inaccurate (only accurate within the constraints of what was tagged). This approach certainly isn't right for everyone (also doesn't scale) and implementing dual trackers can be tricky and could potentially even mess up your primary web property if you do it incorrectly. You can work with Blast to help you navigate whether this approach makes sense as well as the full list of drawbacks and advantages as it pertains to your business needs.

Option #3 - Export Data

Export data using short date ranges like 1-7 days, that avoid or limit the amount of sampling, and then aggregate the exported spreadsheets externally to analyze. As noted above, if you see the checkerboard button show up on the right side underneath the date selector, then you need to shorten your date range to avoid sampling. Be aware that you need to be careful about the metrics you aggregate. For example, you can't aggregate bounce rate or conversion rate, but you can aggregate conversions and visits to calculate this metric. If you are interested in this approach, let us know since we have developed a basic tool to make this process easier.

Option #4 - Collect Clickstream Data

A third option would be to collect hit-level (aka clickstream) GA data and store those individual hits in your own data warehouse. At Blast, we have a tool that we developed, Clickstreamr (currently in limited beta), that collects this data and makes every GA hit available to a CSV file that you can consume however you wish (other formats or direct database insertion is possible). With this, your data is completely unsampled and you will need to have a data warehouse structure in place to handle this level of data and the ability to write queries against this data. Phew, that was a long post. As always, post a comment below to ask any questions you may have.