Posts Tagged ‘google analytics tips’
Sometimes, the urls (and titles) of your pages are not conducive to web analytics reporting. For example, your ecommerce site’s payment, shipping, and order confirmation page may all have the same url for some reason – http://www.domain.com/checkout.aspx. To web analytics, all these funnel pages are reported as one page. You are now stuck, you can’t create ecommerce funnels and measuring shopping cart funnel abandonment is impossible. And there is a more subtle and serious issue as well, in your report, you may find hits (events, ecommerce, social, etc) associated with this url, but you won’t know what part of the order process these hits belong to.
Here’s the actual flow we want to track and understand:
If you have a shipping calculator on your shipping page, a card type drop-down on the payment page, social buttons on all pages, you want to track each of these events on each page. However, it will show like this:
All the urls are the same! How do you know if these events happened on the shipping page, payment page or order confirmation page? You might be able to tell from the event names, but in some cases you may not be 100% sure, and this is definitely not clean and ideal.
While fixing the actual real urls and title tags (assigning unique urls and titles per page) would make things very organized, your content management system may not support this, or you might prefer not to spend that time or money on developers.
Luckily, there is a secret, undocumented method that allows you to actually set the page url and title of a visited page in Google Analytics. More importantly, it will actually associate the hits with these new, more meaningful page urls and titles. Your reports will be easier to read and will provide insights that may not have been available before.
The Issue With Virtual Pages
The traditional solution to this would be to use the _trackPageview method and trigger virtual pages for each “step” (i.e. /virtual-page/shipping.html, etc.).
The drawback here though is still, the actual events will not be associated with these virtual pages you’ve created. They will always be connected to the “real” page, which would be /checkout.aspx (as you can see in the screenshot above). You’re still lacking potentially valuable insights.
SECRET HACK! Setting the URL and TITLE in Google Analytics – _set method
With this new _set method, you can manually set the url and title of the page to whatever convenient name you want.
_gaq.push(['_set', 'page', '/new-meaningful-url.html']);
_gaq.push(['_set', 'title', 'New Meaningful Title']);
Simply push the new page’s title using _set method before calling your _trackPageview…
var _gaq = _gaq || ;
_gaq.push(['_set', 'page', '/new-meaningful-url.html']);
_gaq.push(['_set', 'title', 'New Meaningful Title']);
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script'); s.parentNode.insertBefore(ga, s);
In the case of the ecommerce example mentioned earlier, for each page you’d like to rename, you can pass the preferred url and title so that it’s separated and meaningful in Google Analytics and associated WITH THE HITS:
_gaq.push(['_set', 'page', '/shipping.html']);
_gaq.push(['_set', 'title', 'shipping page']);
_gaq.push(['_set', 'page', '/payment.html']);
_gaq.push(['_set', 'title', 'payment page']);
_gaq.push(['_set', 'page', '/confirmation.html']);
_gaq.push(['_set', 'title', 'order confirmation page']);
You’ll be able to see events and figure out things like “Did they abandon the cart at the payment page? At the shipping page? What are they clicking on the order confirmation page?” etc.
What do you think? Share what other use cases you might have in mind.
Update 07/15/2014: Google Analytics has changed “Profile” to “View”.
Previously, Google Analytics had only 2 roles (“Admin” and “User”), which are very limited. They announced today that they’ll be expanding the flexibility of access – which is good news for anyone that has multiple hands in their Google Analytics accoqunt cookie jar (you have multiple accounts/properties/views but want to give…
- …different employees different access/security roles to specific properties/views.)
- …particular clients/agencies view or admin access to specific properties/views, etc.)
For detailed instructions on the new permissions system and how to set it up, visit the Google Analytics support entry here.
Google Analytics Account Tiers – 101
For those that are new to the structure of Google Analytics accounts, they’re broken down as follows:
- Google Analytics Accounts – this is the general account you set up for analytics. It would be on an organization basis. Example, an analytics account for E-Nor, Sony, Proctor and Gamble, etc. This is the large bucket and you get an assigned ‘UA’ number.
- Properties – Under the account, you can have multiple “properties” – website 1, website 2, mobile app, etc.
- Views – Within each property, you can have multiple views. Maybe for your website, you want a view that only shows E-Commerce data. Another example, say you’ve filtered out all your company traffic from your view so you only see data from “visitors”, not your developers doing work on your site. You also have a backup view (always have an unfiltered control back up view!!!). Etc.
- Users – In order to give someone access to a Google Analytics account/property/view, they must have a Google Account.
The “Old Ways” and its Limitations
As it works now, the user permissions are pretty limited. You can only have admin access at the account level (all properties/views under the sun). Nothing in between.
If you have multiple properties (say website and mobile app), and you want to give a specific user/client admin access to only a portion of that (say, yet you want say the website development team to only have access to the website property/views), this wasn’t possible.
User “View Only” Access per View
Also, you could only give users “view only” access per view. If you wanted to give users “view only” access to all views within a property, you’d have to manually select each view under that property and give them access.
Enhancements and Improvements
User Permissions at Every Level!
Analytics users have been requesting more granular user permissions. Today, we got the answer from the Google Analytics Blog. They’re expanding these options and will allow you to basically set access at every tier. Set users to have view/admin specific to properties, views, and/or the entire account. No more worrying about a user having too much admin access. No more having to manually select views per property – you can set access to whole properties.
We now have the ability to give different access specific to each tier.
For example, while a user can now have permission to say view the entire property, you can also limit their admin access within that property (per view). Example, give the website developers access to view the entire web property, but only edit the E-Commerce view.
The only trick is admin access inherits permissions from its parents. Meaning, if you have full account admin access, it wouldn’t make sense then to only have “view” access to specific properties/views under that account – you have full access.
New User-Role: Manage Users
We know that today Google Analytics has 2 roles of access – “admin” access (which gives users permission to edit Google Analytics accounts/properties/views) and “view only” access.
They’ve now added a third role called “Manage Users”, which allows that that user to add and delete other users as well as assign them permissions. This is different from “edit” and “view” permissions.
Pretty cool! Give certain employees/agencies specific access so they don’t mess up other views! (NOTE: Your account may not yet have this feature, but Google is working on migrating all accounts to have this within the upcoming weeks, so keep checking for it).
For more information on the new permissions system and how to set it up, visit the Google Analytics Support entry here.
What in the….? “Google Analytics” is a browser?!
(For the quick answer, skip to the “Conclusion” below…)
We ran into a confusing situation the other day with a client. They were getting traffic from a browser called “Google Analytics“. It threw us for a loop, because obviously, we’re familiar with Google Chrome, Firefox, the awesomeness of Internet Explorer (sarcasm), Opera, and Safari. Haven’t had the chance to use the Google Analytics browser though.
That’s cause there isn’t actually a Google Analytics browser as you might have guessed. So we were weirded out to see that in our reports. What does it mean when you see on your reports that a large number of visits are coming from “Google Analytics”?
Here’s what we figured out:
On a hunch, we decided to segment for mobile traffic only.
The number of visits from the browser “Google Analytics” essentially didn’t change (the change was so minor, we could assume this was due to sampling). Thus, it looks like this traffic is pretty much mobile traffic.
For this client in particular, they saw a spike of traffic that corresponded to this number. We asked if anything special happened around the time of the spike. They confirmed that they had recently launched a new version of their mobile app.
Conclusion: The Answer Is…
After some more digging and testing, we concluded that when the browser says “Google Analytics”, it’s mobile app traffic! Apps using either the iOS or Android SDK for Google Analytics will report their usage under the browser “Google Analytics.” Not sure when Google will change that, but hopefully, that will help anyone trying to solve that mystery explain to their executives or clients where this traffic is coming from. One method of preventing this from happening entirely is to report mobile app traffic to an entirely different account than your web traffic.
If you have been around marketing and analytics for a while, you know that getting a solid reading of your analytics and optimization is a journey, not a destination. You understand that data is not clean, and 100% accuracy is not attainable. So I think the most we can ask for is to establish processes and educate people on how to keep things under control and still have faith in their data.
This post addresses practical analytics processes to maintain and improve the quality of your data when upgrading or redesigning a site, or migrating to a site/new content management system. While the examples in this post are Google Analytics specific, the approach is applicable to other analytics solutions.
The old adage of Prior Preparation Prevents Poor Performance is so very true here. Those 5 P’s can make a world of difference before a site migration or upgrade.
You definitely don’t want to end up with this scenario (no data)
If you have done your analytics implementation right, you should have maintained different documents; a reporting/metrics doc (marketers) and a solution design or an analytics technical specs doc. In such documents you define what code to add, what custom tracking you are doing, where customization have been implemented, etc. When you plan to migrate or upgrade your site, it’s time to clean the dust off these documents and put them to work for you again!
1- Site Migration/Upgrade Analytics Planning – Marketing
First of all, review your site goals, and ask questions such as:
- What micro conversion am I tracking now and do you want to track on the new site?
- Video/multimedia user actions (play, forward, stop, etc.)
- Have a new blog and I want to measure comment submissions
- I really want to get an understanding of social interactions on my site
- Are my macro conversions changing?
- I didn’t have e-commerce, now I do
- The site didn’t accept paypal/google checkout, but now we need to track it
- I am using a marketing automation platform with tens of landing pages and lead capture forms. How do I want to see lead conversions in my reports?
- Any custom segments that you track closely?
- Your reports might include members vs. non-members segments, member classification, user segments, time-stamped user actions, content groups, etc. this type of data is typically available in your reports based on GA customization and need to be discussed with your technical team
- Make a note of this type of data and ensure this customization is carried over to the new site
- Third-party System Integration
- Identify parameters you are passing to third party systems or integrations you’ve done CRM solutions (e.g. SalesForce.com), or other rich data integration work you’ve done (and rightfully got recognize for!)
- Social: this post would be not as popular if it doesn’t have the word “social” . Look for how your are measuring your socially active users. You might be using GA’s social tracker natively or you might have integrated with AddThis or ShareThis
- Mobile: if you, like many, are launching a mobile site, add your measurement plan for your mobile site to the to-do list. And don’t forget about any niche mobile analytics tools that you have previously implemented (and actively using)
- In addition to your web analytics solution, review the long list of tags/pixels you currently have on your conversion pages such as AdWords conversion tracker and other pay-per-click tags, doubleclick, affiliate, or maybe a niche heatmap tag, or a phone tracking tag, or the testing code such as the Google Website Optimizer (and the list goes on and on, I know)
- If you are using a Tag Management System (TMS), you’ll have less issues with migrating your tags, but then add an item on your to-do list to engage your TMS vendor and seek their support during the planning and implementation of your new site
Have your new or updated goals list ready and then reach out to your friendly webmaster/analyst/consultant to help you implement.
2- Site Migration/Upgrade Analytics Planning – Technical
Sit down with your developer and go over:
- Your standard GATC
- In most cases, you’ll use the same GA account (same UA number). I have seen situations where clients prefer to start a new GA account altogether (with a new UA number) especially if the historic data is a bit messy and they want to have a fresh start
- Any code customizations you have done
- If your current site has sub-domains or you have cross-domain tracking, assess how the new site will be structured and if the domain/sub-domain structure will be intact or is changing
- If you are using events or firing virtual pageviews, look for code updates necessary to maintain the same data collection method
- If your URL structure and page naming convention is changing, document impact on:
- Filters, Goals, E-commerce variables, Custom variables, Advanced segments (that your users are actively reporting on), Custom Alerts, Custom reports with filters, Dashboards with filters
- URL Redirects: redirects are very useful and commonly used on websites. However, they are real culprits if not properly set up and cause all sort of issues such as breaking sessions, dropping parameters or linking to older posts. And while you’re at it, review your URL query parameters and decide what you want to exclude in your GA/Profile Settings.
- Site Search (or Internal Search): if your internal site search has changed along with the site upgrade, then update the search query parameter in your Admin/Profile Settings
3- Post-Launch Analytics Validation – Technical
Webmasters & Developers
- Ensure your GATC is on all your pages and then run your favorite site scan software
- Ensure you are collecting data only from your production web properties. Look for development and staging environment domains. Review your hostname reports and filter out what doesn’t belong there.
- Pay extra attention to key pages
- Landing page/static pages that are not part of your site template
- Conversion pages (thank you pages, form completion pages, e-commerce purchase complete pages, etc.)
- Site Speed Report (under Content) will be your best friend after site launch. Look for Average Load Time, Page download time and other related metrics and spot any spikes and investigate root causes, with pages, server or redirection time
Don’t forget to plan your configuration changes across all your profiles and not just the main profile.
4- Post-Launch Analytics Validation – Marketing
One quick way to see the before and after is to set up a date range comparison (equal number of days, and days of week before and after launch), then monitor the following:
- Run a quick report on traffic/key metrics/conversion by browser. Also, review your mobile traffic and behavior on various devices. If you see significant variances in any of your key metrics pre/post launch, let your designer and webmaster know immediately. The new site might be experiencing browser/device compatibility issues.
- Traffic Sources
- Look for new traffic sources that didn’t exist before (new self referring sources?)
- Look for a sudden spike/drop in direct or referring traffic
- Review your Pages report, is the reported page names what you would expect to see?
- Setup a report on your 404 page and have it emailed to you/your webmaster on a daily basis
- Review your reports on any internal (on-site) campaigns
- Goals, e-commerce numbers look ok?
- In our Analytics Reporting Framework, step #6 was about “automation” and automation comes very handy here
- Set up Auto Alerts (intelligence) on all vital metrics
- Look for abnormalities in your default alerts
- Do take a minute to add an annotation when the site goes live and include a meaningful description of major changes (page names, goals, etc.). Trust me, the person who comes after your will love you for helping them making sense of all these changes (when they come back few months down the road and no one is around to tell him what happened that day)
- It’s not uncommon that site migration has an impact on ranking and organic traffic. The idea here is to be aware of the changes and communicate findings with your SEO team so they can monitor and update as needed. Look for the Organic Traffic Report and drill down when you see issues.
So there you have it. Preparing yourself before updating your website will lead to less headache in the long run. By following these suggestions, your site will not only have that fresh new look you develop, but also have the functionality for ease-of-use for visitors and the ability to track the necessary data for you.
PS. Proper planning for a site migration includes SEO considerations and PPC considerations, content and many technical aspects but that’s something I’ll leave for another time (and probably to someone else)!
Related Posts & Articles