The word “dashboard” is not on my hate list, but it seems to be on a lot of other people’s. Everything has a dashboard now, from software products, to consulting deliverables (we do them weekly for our clients), even video games and LinkedIn have dashboards in them.

So, I get why the thought of another dashboard would make many people want to barf, but it doesn’t make me think they are any less vital to being successful with data.

A few points below that you should consider before you give up on dashboards (I had a great Karate Kid reference I was going to make, but I have been informed that I need to dial back on the 80s film references…).

The obvious point:

A dashboard you don’t love wasn’t built properly: A good dashboard is supposed to provide ‘at a glance’ understanding of something you care about, giving you the ability to have increased understanding you wouldn’t have achieved any other way. If you are indifferent to a dashboard, it sucks. Get rid of it and have one crafted to your exact needs.

Less obvious but critical points:

1) Dashboards create commonality of language and goals: Ever notice that sales and marketing people use different words to describe the same thing? Ever notice that they don’t tend to get along? A well crafted (and agreed on) dashboard has the ability to create significant alignment in an organization, not just between different departments, but between different levels of the org chart. In helping a senior stakeholder build an exciting and relevant performance dashboard, we are very educated on where to focus our analysis on their behalf.

2) Dashboards decrease “weaponized” analysis: In organizations without proper executive dashboarding (so most of them…), the lack of common language, goals and structure creates “analysis anarchy”. This means that execs often ask the analysis to provide reports and data to support an idea or initiative. We call these reports ‘weaponized’ because they are only being created to provide data support to help win an argument, i.e., “Build me a report that shows how marketing has been wasting money on leads for the last 6 months”. Competing on analytics is supposed to be an external activity, not an internal one. It’s very hard to weaponize your reports when the whole team ultimately works again an agreed on performance framework.

3) Good Dashboards maximize analyst value and contribution: the lack of structure around data consumption is the Petri dish that dumb questions grow in (would that mean ‘bad culture’?). Many of the ad-hoc questions that web analysts get are based on a lack of overall understanding about digital. We find that instituting an appropriate and valuable weekly performance dashboard cuts down on ad-hoc requests significantly, and increases the quality of the questions being asked. Good questions tend to be harder to answer; your analyst will still be 100% utilized, but purely on creating insights of high business value.

If you are making plans for 2012, and someone comes out against using a dashboard, realize that they are tired of the abuse of the term, not the value proposition.

Just call it something cooler, like a ‘executive performance visualization’. At the end of the day, a well executed dashboard can have both corporate and competitive effects that are far reaching.

Cheers,

Jim

A quick recap on past write-ups:

• Batman: The boss, not the analyst.  A great executive-facing analyst knows who the hero of the story is, and works to empower them, not overshadow them.
• Doc Brown:  Great analysts will hack together what they need from what they have, not just stay inside a given tool.  They will also focus on the temporal nature of measurement, using the past and the present to predict the future.
• Columbo:  Relevant analysis can’t exist in a vacuum.  Constant interviewing of your internal stakeholders will help you learn their language and motivations, and ensure that your analysis is timely and relevant.

This week we are focusing on one of the least analytical and perhaps one of the most important of our pop culture references: Sam Malone from Cheers.

For those of you unfamiliar with Cheers (it was on TV for over a decade…), it was a sitcom about a group of regulars at a bar in Boston.  Sam was the central character of the show. He was the owner of Cheers and the mainstay behind the bar.

Sam showcased all the qualities inherent in the ‘perfect bartender’ stereotype.  He was a charmer and an amazing listener; strangers would often open up and tell him their problems (which he would then try and fix).  He had a great memory for drink orders, bringing people what they wanted before they asked for it.  This pathos and attention to detail is the glue that holds the motley group of regulars together, and creates a community within the bar.

I am guessing that Sam Malone would be a crappy analyst, at least from a data modeling perspective.  I also guarantee that he would be very effective at knowing what his internal stakeholders needed, and create the kinds of relationships internally that would allow his findings to be both appreciated and used to best effect.

As a real world parallel, Napkyn has become the analyst several times in organizations where there is interdepartmental conflict – sales hates marketing; eCommerce doesn’t agree with Merchandising.  Initially, we are often asked to ‘weaponize’ our reports, to frame the data in such a way where one group looks good and the other looks bad.

These situations are where the Sam Malone reference comes out.  By being positive and proactive with all stakeholders, we try to do analysis that creates positive impact through alignment.  The analyst has the ability to become the common person bringing together that motley group of personalities, which doesn’t just have the most impact on the business, it also positions the analyst in a much more important light than just someone who builds reports.

Getting an executive to care about analysis can sometimes have a whole lot more to do with customer service than Microsoft Excel.

Cheers,

Jim

I’m awfully pleased that this series seems to resonate in the measurement community, because I know a lot more about TV shows from the 80s than I do about how eVars and event scripts work.  And for those of you just tuning in, that’s the point here.

A good story, listened to by the right person, will trump a spreadsheet every time.

Now having the story be accurate, and earning the right to have the appropriate person listen, are hard to do.  This week’s pop culture reference is a personal favorite of mine, and once again is a reference that I make continually at the office, especially when training new analysts on how to engage their new executive stakeholders through the Analyst Program.

Unfortunately, I also tend to have to lend them the first season of the show, because anyone under the age of 30 has never heard of Columbo.

For those of you who haven’t seen this show, it’s a murder mystery TV series that was on from the late ’60s to the mid ’90s, and stars the amazing Peter Falk as Columbo, a quirky homicide detective.

Unlike most detective shows (think Law and Order), Columbo was not a menacing, tough talking inquisitioner.  He played a disheveled, confused looking, gunless detective who would often ask obvious questions. Every single episode, he would find the murderer by piecing together often tiny details put together over the course of his seemingly innocuous interviews.

Columbo would have made one heck of a good business analyst, and he is my go to reference when discussing how relevant our work is to a particular executive.  Here are the key points about Columbo that make him such a valuable example.

Constant Interviewing Saves the Day:  Columbo is the opposite of the team at CSI, where they use math and science to catch the killer.  He patiently talks to every single person involved with a crime to understand motivations and alibis.  If he was to take a job as a business analyst, he would interview every key stakeholder about what they do and what they care about, before ever opening a reporting tool.  We try to have a conversation as part of every dashboard build or ad hoc report request.  This always makes the work more relevant, and often helps us find even better ways to proactively show insights on the business.

Ask ‘stupid’ questions:  A lot of times the answer to a question is much more important than the question itself.  I try and ask ‘stupid’ questions, or a question where both I and the executive know the answer, all the time.  You would be amazed at the details you learn when getting a smart answer to a stupid question.  In already knowing the answer, the analyst is able to devote 100% of their effort to listening to the language and the specifics of what the executive is saying.  Also, throwing softball questions that an executive is able to answer allows them to feel like their analyst is supportive and listening.  These kinds of questions are going to go a long way in both getting executives to  give you the time of day, and in helping you to write and speak in ways that they will appreciate.

“Just one more thing”: If you haven’t seen an episode of Columbo you won’t get this reference, but it’s a good one.  In almost every episode, Columbo will be interviewing the killer and throwing lots of softball questions.  Right when it looks like he’s leaving, he stops, turns around, and asks a question that starts with “Just one more thing…”.  This question is always a well thought out, hard hitting one, which helps solve the crime.  Many analysts (and I am guilty of this one too), try and lead discussions with executive stakeholders with the hard questions.  Not only does this sometimes mean that we are leading with the wrong questions for the business, it also means that we are starting off a discussion in a confrontational manner.  Save your tough questions for later in a discussion or interview, and allow them to be “Just one more thing”, it will help you ask much better questions, and will create more solid relationships with the people whose decisions you support.

Even if you have never seen an episode of Columbo (which is a shame), there is a heck of a lot of value you can take from his approach to problem solving.  Having continual conversations with the people you work with and support allows you to increase your visibility and your value.  Asking the right kinds of questions in the right ways lets you do better work (and frankly have more fun doing it).

Cheers,

Jim

P.S., (aka, “Just one more thing…”): This is not a permanent series, there are only two references left to go.  I promise you won’t be reading posts from us in two years where we try to explain how The Breakfast Club is actually about multi-channel attribution.

Check out the other posts in this series:
Part I: Alfred and Robin
Part II: Doc Brown

However, this philosophy comes at a price. Because it indiscriminately accepts any data it’s given, it accepts any data it’s given. The result is that, if someone with the right skills is feeling particularly malicious, they can vandalize and seriously distort your business’ data. There are two ways this can be done.

We’ve been aware of these potential issues for some time now, but we wrestled a bit with the decision of whether or not to post this. On one hand, we like to share our knowledge and, since this is a very real fact about Google Analytics, it’s good for GA users to be aware of it. On the other hand, we’re potentially teaching people how to mess with someone’s GA deployment. Ultimately we decided on transparency and honesty — after all, we’re also going to tell you what you can do to protect yourself from these. But we must begin with a caveat: we do not endorse doing anything like this. We offer this information so you can be aware of potential security risks with your own data, and take the necessary steps to protect your data integrity.  We are strong supporters of the Web Analyst’s Code of Ethics, and though that code doesn’t say much about messing with others’ data, the idea is generally to be open and honest with data.

(Update: I should also point out that Google Analytics is not alone in being vulnerable to some of this. The approach to campaigns and ease of copying other data makes it easier than with some tools, I think, but those stem from Google’s strengths rather than weakness. I offer Google Analytics up because they don’t have a service level agreement for everyone, and hence it’s up to you to protect some of your data. Despite any vulnerability, I do want to be clear that Google Analytics is a fine tool and this alone is not cause for alarm, just something to be aware of when implementing this tool, and by extension, others like it.)

With that out of the way, here are the potential exploits we’ve seen:

Campaign Vandalism

Google Analytics makes campaigns tracking easy. Unlike tools like Adobe SiteCatalyst which store campaign tracking codes and convert them into useful data, Google Analytics sets campaign names directly in the URL query parameters, accepting any campaign name that it receives. This saves you time managing all your campaigns and channels, and makes setting up Google Analytics significantly faster. But with GA merely accepting any campaign names it gets, what’s to stop me from visiting your site using a bogus campaign name?

What’s the problem?

Campaigns in Google Analytics work by adding the names of campaigns, media and sources to URLs. For instance, if you want to track a summer email campaign that links to www.example.com, you may enter a URL like this:

In this example, you’re pushing though three pieces of information: the source of your list (newsletter), the medium over which you’re marketing (email) and the name of the individual campaign (SummerBlast). This data will be recorded in Google Analytics, no questions asked. You don’t even have to tell Google about the campaign ahead of time.

But what’s to stop me from visiting your site on this URL?

The answer is nothing. If I were to visit a GA-tracked website with those query parameters attached, their Google Analytics implementation would show that someone came to their site magically, by means of a spaceship, through a campaign called Stupidhead. I did this to one of my own sites, and here’s what I got.

How dangerous is it?

The most someone can do is create a bunch of meaningless data. The effect of a single vandal acting alone would be minimal, though an extremely determined vandal could set up a sort of vandalism bot — an automated software that repeatedly visits your website using falsified campaign data.

If you’re smart about your reporting, you’re probably more concerned about your converting campaigns. In order for vandals to mess with those reports, they’d have to become converting visitors. They may not have a problem with filling out a lead generation form, but if you are running an ecommerce site, these reports have a built-in protection: vandals will have to pay for the opportunity to seriously mess up your reports. (However, you’ll still need to account for the second scenario below.)

How do you fix it?

The first step is to identify vandalism. Chances are, it will be obvious — if someone has decided to vandalize your site, it’s probably because they want you to see it. So a bogus campaign name that shows up in your reports will be clear. If you’ve been smart about maintaining a convention for your campaign naming, you should have an easier time detecting falsified campaign information, though a determined vandal could spoof your own conventions.

Getting rid of the campaign data isn’t as easy. In fact, it’s impossible. What you can do instead is segment it out, so that you see only data from non-vandals. To do this, you need to create an advanced segment. Creating a new custom segment (using the ‘Advanced Segments’ area at the top of a report in the new Google Analytics interface), you can choose to exclude campaigns, media or sources that contain the offending terms.

The problem here is that if you’re the victim of serious vandalism, such as from the bot scenario given above, you have to use this segment every time you look at a report in Google Analytics. That’s a pain.

If you’re a large organization and you’re afraid of receiving an attack to your Google Analytics account, you may consider running more than one analytics solution, or copying the relevant data to your own datamart. The larger you are financially, the more likely such an attack is, but the more resources you’ll have to back-up your data.

What should Google do?

Probably nothing. I think that the fact that you don’t have to do campaign management within Google Analytics is a plus. It cuts down the overhead — every organization should have some method to the madness of creating campaigns and campaign names, but the extra work of punching data into your web analytics tool isn’t always worth the benefit, especially for smaller organizations.

Given the fact that traffic has to convert, and actually spend money if you’re an ecommerce site, in order to mess with valuable reports. If someone really wanted to hit your site hard with this, the most they could do is become a nuisance. It won’t destroy your reporting, but it will make it harder to pull clean data.

However, since Google is gradually approaching the enterprise market with its Analytics product,  its product team may consider providing two options for campaign management: both the current consume-everything version, and an internally-managed campaign list in the style of SiteCatalyst. The benefit would be for large customers, who have the resources to properly manage their campaigns, to be able to do so risk-free.

Fake Data Injection

Ok, so, if I want to, I can mess up the campaign data a bit. And if I want to mess up your revenue sources, then at least I have to pay you for the opportunity to do so, and it may not be so bad.  But what if I want to mess up the rest of your data? Surely, I wouldn’t be able to do that, right?

Wrong. Unless you’ve set up filters to prevent this, Google Analytics will accept data for your Google Analytics tracking account from any server, as long as it sends the web property ID for your website.

What’s the problem?

Because Google Analytics accepts this data from anywhere, anyone can create a web page using your Google Analytics tracking code, view it, and have traffic, events or ecommerce data show up in your Google Analytics report.

For example, what happens to your reports if I create a fake transaction, using your Google Analytics tracking code, with a transaction of -$90 million? Here’s what happens:

The other days in that report aren’t at zero dollars. They range from $50,000 – $100,000, but you can’t see the trends because the fake transaction has skewed everything.

How dangerous is it?

The damage here is greater, in that it will severely distort any reports. Someone could take an obvious step, like the above examples, of pushing huge transactions into your Google Analytics account. However, the vandalism could be more subtle: one could push several smaller transactions with false source data to try and misguide you, or push events that you can’t reconcile with your order management system.

The effect of this and the campaign vandalism method I mentioned above can be compounded. Recall that you’d have to buy something to mess with revenue source data with the method above? It turns out that, if you fake realistic-looking transactions while using spoofed campaigns, you can make an even bigger mess of things.

One limiting factor here is that the visits have to be run from a server that’s connected to the Internet and can host web pages. As a result, you can use the Hostnames report in Google Analytics to identify where the fake data came from. This does mean that if someone wishes to vandalize your data in this way, they will have to do so carefully, otherwise they may be identifiable. Potential vandals would have to go to greater lengths to ensure their anonymity.

How do you fix it?

Finding the fake data could be tricky. In the case of revenue and transaction data, you probably have an order management system with which you can compare the data. However, when you’re strictly looking at Google Analytics, the fake data may not be obvious if the vandal has chosen to be sneaky about it. The first step is to check your Hostnames report. Hostnames are the domain names or IP addresses from which your website is viewed. In the new Google Analytics, you can find the list of hostnames that have been used to view your site from the Visitors > Technology > Network report.

If Google Analytics code executes on hostnames that you don’t own, you’ll want to investigate the problem. In some cases, those hostnames will simply be search engine caches or translation services that are copying your analytics code. However, if you notice transactions or strange events and campaign data from suspicious hostnames, then you may want to look into the matter.

There are a couple of ways to actually fix the problem. The first is an ad hoc approach — if someone drops a fake transaction into your system, simply remove it by executing some JavaScript. This requires you to write a custom JavaScript that basically makes an inverted version of the transaction, with negated quantity, revenue, shipping and tax values. This is annoying, but quick enough to get rid of a single transaction.  You can also handle it the way I suggested handling vandalized campaigns above, using custom segmentation.

However, if you want to prevent yourself from these attacks entirely, then you’ll need to add some filters to your Google Analytics profiles (or create new filtered versions of your main profiles). The goal here would be to create a list of hostnames — the domain names and subdomains that you use for your website — and ONLY accept data from those hosts. Now, you’ll probably want to set up your filters on a new profile, which is a filtered version of your original. That way, you have 100% of the data collected by your site, but also a clean/safe copy to work with.

The example filter I’ve given here will only count traffic, events and transactions from the domain name ‘example.com’. A better way might be to only include traffic from specific IP addresses, if you know the IP addresses of your website(s)–this could prevent attempts to spoof your hostname and push vandalism that appears to be legitimate. In either case, be sure to keep this up-to-date! If you change your domains, subdomains or IP addresses, it may affect your filtered profile and cut out some legitimate, valuable data.

One quick note: Sometimes you’ll see additional domains in your list that are from hostnames that have a legitimate purpose. For instance, Google will serve up your site when it shows either a cached version or a translated version — in both cases, the hostname includes ‘googleusercontent.com’. Bing also shows page caching on cc.bingj.com. You may want to exclude data from caches or translated versions of your pages, but if you’d prefer to see all of it, include data from those domains as well.

What should Google do?

Google should provide these filters as standard options. You should be able, when creating a profile in Google Analytics, to specifiy what host names and/or IP addresses you’re willing to accept data from, and be able to provide an on/off switch for accepting data from other sources. Making this option more prominent may help businesses be aware of the issue and protect themselves from day one.

The are more technically complex, and secure, methods of limiting these kinds of problem that Google could consider. One option is to make use of server-side code in conjunction with the JavaScript to authenticate an API key before data is accepted.

At any rate, rumblings of a paid, enterprise-focused Google Analytics can be heard from the horizon. If a service level agreement becomes available to some Google Analytics customers, data integrity and security will be chief concerns.

Until next time,

Colin

UPDATE: Just a quick note of clarification. Although I focused this post on Google Analytics, I should clarify that GA is not the only tool vulnerable to this — especially the second method of vandalism. The first method is the easiest thing, and that’s more specific to GA. This post came out of an internal discussion about the campaign vandalism. To be clear, this kind of thing isn’t particularly common, and as Emer mentions in a comment below, it tends to be a result of negligence when people copy code or designs, rather than a malicious attempt. So, there’s no need for immediate concern for most people, but I think it’s worth being aware of what you can do to protect yourself from this inherent vulnerability in most analytics tools.

The method of tracking for LinkedIn buttons differs a little bit from the others I’ve posted so far. Currently, LinkedIn does not provide a callback function that executes when an action is completed — there’s no flag in the code that says “visitor shared something, now what?”. Instead, we have to build our own JavaScript function that we can bind to an action. In order to do so, this example uses jQuery, a popular JavaScript library.

The first step is to get your button code snippet from LinkedIn. LinkedIn calls this service LinkedIn for Publishers. When you generate the code, it will look something like this:

This script from LinkedIn above generates new HTML which is inserted into the page in order to create the ‘Share’ button and its functionality. The code generated includes a new <div> element, which has the class name IN-widget.

This gives us the chance to reference the generated button with a little code of our own. Using the jQuery .ready event handler — to ensure that the code does not execute until LinkedIn is finished building the button — we construct a new function that binds to the “click” event for all objects with the class name ‘IN-widget‘. In this function, we include the Google Analytics social tracking code, to create a new social event.

This new code can be added pretty much anywhere on your page — you may want to include it right after the code LinkedIn gives you to keep them together, or put it in your header if that’s how you prefer to organize your site.

Note that in this example, the last parameter, window.location.href, will send the current URL along as the resource shared. In different systems, you may prefer to output the URL directly, rather than through JavaScript. For instance, in WordPress, you may replace the last parameter with the permalink for a post:

Now, there is one issue which must be kept in mind. In the case of the Facebook and Google +1 buttons I’ve previously shared, the social event code only fires after something has been shared. That’s the benefit of the callback function provided by those services. In the case of LinkedIn, however, what we’re really tracking are clicks to the share button — it’s possible for someone to cancel sharing after clicking the button, so you may get an inflated total.

With that caveat in mind, you’re all set! Once you’ve added this JavaScript, your LinkedIn shares will appear in the new social reports in Google Analytics. You can find these reports under “Visitors > Social” in the new version of GA. With this, your web analyst can help you determine what impact these buttons have on your site and your business. For instance, whether frequently-shared articles get much more converting traffic from LinkedIn, and whether the people who share things are also the people who convert themselves.

Until next time,

Colin

We use way more pop culture references in the office than we do math/sciences ones. A good reference tells a story much better than a detailed (and alienating) technical description.  If you don’t believe me, ask me to explain tag management systems using nothing but Terminator 2 references.

With this in mind, I thought I would use the blog this week to share another popular pop culture reference that comes up in meetings all the time, in the form of the following sentence:

“So, what would Doc Brown do?”

I won’t spend too much time explaining the character of Doc Brown, because if you haven’t seen Back to the Future, you probably aren’t old enough to read this.

I will, however, talk about some of the critical aspects of the character of Doc that every analyst should aspire to when approaching their work.  If the Batman reference helps explain how a good analyst should approach their executive stakeholders, the Doc Brown one is for day to day problem solving.

Doc Brown is a hacker: Does the Doc ever give up because he can’t get enough speed and power into the Delorian?  Heck no!  He defines his goal, looks at what he has available, and builds an appropriate means to his end. Many analysts get way too caught up in their technology and lose sight of their goals (support decisionmaking, make more money). Others feel that they aren’t able to be effective because of a lack of developer support or enterprise technology. You would be amazed what you can do with a copy of Excel and a little bit of ingenuity.

Doc Brown doesn’t live in the present:   Based on the end of Back to the Future III, this is a literal statement — but I digress.  The real point is that Doc Brown constantly made decisions based on the fact that the only way to both affect and understand the present is to understand both the past and the future. The only thing better than a critical metric is a performance-focused metric, tied to both historical performance and year-end goals. This temporal context always helps support quality decisions.

Doc Brown isn’t the hero, but he is a critical character:  Similar to Robin and Alfred, Doc Brown is not the star of the Back to the Future movies.  Without him though, Marty McFly would just be some Huey Lewis fan in California who doesn’t respond well to being called a chicken.  Doc is the person who uses technology, intuition and decision support to allow Marty to optimize his family, get the girl, and save the day.

The next time you are looking at a tough analysis problem, do what we do at Napkyn and ask yourself, “What would Doc Brown do?”.  Taking on his DIY attitude and temporal attention will have your boss yelling “Great Scott!” in no time.

Cheers,
Jim

PS – We have three other pop culture references we use all the time at the office – what are yours?

Social media is difficult to track, and as a result, it’s notoriously difficult to assign value to it. So, adding tracking to the few places you can is important. One of those places that we frequently encounter is the Facebook Like button.

Last week, Google introduced Social Interaction Tracking in Google Analytics. Essentially, this allows you to put events from social media interactions into a special category that groups all social engagements together.  We’ve been tracking social media interactions on our clients’ sites for quite a while, but until now this was done with event tracking. The new format, using the Social Interaction reports, lets you view the data through reports that are specifically tailored for this kind of activity. It also lets you more easily group any kind of social interaction together, and provides some automatic segmentation of socially engaged visitors.

So, using this new code, here’s my update on how to track Facebook “Like” buttons in Google Analytics. In this example I use the latest code from Facebook, so you’ll want to update any existing Like buttons you have. I also used the latest, asynchronous version of the Google Analytics tracking code.

Getting your Facebook Like Button code

The first thing you’ll need is the code that actually creates the Like button, which can be obtained from Facebook. Facebook requires you to be a registered Facebook developer in order to make your buttons, which means confirming that you’re a real person either by a text to your mobile phone, or by entering credit card information.

In the post I mentioned above, I said that everything that happens on your site can be tracked — but that some things, including iframes and entirely-external JavaScript cannot easily fit into the mix. Facebook Like buttons can fit into either category. There’s an iframes version, which simply loads in a tiny window into Facebook that’s outside of the reach of JavaScript. The consequence: you can’t track the iframes Like button.

The other method uses Facebook’s XFBML. This version is mainly JavaScript-driven, but includes one very cool feature: Facebook provides a function to handle a Like event. That is, Facebook gives you an opportunity to add extra code to be executed whenever a “Like” happens. This is the perfect spot for Google Analytics event tracking, so make sure to choose the XFBML version of the Like button.

Facebook will give you some code that looks something like the following. Of course, APP_ID_HERE and PAGE_URL will both be replaced by your App ID from Facebook, as well as the URL of the page to Like — both of these parameters are set automatically when you generate the button. The settings you choose when you generate the button will change the second line.

Adding the Google Analytics social tracking

What you need to add is a simple line of code that adds a new JavaScript function. This function’s purpose is to execute whenever the Like button is clicked, and fire a Google Analytics tracking code when that happens.

The asynchronous (async) version of the code looks like this:

You may also want to track “Unlikes”, cases where a visitor clicks the Like button again to remove the page from their Liked content. Using the async method, add this to the JavaScript:

Here’s what the final code looks like when you’ve added the new tracking snippet.  Again, APP_ID_HERE and PAGE_URL, in red, need to be replaced. The new tracking code is highlighted in color:

So that’s it! Google Analytics tracking for Facebook “Like” buttons on your website. Once people start to ‘Like’ your pages, you’ll see the data show up in the Visitors > Social area of your Google Analytics account (in the new version).

Using the Data

Once you have your tracking in place, your web analyst can make use of Google Analytics segmentation and a little bit of smarts to answer some really cool questions. Are the same visitors who “Like” products the same ones who actually buy them? Do posts, pages and articles with more Likes serve as the landing pages for more converting visitors? Is there a best position for social media buttons to get the most shares, Tweets and Likes without distracting from conversions?

All of these questions can be answered with this data. Together with the referral data from incoming Facebook visitors, these insights can give you a sense of how valuable Facebook Like buttons are on your site and how you can best make use of them.

Until next time,

Colin

I had a very enjoyable lunch last week with a few technology executives, where the focus of our discussion was on creating dashboards and reports that the CEO will want to read (one of my favorite topics).

We were talking about different approaches to initial dashboard builds for a CEO, and all the approaches were totally different (and effective with the right kind of person).  One concept was around building all the key data points that any executive would want to see, so that they can easily put together their own dashboard.

Another (not from me, but similar to what we do in the Analyst Program) was around building an initial dashboard after an interview, knowing that it isn’t 100% correct, but also knowing that the recipient would give much better feedback on a deliverable than they would on a concept.

My contribution was on a question I often ask with new clients, or prospects who are looking at a Napkyn analyst as a potential addition to their team.  I call this question “The Elevator Ask”, and it’s just a simple variation of the dreaded elevator pitch.

As I run a young and aggressive business, I get asked for my elevator pitch all the time.  For anyone who hasn’t heard the term before, it works like this:

Image credit: sergis blog via Flickr

Pretend that you are in an elevator with someone who could assist your business.  You have to effectively describe your business and your value proposition before the elevator door opens, or lose an opportunity to get value from this person.

The reason that the elevator pitch is so entrenched in business is because it’s both a fantastic exercise in refining your value proposition as well as a way to ensure that you aren’t wasting anyone’s time when you describe your company.

This approach works equally well with The Elevator Ask in helping figure out what to put on the CEO’s dashboard.

Pretend that you need to rush out of the office, and you are going to be gone for a week.  You jump into the elevator, and all your senior managers happen to be in there with you.  What questions would you ask them to answer before you hit the ground floor?

Sometimes the answers to this question are surprising, and sometimes they prove to be incorrect over time when delivering an ongoing performance report.  Most of the time, however, you are given some great insights that will allow you to do analysis that will be read, valued and used to move the business forward.

Give it a shot, and please share your feedback with us.

Cheers,
Jim

Everything that happens on a website is an event.

We’re in a strange place with this ‘events’ business in web analytics right now. Event tracking is still relatively new and many are only now really discovering them. The events paradigm allows you to track activities that were previously outside the realm of measurement by firing off a JavaScript codes that say, “hey, something happened!”.

This leads us into a bit of misunderstanding. Traditionally, web analytics involved looking at page views. Some page views were boring. Other page views were conversions. Some other page views were somewhere in between, part of a conversion funnel. Web analytics tools became much more relevant when they started tracking ecommerce conversions, so you could see how much money was being made. So far, so good.

Events showed up, in part, to respond to the technological development of the web. Suddenly, important stages of that funnel were no longer page views. With methods like AJAX, some sites suddenly had their entire shopping cart process happen on one page, with each step loading within the page. Page views don’t tell you what happened there, so event tracking came to the rescue in order to track these new “events” alongside your traffic and transactions.

What event tracking highlights is not that there was good tracking and then new technologies broke it. What it shows instead is that the older way of doing things was broken. It tracked only one kind of event: page views. Sometimes, it tracked two: page views and transactions. Good. Not good enough.

Page views are events. Transactions are events. Clicks are events. Chat interactions are events. Searches are events. Customer reviews are events. You get the idea: everything that happens on a website is an event. It’s not that these new event things are an addition to what’s there, it’s that the old way of tracking interaction on a website is incomplete. It forced you into one or two types of event, and ignored the rest.

What Google Analytics, Yahoo! Web Analytics, Adobe SiteCatalyst and other tools are now doing, which needs to be done, is allowing you to determine, as an organization, what kinds of events are happening on your website and which ones are relevant to a conversion.

Everything that happens on a website can be tracked.

At Napkyn, we don’t really do implementations, almost as a rule. Our focus is on helping our clients expand the value of their sites. If we sold developer time, we’d be focused too much on building implementation frameworks and running up project hours, which isn’t valuable. But we do review our clients’ implementations and make our recommendations about what else should be tracked — what data we need to tell them how to grow their online business.

When we make these recommendations to clients, more often than not, the answer is something like, “wow, you can really track that?” Sometimes that sparks a further list of, “what about this, and this, and this?! Can you track these?” The answer to those questions, 95% of the time, is “yes, we can track that.”

Strictly speaking, any user interaction on a website can be tracked. This includes anything that’s clicked on, moused over, spoken with. I say, “strictly speaking”, because the things we can’t track are the little bits that aren’t on the website itself. Obviously, things like whether the planes are on schedule at O’Hare and whether or not it’s raining in Fiji are off-limits for a web analytics tool, unless you happen to be the O’Hare airport or a news outlet in Fiji. Less obviously, things that are contained within iframes (small windows within a site that load in content from another site) as well as some externally-hosted JavaScript applications can’t be tracked by the page they’re on.   This includes some versions of Facebook Like buttons and other social media sharing icons.

Everything that happens on a website should be tracked.

That claim goes beyond my analyst’s desire to have the whole picture, to sift through every bit of data I can to get killer insights. This isn’t a quest to know everything about everyone who browses a website. This is about knowing how valuable each ingredient is. You don’t want useless clutter, but you don’t want to throw out anything good. So, we need data to determine the value of every interactive piece of a website.

So, everything on your site should be worth tracking. The reasoning is simple: If there’s something on your site that’s not worth tracking, it’s not worth having on your site.

Of course, you have to prioritize what tracking you’ll add first. If you’re missing it, the first things you should track are your macro conversions – the ultimate goals of your website: Sales. Lead forms. Donations. This will depend on what your site is about, but you get the idea. This is crucial, and web analytics is next to useless without it.

Next up, track your micro conversions — conversion-related events that drive towards a conversion. An add-to-cart button is a micro conversion. We can argue about semantics, but I count things like newsletter sign-ups as micro conversions. They’re not the goal of the site, but they get you something valuable: permission to market to someone later.

Engagement events are third on my list. Some others, like Avinash Kaushik, count these as micro conversions. This is all semantics, of course, but I like to, at a higher level, differentiate between events that are and are not driving someone towards being a customer. Signing up for marketing emails does that. Adding a product to a cart does that. Clicking a Facebook “Like” button does not. These events may still be valuable and certainly show that the visitor is engaged in your website, but they don’t directly help that visitor become a customer. Other examples include filling out a feedback form or commenting on your blog.

Anything outside of that is noise. External links on your blog? Noise. Social media links that take people away from a product page and towards Facebook, Twitter, etc.? Noise. (Yes: That someone “liked” a product page without leaving it is valuable. That someone left your conversion-focused site to look at your Facebook page is noise.) Should you track noise? Sure! After all, if you can prove that a feature is useless or even hurting conversions, then you have a case to rid yourself of it. On the other hand, you may be surprised by what the data tells you — after all, if intuition were perfect, we analysts wouldn’t have jobs.

You won’t look at all of this at once, and this isn’t data for executives. Executives are already drowning in metrics — this is data that should be at the ready for analysts when hard questions come up. And when the time comes around to make iterative changes or a full redesign, it’s extremely valuable to be able to see what role each component of your website plays in the overall visitor experience, and most importantly, converting traffic into business.

When such a time comes, you’ll be thankful that your web analyst has the data at hand to answer those questions. And if you can get your head out of the traditional page-views–centric approach, you’ll stop worrying about what you can track and start thinking about where your next revenue lift should come from.

Until next time,

Colin

As analysts, we naturally want all of the data, so my first thought was, “OK, how do we track this thing?” As it turns out, Google thought of that as well. When you’re creating your +1 button, there’s an Advanced Options area which lets you customize the button. One of those options is to reference a callback function — JavaScript code that will execute when a +1 event happens. This is the perfect place for a little Google Analytics event tracking.

The code you get from Google will look something like this:

The first part, the <script> tag, doesn’t need to change and will need to be put in your header no matter what. What will change is the second part, the <g:plusone> tags. If you choose to add a callback function, it’ll look something like this:

In this example, I added a callback named track_plusone. This is a reference to a JavaScript function called “track_plusone” that will need to be defined on the page as well.  Here’s the code for my initial function:

What this function does is fires a Google Analytics event tracking code. It sets the category of that event to “Social Shares”, the action to “Google +1 Vote” and the label to the URL of the page the button was clicked on. You can change the category and action to suit your own conventions, of course. The page is technically available in the new GA interface, where you can view events by page as well.   The result is an event that shows up in Google Analytics whenever an item is voted for. Events take anywhere from one to 24 hours to show up, and appear within the Content > Events area of the Google Analytics user interface.

There’s one other feature we need to account for. Not only can visitors click the button to +1 vote for a page, but they can click it again to undo their vote — effectively giving you a -1 vote. We’ll need to be able to distinguish between initial +1 votes and -1 vote “undo” events. So, here’s a revised version of the function, which gives you two kinds of event actions: “Google +1 Vote” and “Google -1 Vote (Undo +1)”. Again, you change those details to match your conventions.

[ Update: Google has also indicated that they will be adding some +1 reports of their own into Google Analytics, so these features will be integrated. You may prefer to do it that way, but one of the reasons we're using this code is that it allows our "social shares" events to be grouped and roll up into one category. At a glance, we can see how many shares happened on the site, and then drill down to see which services they came from. It's all about getting the right structure you want for the way you look at your site's features. ]

[ Update 2: Google has now unveiled its new reports for tracking social media interactions. The integrated +1 tracking is now combined with a new version of the event tracking code that's specific to social media. I added a post on tracking Facebook Like buttons using Google Analytics social tracking to showcase the new code, but the +1 buttons have this feature automatically, so strictly speaking, you don't need to add this yourself anymore. We still use this code to show these alongside our existing events for social tracking, at least until we get more data from the new method and phase the event tracking version out. ]

This kind of tracking lets your web analyst answer questions about the value of these Google +1 buttons, and the voters who use them. Are people who +1 vote for products the same people who purchase them? Do those people tend to come from social media themselves?

Social media is notoriously tough to track, so answering questions like this can be very useful to understanding what exactly you gain by adding these buttons to your site. Are they worth it? Let the data tell you.

Until next time,

Colin