Augustine says that the actions of infants are “reprehensible” (8), the way they cry loudly for nourishment, constantly demanding the attention of their mother. Infants become intolerant of others, their parents and strangers, who do not obey them, often lashing out “with sheer will to hurt” (9). They also complain and demand things that aren’t even in their best interests. Augustine remarks that such actions would not be tolerated of an adult; in fact, an adult behaving in such an infantile manner would rightfully be the subject of scorn and ridicule. One cannot blame infants for the way they cry, of course, since they do not know what is wrong with their behaviour. However, Augustine says that such behaviour is clearly wrong, for as the child grows up there is an attempt to put an end to such behaviour, creating a more calm and polite child. Were it correct, it would be allowed to continue as the child matures.

Because of this clear wrongdoing on the part of infants, Augustine wonders why it is that infants are thought to have innocence. He concludes that it must not be anything having to do with the mind of an infant, since as has been shown, infants are not in possession of finer human qualities like humility and patience. Quite to the contrary, infants are selfish, impatient and impolite, and thus can rightfully be labelled as sinners. Instead, Augustine says, they must be innocent only in the sense that they are helpless.

He goes on to provide further evidence that the state of the infant’s mind is sinful, by means of demonstrating infant jealousy. He says that he has seen a case of a baby who was watching another feeding at a breast. The child who was watching was “livid with anger” (9), despite being too young to even speak. This jealousy shows an unwillingness to share readily-available milk with a child that will not survive without it, though the child likely doesn’t understand this. Still, this shows that infants can be guilty of jealousy and of gluttony. For Augustine, referring to infants as innocence seems to refer to “an odd kind of innocence” (9).

On this account, infants get away with their behaviour and allowed to act in the manner they do not because their behaviour is correct or sinless, but because it “will pass with the years” (9). Adults only allow infants their sins because they are short-lived.

So how about that? Normally we think that infants are innocent because of their ignorance — though ignorance doesn’t count as a defense later in life.

It turns out, they’re just awful.

The proper naturalist position counts the mind as part of the world, as McDowell wants to do. What a naturalist proper cannot coherently talk about is the Kantian subject. Instead, there are only objects. For those who would say that things are only objects in the sense that they are the object of some subject, then we may use the word ‘substance’, in the earlier Greek sense, to talk about physical things. Thus, the naturalist position is that everything is a substance; in Heidegger’s terminology, everything is essentially present-at-hand[1] and though further supposed properties or features of substances (readiness-to-hand, the existence of Dasein, the mind, intentionality, subjectivity) are reducible to that raw substance. In contemporary physics, that substance is identified with particles, though the details may be somewhat more complex than that[2]. The manifest image of the world[3], the normative space in which intentionality and morality are thought to lie, is composed of that same physical substance that makes up the brains of those who experience and project outwards.

So, for the naturalist proper, the space of reasons is not a realm outside of the natural or physical world, as it is in rampant platonism, nor is it an autonomous space within the world as it is in McDowell’s naturalized platonism. Rather, all rationality, normativity and intentionality is identical with brain states. There is no one space of reasons with which human beings have a connection; rather, each human being can be thought to have their own space of reasons. This space is not especially private, though. It can be seen physically by examination of the neurological states of the brain, and with the proper technology, those states may even be translatable into intelligible images. In another sense, it is not fully private, since glimpses into its content can be seen through behaviour.

‘Content’ needs qualification in that last remark. Intentional mental states are mental states that are about something else in the world. But they are neither a metaphysical link through some imaginary (or real) space to other substances which they are about, nor are they really representations of the substances they seem to be about. They are not the former because such space doesn’t exist in any important way. They are not the latter because, of course, the neurological features of our brain do not form a structure that mimics the outside world. Rather, they form a structure that allows us to have a mental state (which is identical with that brain state) such that we think we have a representation of the substance we are thinking about. So, when I close my eyes and picture the CN Tower, I do not obtain or summon some representation of that object. That object may be gone, moved, or different than I remember. Instead, my brain generates a certain arrangement such that it looks like the CN Tower to itself.[4] All of the qualia, ‘what it’s like to be’[5] and private world phenomena that philosophers expect to find in a separate mental world are  merely what the brain’s activity looks like from the point of view of that very brain.

Against the rampant platonist, the naturalist’s response is brief. Whatever attitudes one has towards the empirical observations with which one is presented, one does not survive without indulging in them. With a proper account of naturalism, any reason to favour a platonic account dissolves. Naturalism proper offers an explanation of intentionality, removes the “spookiness” (McDowell 92) of a separate space of reasons that McDowell complains of. We don’t need to add anything ontologically, and we have a hope to answer the how questions about mental states and intentionality through study of the brain. Spontaneity doesn’t need any explanation here, either, because it is not sui generis, if it’s counted as existing at all. We’re better off with the naturalist account.

Against McDowell’s naturalized platonism, the proper naturalist has to say that McDowell is wrong about naturalism. He argues against his ‘bald naturalist’, saying that “knowing one’s way around the space of reasons, the idea of responsiveness to rational relationships, cannot be reconstructed out of materials that are naturalistic” (McDowell 77). But the naturalist proper doesn’t want to reconstruct a space of reasons, really. The naturalist proper holds that all reasoning, all intentionality, all communication—the entire manifest image—takes place between physical substances across physical substances. The naturalist isn’t committed to reconstructing any intentional state beyond this because she doesn’t hold it to exist. What counts as intentionality for a naturalist proper is evidenced through behaviour, and it consists of a brain processing incoming information. The space of reasons, the finer points of language, art, morality, knowledge and so forth can be talked about as abstractions. They are useful in the processing that the brain must do; they result in digestible inputs. But the naturalist proper is ever-mindful that these are not things in themselves, but that they are always identical with and reducible to the states of the brain. The same holds of spontaneity. The naturalist counts human judgments to be determined (in a deterministic or indeterministic sense[6]) by the physical processes that cause them. Thus, spontaneity can be said either to not really exist, or at least to be denied status as sui generis, as is the case with the other ideas McDowell wants to preserve. Where McDowell wants to say that human beings are free to choose their beliefs, to take their experiences and spontaneously form judgments about them, the proper naturalist denies this. For the naturalist proper, sometimes brain states will have the disposition to respond to the stimulus of a red bench and form the belief that there is a red bench. Sometimes, because of other beliefs, brain states will not have such a disposition and will not form such a belief. Whether or not this happens is not an act of spontaneity, but a function of the states of the brain, including the stimulus received and the beliefs already held.

By positing an autonomous space of reasons, and a second nature with which humans can access it, the naturalized platonist gains little in the way of explanation and much in the way of recalcitrant philosophical questions. McDowell thinks that he gets out of the “threat of supernaturalism” (78) by saying that scientific advancements don’t clarify nature as a whole, but only the realm of law. This step does not work; it only redefines “nature” to include what the naturalist counts as supernatural. McDowell renames nature as the realm of law, says that the platonic heaven, the space of reasons, also exist, and says that there’s this new thing, now called nature, previously called existence, which encompasses all of them. The connection between the realms of laws and reasons is as sketchy as ever, and it is only through proper naturalism of intentionality and spontaneity that the confusion is finally dissolved.

⊨(P → Q) ∨ (Q → R)

Try throwing that into English. Here’s a reading using some propositions I just came up with:

“I’ll die if I’m immortal, or I’ll live if I die.”

Obviously, neither of those are the case. But this formula, (P → Q) ∨ (Q → R), is both provable and self-implied in classical propositional logic.

Here’s a syntactic proof by means of natural deduction using some basic rules of inference:

Ok, there are definitely shorter proofs, especially if you let other equivalencies into your rules of inference, but this spells out quite a bit and gets the job done.

So, ⊢ (P → Q) ∨ (Q → R)

The reason this is provable, despite being formally contingent in English, is that the material conditional, →, does not represent the English “if/then”. If you’ve taken a course in logic, you’ve probably heard this. The reason is that the truth conditions for the material conditional are a little different. Specifically, a formula of the form (α → β) is true on every valuation except those that make α true and β false.

Look at our formula again. It states, semantically, that either (P → Q) is true, or (Q → R) is. If (P → Q) happens to be true, then the whole formula is true, so that case is covered right off the bat.

If (P → Q) is false? Well, there’s only one valuation that makes (P → Q) false — the valuation where P is true, and Q is false. So, if (P → Q) is false, then Q is false as well. But, if Q is false, then (Q → R) is true, because (Q → R) can only be false when Q is true and R is false. If Q is false, then (Q → R) is true.

Going the other way, if (Q → R) is false, then Q is true and (P → Q) can’t be false, because it can only be false if Q is false.

As a result, whenever (P → Q) is false, (Q → R) is guaranteed to be true, and vice versa. So, (P → Q) ∨ (Q → R) is a tautology.

My point here is just a friendly reminder: be careful with translation. Expressing the English “if/then” with the material conditional (→) may sometimes get you into trouble.

This objection has probably been made before, but for the sake of my notes I’m spelling it out as I read it.

In the paper, Sellars runs through a set of three propositions that he believes that sense-datum theorists must hold, but that Sellars believes is inconsistent.

A. X senses red sense content s entails x non-inferentially knows that s is red.

B. The ability to sense sense contents is unacquired.

C. The ability to know facts of the form x is Φ is acquired.

Sellars then states that “A and B together entail not-C; B and C entail not-A; A and C entail not-B” (132).

However, I think he makes a crucial misstep in his formulation here. Namely, in C Sellars refers to a fact, that knowledge “of the form x is Φ is acquired”, but I do not believe that what is stated in A truly takes this form.

On my reading of A, when we say that x non-inferentially knows that s is red, we are not saying that x knows the fact “s is red“. It may entirely be the case that x is unable to form the sentence “s is red”. Suppose that x has been living in Mary’s Room and is experiencing red for the first time — x would not be able to know that what x sees is red. Hence, x does not have knowledge of the form x is Φ  in the sense that x can categorize his or her sense perception. But x still has some knowledge from this experience, and for the sense-datum theorist this is a recollection of that given sense data.

The difference here is a logical distinction between a de re and a de dicto formation. These two Latin phrases basically mean “of the thing” and “of what is said”. Symbolically, we can represent “x knows that” as K_x. We can also symbolize “α is red” as R(α).

Now, in the case of A, we have the claim that X senses red sense content s entails K_xR(s). This is a de re claim — what x knows is that, of s, that object is of a certain colour, which we call red. The claim is that x knows that s has some property. We can argue a bit over whether this must be knowledge by acquaintance in the sense that Sellars talks about in this paper, but the idea here is that this is not knowledge of a fact, but rather the knowledge you would acquire whether or not you knew of the category “red” to begin with.

However, in C, we have the claim that knowing facts of the form K_x[Φ(α)]. This form translates in our example to K_x[R(s)]. This is the de dicto claim — what x knows here isn’t that s is red, but the sentence “s is red”.

So, the sense-datum theorist can simply agree that knowledge of de dicto facts in this form are acquired, but deny that A includes such a fact, since what is known can be expressed as a de re claim. Hence, the triad of propositions that Sellars attributes to the sense-data theorist is not inconsistent.

Cited:
Sellars, Wilfrid. “Empiricism and the Philosophy of Mind”. Science, Perception and Reality. London: Routledge & Kegan Paul, 1963. pp. 127-164.

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

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

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

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.