Web Analytics Tracking on a Facebook Page

I’ve been on a quest now for several months to crack the code of how to get web analytics tracking on a Facebook fan page. My (and our clients’) desire to do so shines an interesting light on the way that social media has blurred the concept of a “web site.” Back in the day, it was pretty simple to identify what pages you wanted to track: if the user perceived the page as being part of your site, you wanted to track that page with your web analytics software (even if it was an area of your site that was hosted by some other third party that had specialized capabilities like managing job opening, events, or discussion forums).

Social media, and Facebook in particular, is starting to blur those lines. If your company manages a branded fan page on Facebook, and that page is a place through which your customers and target customers actively engage with the brand, isn’t it acting a bit like your web site? Clearly, a Facebook page is not part of your site, but it’s a place on the web where consumers actively engage with brands, both to give and receive brand-related content. It acts a lot like a traditional web site in that regard.

As companies begin to invest more heavily in Facebook pages — both through creative development and staff to engage with consumers who interact with their brand through a fan page — there is an increasing need to have better visibility into activity on those pages. I wrote an entire post on the subject of Facebook measurement back in January, and I’ve had to update it several times since then as Facebook has rolled out changes and as I’ve gotten a bit deeper into the web analytics aspects of that tracking.

Just last week, Webtrends announced some damn slick enhancements to Analytics 9 that allow not only tracking well beyond what Facebook Insights offers, but that also brings in some specific (anonymous) user information so that the traffic can be segmented in useful ways (the post on mashable.com shows some screen captures of the resulting data). I fully expect that Omniture will come out with something comparable as soon as they can, but I don’t think they have that level of tracking yet (if you know differently, please leave a comment to let me know). [Update: Coremetrics announced some new Facebook tracking capabilities shortly after this post was published.]. My one concern with the Webtrends solution is that, as best as I can tell, it requires the tracked pages to use a Facebook application that will pop up an “Allow Access?” question to the user — the user has to indicate this is okay before getting to the content on the page. Lots of applications have this, but, at Resource Interactive, we’ve also had lots of clients for whom we have built very rich and interactive experiences on their fan pages…without requiring anything of the sort. If the access is needed to enable the application to deliver value to the user, then this is fine, and the improved trackability is just scrumptious gravy that comes along for the ride. If the access is needed just for tracking, then I would have to think long and hard about it — data capture should always be between somewhere between excruciatingly minimally visible to the user and not visible at all.

The question, then, is, “What can be tracked unobtrusively, and how can it be done?” This post will attempt to answer that question.

Why Is It So Tricky in the First Place?

Facebook, largely for privacy reasons, locks down what can happen on its pages. It may make your head hurt (it certainly makes mine) to understand all of the cans vs. cannots for different scenarios, but I’ll take a crack at a short list. There are two basic scenarios that a customer might experience as a “tab on a brand’s page:”

• The brand can add a tab to the page and drop some form of Facebook application into it; in this scenario, iFrames are not allowed, and Javascript cannot be executed
• The brand can make a separate application, and, on the “application canvas,” they can drop an iFrame, and Javascript can be executed within that iFrame; but, since the application canvas cannot exist “in a tab,” the design for the page has to include tabs to mimic the fan page, which is a bit clunky and raises some other user experience challenges

Okay, so that was easy enough…assuming you’re following the custom tab / application / application canvas terminology. Both of these scenarios allow the embedding of Flash objects on the page.

Facebook doesn’t allow Javascript, but it does allow it’s own similar scripting language, called FBJS (these tabs also use “FBML” rather than HTML for developing the page — it’s similar to HTML but not identical).

What all of this means is that it’s not as simple as “just drop your web analytics page tag on the page” and you’ll get tracking. But that doesn’t mean you’re entirely SOL. This post is almost entirely geared towards custom Facebook tabs — and, really, it assumes that the content on those pages are based on an FBML application.

Tracking Basic Visits and Page Views for a Custom Tab?

We’ve cracked this to varying degrees for two different web analytics tools: Google Analytics and Webtrends. We haven’t had a pressing need to tackle it for anything else, but I’m pretty sure the same principles will apply and we’ll be able to make it happen. In both cases, the approach is pretty much the same — you need to have the FBML and FBJS on the page make an image call to the web analytics program. To pull it off, you do need to have a good understanding of how web analytics tools collect data, which I wrote an extensive post about a few days ago.

In the case of Webtrends, the simplest thing to do is treat the page like a page where every visitor who comes has Javascript disabled in their browser. I’ll cover that later in this post.

For Google Analytics, things are a little dicier because Google Analytics doesn’t have out-of-the-box “noscript” capabilities. You have to figure out all of the appropriate parameter values and then just make a full image call (again, reference the link above for a detailed explanation of what that means). You’re not going to get all of the data that you would get from running the standard page tag (which I’ll touch on a bit more later in this post), but you can certainly get page views and unique page views with a little FBJS work.

Start out by creating a new Google Analytics UA number for your Facebook tracking. This will give you a profile with a new ID of the form: UA-XXXXX-YY. You will have to provide a domain name, but what that domain name is is immaterial — “<brand>.facebook.com” makes sense, but it can really anything you want.

Then, it’s just a matter of figuring out the list of values that you are going to tack on as parameters to the Google Analytics image call (http://www.google-analytics.com/__utm.gif). Below are some tips on that front (refer to the Google Analytics documentation for a deeper explanation of what each parameter is), with the bolded ones being the ones that I’ll discuss in greater detail:

• utmwv: 4.6.5 (or a newer version — I don’t think it’s critical)
• utmn: needs to be a random number between 100000000 and 999999999 (more on this in a bit)
• utmhn:  <brand>.facebook.com (or something else — again, not critical)
• utmcs: leave blank
• utmsr: leave blank
• utmsc: leave blank
• utmul: leave blank
• utmje: leave blank
• utmfl: leave blank
• utmdt:  the title of the page (whatever you want to call it)
• utmhid: leave blank
• utmr: leave blank
• utmp: a “URL” for the page
• utmac: the Google Analytics ID you set up (UA-XXXXX-YY)
• utmcc: __utma%3D1.<session-persistent ID>.1252000967.1252000968.1252000969.1%3B

This is as simple as it gets. Obviously, all of the “leave blanks,” as well as the limited number of “cookie values” being passed, mean that you’re not going to get nearly as rich information for the visitors to this tab (you should be able to just eliminate the “leave blank” parameters entirely from the image call. You will get page views and unique page views, and you can set up goals and funnels across tabs if you want. You can also start getting a little fancier and inserting campaign tracking parameters and other information, but start here and get the basics working first — you can always augment later (and please come back and comment here with what you figure out!).

For the four bolded parameters in the list above, two are ones that you will predefine for the tab itself — they’re essentially static — and two are ones that will require a little FBJS magic to make happen.

Let’s start with the two static ones:

• utmdt: this is normally the <title> tag for the page that is being visited; you can make it any plain English set of text you want, but you need to replace spaces and other special characters with the appropriate URL encoding
• utmp: this is the URL for the page; you certainly can navigate to the custom tab in Facebook and use that, but I suggest just making it a faux URL, similar to how you would name a virtual pageview when doing onclick tracking; again, you will need to make this an appropriately URL encoded value (that mainly means replacing each “/” in the URL you come up with with “%2F”)

The two other values require a little more doing, although it’s apparently pretty straightforward with FBJS (if you’re not a Javascript / FBJS jockey, as I’m not, you may need to track down a willing collaborator who is):

• utmn: the sole purpose of this value is to make the overall GIF request a “new” URL; it’s a random (or, at least, quasi-random) number between 100000000 and 999999999 that should change every time there is a new load of the page
• utmcc: the main thing you want to do here is generate a value between 1000000000000000000 and 9999999999999999999 that will stay with the visitor throughout his visit to Facebook. The other values in the __utma subparameter of utmcc are various date-stamps; if you want to get fancy, you can try to populate some of those as well; overall, utmcc is supposed to be a set of cookie values that persists on the user’s machine — we’re not actually dropping a cookie here, which means we’re not going to be able to track any of the sorts of “lifetime unique visitors”-dependent measures within Google Analytics (that includes “new vs. returning” visitors — everyone’s going to look like a new visitor in your reporting)

Make sense? I built a spreadsheet that would concatenate values I’d populated for these variables which just isn’t pretty enough to share. But, you just need to tack all of these values together as I described in my my last post and drop that as an image call on your custom tab.

This won’t work for every tab — you can’t do it on your wall or your Info tab or other pre-defined, unformattable tabs, but if you create a new tab and drop an FBML application in it, you can go nuts with this.

[Update: At almost the exact same time that this post went live, an e-mail hit my inbox with a link to a Google Analytics on Facebook post that I failed to turn up during my research (the post is only a week old, and most of my research happened prior to that). This post includes a handy link generator which looks really promising and helpful.]

Tracking Actions within a Tab

Now, suppose you’ve got your custom tab, and you’ve got tracking to the tab working well. But, you’ve dropped some Flash objects on the tab, and you want to track interactions within Flash. You’ve got two options here:

• Just use the Actionscript API for Google Analytics — as I understand it, this works fine; I’ve also heard, though, that this adds undue weight to the app (35 KB), and that it’s not super-reliable; but, if you or your Flash developer is already familiar with and using this approach, then knock yourself out
• Manually generate image calls for each action you want to track — this really just means follow the exact same steps as listed in the prior section, but use Actionscript rather than FBJS for the dynamically generated pieces

Because I work with motivated developers, we went the latter route and built a portable Actionscript class to do the heavy lifting.

Presumably, you can also use FBJS to track non-Flash actions as well, depending on what makes sense.

What About Webtrends?

The same principles described above apply for Webtrends. But, Webtrends has an out-of-the-box “<noscript>” solution, so, rather than reverse-engineering the dcs.gif, you can use a call to njs.gif:

http://statse.webtrendslive.com/<your DCS ID>/njs.gif?dcsuri=/<virtual URL for the page>&WT.ti=<name for the page>

(I did confirm that you can leave off the WT.js parameter that is listed in the Webtrends documentation for using njs.gif).

It also seems like it would make sense to tack on a random number in a parameter at the end (such as “&amp;nocache=<random number>”) just to reduce the risk of caching of the image request (similar to what’s described for the utmn parameter for Google Analytics above). I haven’t even asked for confirmation that that would be useful, but it seems like it would make sense, and it’s just a parameter that Webtrends will ignore in the processing.

Chances are, you’ll want to set up a new profile in Webtrends that only includes this Facebook traffic (see my opening ramble about Facebook pages being quasi-web sites), and you’ll probably want to filter this traffic out of your various existing profiles. That may mean you need to think about how you are naming your pages to make for some easy Include and Exclude filter creation.

(Oh, yeah, and the “statse.webtrendslive.com” assumes you’re using Webtrends Ondemand — if you’re running Webtrends software, you’ll need to replace this with the appropriate domain.)

As you’ve probably deduced by now, we haven’t really vetted our “njs.gif” usage…yet, but we’ve gotten a lot of head nods from within Webtrends that this should work. I’ll update this post once I’ve got confirmation, but I wanted to go ahead and get the information published so that someone else can run with it and maybe figure it out in more detail and let me know!

Webtrends also, apparently, allows Actionscript to interact with the Webtrends REST API directly, which, allegedly, is an option for action tracking within Flash on Facebook pages. We haven’t confirmed that, and, in what little looking I did on http://developer.webtrends.com, I didn’t turn up any particularly useful documentation, so either that’s not widely in use, or I’m a lousy user of their search function.

It’s Not as Tough as It Looks…but It’s Not Perfect

This may seem a little overwhelming, but the mechanics are really pretty straightforward once you dive in and start playing with it.

To test your work, you don’t need to actually code up anything — just set up your new profiles (Google Analytics or Webtrends) build up some image request strings, and start hitting them. You can manually swap out the “dynamic” values — even have some friends or co-workers hit the URLs as well. To introduce a bit of rigor, it’s worth tracking the specific image requests you’re using, how many times you hit them and from what browser. That way you can compare the results in your web analytics tool to see if you’re getting what you’d expect. Then you can move on to actually getting the calls dropped into a Facebook page.

Realize, too, that this whole process is a dumbing down of what normally happens when Javascript or Actionscript is used to tell your web analytics tool that someone has visited the page. Your new vs. returning traffic is going to be inaccurately skewed heavily towards “new.” You’re not going to get browser or OS details (much less whether Javascript is enabled or not). But, you will get basic page views and visits/unique pageviews, and that’s something! You’re stepping back into the Bronze Age of web analytics, basically, but that’s better than the Stone Age, and you’re doing it within social media!

I suspect that you can get a little fancier with FBJS and start to get more robust measurement. As a taste of that, we actually got some tracking working on users’ walls in Facebook, which was both wicked and rad (as the cool kids in the 80s would have said):

• We posted a status update that was, basically, an invitation to click into a Flash object; if the user clicked into it, then a Flash-based box expanded on their wall, and Google Analytics would be passed an image call to record a page view for the activity
• We also passed in a “utmv” value, which we then used to set up segments within Google Analytics — the idea being that, each time we do one of these status updates will be a separate “campaign,” but our campaign tracking will be through custom segments within Google Analytics — that will enable all of our reporting, including the conversion funnels we set up, to be set up once and then re-used through Google Analytics segmentation

Neat, huh? Or, as we’d say in the rural Texas town where I grew up, it’s slicker than greased baby poop. This is giving us highly actionable data — enabling us to see how people are interacting with these experiences through Facebook and enabling us to try different approaches to improve conversion over time! (To be clear, we’re not capturing personally identifiable Facebook information — exactly who is interacting is still invisible to us, which is as it should be).

Fun stuff. If you’ve given anything along these lines a try (or if you’ve successfully taken a totally different tack), please leave a comment — I’d love to get other options added!