Web Analytics World

Analytics, Mobile, Social Media and Digital Marketing Strategy

  • Home
  • About Us
  • Online Courses
  • Current Bloggers
  • Contact Us
You are here: Home / Archives for Web Analytics Implementation

localStorage vs. Cookies for Analytics Implementations: What You Should Know

September 26, 2017 by Lukas Oldenburg 2 Comments

Image of storage shelving with title textlocalStorage has long established itself as a wonderfully comfortable way to store data in the user’s browser. Many tracking implementations depend on it.

But it is not the best solution for all cases, as 7-8% of users block it (on our site at least).

[Read more…]

Advanced Analytics Debugging: No Code Access? – No Problem!

May 27, 2014 by Lukas Oldenburg 2 Comments

A typical day in the life of a Web Analyst: On a certain web page, something is not being tracked the way it should. Looking at the source code, you are almost certain that adding, deleting or rewriting just that one line of Analytics code would make it work. But how do you verify that if you cannot change that code yourself?

Web Analysts are usually not developers and often have to find errors in systems where they have little to no access to the code base or the server-side templates where the HTML and JavaScript code comes from. You can make hypotheses about how to solve these errors, but in order to test these hypotheses, you often need a developer to update the code first according to your hypothesis.

Say hi to Fiddler, the browser-independent HTTP debugger and manipulator

To get the testing job done without the developer help, you first need Fiddler, a free HTTP debugging and traffic manipulation tool. Remember that, unlike browser-plugin-based debugging tools like Chrome GA Debugger (see my article here), the very basic Google Tag Assistant, or the flashy WASP, the basic advantage of Fiddler is that it is browser-independent. This is important since there are still many bugs that only happen in Internet Explorer or Firefox for example. With Fiddler, you can even debug your iPhone apps or anything else that does not run through a classic browser. And you can manipulate the web pages and files that you up- or download from the web before they render in your browser – and thus, as if they had come like that from the server itself. [Read more…]

Why HTTPS websites like Xing don’t send you any traffic (according to your Google Analytics)

March 20, 2012 by Lukas Oldenburg Leave a Comment

Ever wondered why the biggest German-speaking business network Xing sends you almost no or no traffic at all? It might not only be Xing. As Facebook, Twitter and Google+ and an increasing number of other websites, Xing runs on the secure HTTPS protocol. And that can mean trouble for the referrer data in your Web Analytics tool.

The good old HTTP referrer is getting less and less reliable. Reasons include:

https (by svilen001, sxc.hu)

  1. The multitude of ways other than traditional links you can arrive at a page. For example, think of mobile, desktop or browser apps.
  2. Google Analytics discriminates against “normal” referrers by treating them as less important than search engine or campaign links when a user’s source changes during a visit. I say “discriminates”, but there are probably some good reasons for that.
  3. The “new” (well, from 2009) HTML link attribute “rel=’noreferrer'” which allows websites to not leak any referrer information when following the link.
  4. The increase in sites using HTTPS.  When a link goes from an HTTPS to a HTTP site, by default no referrer is transmitted. This can be a major problem, especially with important sites running on HTTPS, like Facebook, Twitter, Google+ or Xing, the largest business network in the German-speaking world. The whole “keyword not provided” debate when using Google in HTTPS is a related, but different discussion.

If you’re using “untagged” links (no utm_source and the like), all four cases will mostly lead to “direct traffic” in your Web Analytics tool.

I will dig deeper here into that fourth point because a lot of web analysts are not aware of this. And when web analytics tutorials on analyzing your sources discuss referrers, this topic barely if ever comes up. Google Analytics’ Conversion University doesn’t touch it in its Google Analytics Tutorials. Even Avinash Kaushik added this issue only after a user suggested it in his post on “making love to your direct traffic“. 

Facebook, Twitter and Google+ are not a problem

To ease your heartbeat a little, HTTPS is not an issue with Facebook, Twitter or Google+. All these networks seem to want to show other websites that they are generating traffic for them (they should!). All channel their links through a non-HTTPS page that serves as an intermediator (Google+: plus.google.com?url=…, Facebook: facebook.com/l.php?u=…, Twitter: t.co/…). That way, the referrer gets sent along. Make sure to add the “t.co” source to your Twitter segment, by the way.

Intermediate pages also make surfing easier

This intermediate page has other reasons, of course: It makes surfing safer and more private. Firstly, Twitter & Co. can thus prevent you from moving to a spammy or infected site (yet, also sites they might want to censor). Secondly, Twitter & Co. can cloak the original referring URL so the destination website can’t see that someone clicked on a friends-only link on someone’s Facebook page (“facebook.com/john.doe” is not the most private of URLs).

See this example for a link to webanalyticsworld.net on Facebook:

HTTP://www.facebook.com/l.php?u=HTTP%3A%2F%2Fwww.webanalyticsworld.net%2F&h=oAQH3bikK

Facebook even rewrites links in email notifications this way. So if someone sends me a link via a Facebook message and I click on that link in my email notification without going to my Facebook inbox first, the referrer will still be facebook.com. That way, Facebook makes sure the rest of the web gets a complete picture of Facebook’s share of their traffic.

Xing, and other https pages, are problematic

Still, there are https sites like Xing that don’t use intermediate pages. Yet, they may generate a lot of “organic” traffic for you, that is, traffic you didn’t provoke yourself like when people send each other links to your site or post them in their status updates. In that case, there is hardly any way you can figure out Xing’s impact for your website via Google Analytics if your own website doesn’t run on HTTP.

GA Chrome Debugger Screenshot 1 : Xing (HTTPS) link to HTTP page. Referrer = “-“, Campaign Source = “direct”

https to http (Screenshot of GA Chrome Debugger)

—

Screenshot 2: Xing (HTTPS) link to HTTPS page. Referrer gets transferred, Campaign Source = “xing”

Referrer data when link goes from https to https (GA Chrome Debugger)

—

LinkedIn, by the way, runs almost entirely on HTTP (the settings page is on HTTPS) and has a similar rewriting mechanism like Facebook and Google+. So no need to worry here.

So what does all this mean for you? 

1. Does your website run on HTTPS?

a) Good for you, because you need not worry about not seeing the referral traffic in your web analytics tool, as traffic from https to https preserves the referrer. 

b) Bad for you, because other non-HTTPS websites you’re linking to might not realize how much traffic they get from you. Try a solution like Facebook’s to ensure that other sites see your impact.

2. Does your website run on HTTP?

  • Tag all the links you can influence with the utm campaign parameters.
    Check out Google’s basic guide and Lunametrics’ Dorcas Alexander’s suggestions for a good tagging hierarchy.
      
  • Add default campaign parameters when providing “share” links through a widget in an article or product. 
    Example: Add  “utm_source=share&utm_medium=shared-referral&utm_campaign=share_this-url” to the links if someone uses your share widget. You might want to have the links shortened automatically in the process via the bit.ly API or your own tool so they don’t get so long.
     
    If you are really nifty, you can even provide different parameters depending on which sharing option someone clicked on (“share-email”, “share-twitter” or “share-xing” for example).
      
  • If possible, switch to HTTPS.
    I know this is not easy because there are so many other problems associated with HTTPS. For example, a lot of external tracking scripts or widgets, like Google’s on-site search (how ironic!), do not support HTTPS and create ugly browser errors (Internet Explorer 8 shows a popup warning on every page for example). We switched back to HTTP on our website because of these problems last October.
What are your suggestions on how to deal with unrecognized HTTPS traffic?
Now it’s your turn: Do you think you are missing out on a lot of traffic from an important HTTPS site? How are you dealing with it?

Debugging Google Analytics code (II): A Tutorial Video on Fiddler’s Inspector and AutoResponder functions

February 7, 2012 by Lukas Oldenburg 1 Comment

Fiddler is a tool that many web developers are common with. It is my favourite tool for debugging existing tracking code and testing new code.  This video shows two useful functions for this purpose: Inspectors and the AutoResponder. 

Fiddler is a free Web debugging tool. You can download it at fiddler2.com. Fiddler logs all HTTP traffic between your computer and the internet. That means you can view just about everything that is exchanged in the background while you’re browsing the web.

What makes Fiddler so great

Apart from the functions shown in the video below, I love Fiddler because of at least one more reason: It is not dependent on any browser. Tools like Firebug, Chrome’s Web Developer Tools or the Chrome Extension “Google Analytics Debugger” (see the first article on how to use these tools) all just work within one or the other browser. But Web Analytics code is usually JavaScript code. And JavaScript works differently from browser to browser. That does not mean that Fiddler should be seen an alternative to Firebug. Both tools have their purposes and go very well together.

The following video shows how to use Fiddler for Web Analytics purposes. You will learn:

  • How to test existing code with Fiddler’s “Inspectors” feature. The use case will be the test whether a click on an application button really triggers the desired Virtual Pageview call
  • How to try out new or different tracking code without having to upload anything to your server (no IT needed!).

 

 

Tracking on-site campaigns with Google Analytics: Part 2 – The pros and cons of Event Tracking

November 17, 2011 by Lukas Oldenburg Leave a Comment

Welcome to part 2 of this series on how to track on-site campaigns, for example, teasers on your homepage. After taking a deeper look at In-Page Analytics in part 1, we are now going to dive into the world of Event Tracking and Virtual Pageviews and offer you a script that will track all the clicks on your homepage by default.

One of the best things about In-Page Analytics was that you don’t need to add any code to your page or alter your links. With Event Tracking or Virtual Pageviews though, there is no way around some additional coding.

Event Tracking or Virtual Pageviews?
So what’s the difference between Event Tracking and Virtual Pageviews again? To make a long story short: With Virtual Pageviews, you can track Pageviews for “virtual” URLs (you can decide their name), even though there is no real pageview. For example, anytime someone clicks a link on a teaser, you can tell Google Analytics to record a virtual pageview like “/teaser-click-to-url-x”.

Almost the same happens with Event Tracking. To stick with our example, when somebody clicks on a teaser link, you can tell Google Analytics to track this as an Event. The major difference is that Event Tracking doesn’t create fictional Pageviews and thus doesn’t inflate your Pageview-based data. Imagine that every click on every teaser on your homepage was tracked as an additional Pageview. That would skew your data a lot because it also has a major impact on other data like Bounce and Exit Rate, Pageviews per Visit etc…

I prefer Event Tracking
That is the main reason why I do not use Virtual Pageviews for this purpose. Be aware though that Event Tracking can also skew your bounce rate and Time on Site/Page metrics, for example when you use it to track outbound links (usually bounces). Luckily, Google Analytics has recently published a way to work around this with “Non-Interaction Events”.

In the full article, you will find advice on how to properly implement Event Tracking for on-site campaigns, including a javascript that automatically tracks all the teaser links on your homepage or category pages, and we will analyze 7 advantages and 5 disadvantages of Event Tracking as a means for tracking on-site campaigns.

  • 1
  • 2
  • Next Page »

Accelerate Your Career

Business Blockchain

Never miss another post!

Entering your email address in the field below will subscribe you to our RSS to Email list. This means that when we publish a new post, you'll get an email with a synopsis of the post and links to the full article on this site.

  

You can unsubscribe from this service at any time by following the instructions within the notification email.

© 2021 Web Analytics World • Privacy • Cookies