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.

We’re well into 2011 and coming up to the end of the fiscal year for many businesses. With pressure to plan out the next 12 months in order to continually grow, many of our clients are looking to refresh or relaunch their websites. (We’re looking at doing the same ourselves–we’re doing some cool new things that we’d like to brag about!)

As web analysts, we’ll be the first to tell you that updating a site’s design won’t immediately equal performance improvement. Without planning, it can easily go either way: a relaunch can offer major improvement to your revenue performance, but it can also kill your traffic, and even with an amazing conversion rate, fewer visitors means fewer visitors to convert.

So, here’s the checklist:

1. Look at the data

Obviously, as web analysts, this is near and dear to us at Napkyn. But it’s something every business should do when making changes to their marketing efforts. You essentially have two options when deciding what sorts of changes you make to your website. You can:

1. guess, or
2. know.

If you guess, you could throw out the best-converting pieces of your website. Worst case scenario: your business fails entirely. Looking at your current data will let you know which parts of your site are working, and which aren’t. Worst case scenario: You do as well as you did before.

Everybody wants a sexy brand and that’s not a bad thing, but good design is not success. I’ve seen beautiful sites fail and ugly sites make millions. At the end of the day, you probably want changes that make you more money. Look at your data to get insights on what works well for your business and compare it to others’ data and best practices to get a sense for what has worked before.

Of course, not everyone has a head for this stuff, so if you’re not sure about how to move from guess to know, we can help with that.

2. Manage your URLs

Next up, a tactical tip. If at all possible, try to minimize the changes to your URL structure. Keep in mind that search engines don’t index websites, but rather web pages — and they do this by the URL. Every URL that you remove from your site is a page lost from Google’s index. Chances are good that you remember from when you first set up your website, getting good rankings can take a while. You don’t want to risk having to start over. The number one cause of lost traffic after a site relaunch is almost always a drop in search traffic.

There are some cases where keeping your URL structure is not possible. This can happen because you change content management systems or ecommerce software vendors, and the old structure simply isn’t possible in the new software. Many good systems allow you to set the rules for how URLs are generated, but sometimes this isn’t available. Fair enough.

If your redirects look like this, you’re doing it wrong. Go for a seamless HTTP 301 redirect.

What you’ll need to do is make sure that every URL on your site still goes somewhere. The best way to do this is with an HTTP redirect — specifically, using the HTTP 301 “Moved Permanently” code. This is a message that is sent by your server to a browser, search engine or any other device that visits your site, and tells them that a page moved, and where it went. Other methods, such as meta refreshes and other HTTP redirects are not as effective in keeping search engine listings, so be sure to use this one whenever possible.

If at all possible, configure your server with a listing of all of your old URLs and their new locations. That way, specific product listings, articles or other pages aren’t lost. If you’re raking well in Google for selling blue widgets, don’t redirect your old blue widgets page to your homepage — point it to your new blue widgets page. This will make sure that your search rankings, incoming links, shopping feed listings and bookmarks are all preserved, and will help potential customers find what they’re looking for.

A new website almost always means a change in search traffic. This will help you minimize the risk of a natural search free-fall.

3. Keep your customers in the loop

If your business has tends to bring customers back for more, or you have prominent customer login or customer service  areas of your site, you want to be sure that you don’t alienate them with your new changes.

In customer service areas, inform customers early that the site will be re-launching soon. If you rely on customer involvement with your site, pull a Twitter and let them test the new interface with an option to switch back for now. If that’s not a viable option, provide linked messages to customers like this: “Looking for your order history? Our new site files orders right in your user profile.”

This is relevant to my next point, preparing to measure the results. An increase in page views (relative to visits) isn’t always a good thing when you relaunch a site. Often it’s a sign of existing customers or visitors familiar with your site who get lost in your site. Visitors who are already familiar with your site may be looking for something in particular, and if it’s moved, they can become frustrated.

4. Get ready to measure the switch

If you followed item #1, then you’re making these changes for a reason. Don’t forget to close the loop, either — you need to define the metrics that will determine whether or not this change was a good one. How will you know that you’ve won? Make sure that you’re prepared to handle, and try to make predictions about how the flow of traffic.

Then, once your new site has been online for a while, you’ll be able to compare the data against the plan, and learn whether or not the changes you made had the intended impact.

The technical side to this involves making sure that you actually can measure the change with some confidence. If you’re making significant changes to the deployment of your web analytcs tool, you’ll want to be sure that you’re not comparing apples to oranges with this change. If you’re switching tools, try running them concurrently for a time to be sure that they’re on the same page.

5. Develop a testing plan

Even the brightest marketing minds don’t get everything right the first time. Your new website may be miles ahead of your old one, but without data on its performance it’s tough to be certain how it will fare. So, once your new site is launched, you’re not done.

When measuring the switch (item 4 on our checklist), you’ll probably notice a few areas that don’t do quite as well as they did before, or didn’t improve as much as the rest of the site. These may be individual products or product categories that perform differently, or specific traffic sources that react differently to your site.

Identifying the less-successful areas of your redesign early gives you an opportunity to ensure that you continue to make the proper revisions. Start testing areas of your redesign by using A/B or multivariate testing tools. If you had two competing layouts for a new page on your site, test both! Sometimes the results will confirm your intuition, other times they will surprise you.

6. Think of everything

Easier said than done to be sure, so that’s a joke. But if you’re tracking your business through high-level metrics, you’re better equipped to understand where major changes fit in and how to avoid missteps. As web analysts, our job is to make the big numbers bigger, so when you’re clear about high-level business performance, the tactical stuff falls into place.

This list isn’t exhaustive, but following these guidelines can help you make informed decisions around your relaunch, and prevent you from throwing out the things that work.

But, talk has been growing over the past year about the future of this utopia we’re all building together — or at least, its business future. The analysts say the tides may be turning yet again: that Web 2.0 is forming a bulge of a bubble that’s about to burst at the seams.

And they’re probably right. If you look around, it’s pretty obvious that there’s a lot of noise going on. Of course, we’ve had Facebook, YouTube, MySpace, Digg, Flickr and the great big blogosphere for a while now. But every day it seems I’m learning about some new Web 2.0 app and how it’s the best thing for me since sliced turkey. There are way too many social media sites out there, and I’m afraid that sitting in the middle of this with my Web Marketer and Web Developer hats on has gotten me awfully dizzy.

And while wearing those hats — yes, I wear actual hats — I’m often browsing freelancer sites looking for fun and exciting projects to work on. Without fail, there are daily postings from investors looking to build the next MySpace, Digg or i-silver-bullet. If not, they at least want a new Facebook app that will create the viral marketing their business always needed to get off the ground.

After the 2000 dot-com burst, this kind of if you build it they will come smack in the face of rationality came to a grinding halt, and the executives who didn’t smarten up were politely asked to die in a hole somewhere. Now, it seems like the coffers are opening up again to buy a piece of Web 2.0 pie.

Of course so many “Web 2.0″ companies are living off of traffic and ad revenue alone — but what about those using the Web to sell something tangible? My friends over at Sitebrand paint a brighter picture for those involved in online retail, where the Web may actually be the safer bet as the U.S. economy slows down.

Meanwhile, the clients I work with have all increased their online marketing spending over the past year or two — but every single one of them has become obsessed with their web metrics. Conversion rates, cost-per-lead and ROI are on the tops of their minds, and rightly so.

So it seems that at least some people have learned from the first dot-com burst, which is great because they’ll need to use that kind of sense again to search for new marketing tactics when the bubble bursts and Internet users worldwide simultaneously fall into comas.

I guess what I’m trying to say in all of this is “smarten up, Internet”, because if everything goes to hell again the Web won’t be any more fun and I’ll have to get a new job.