I’m worried that many of you will be disappointed with this blog post. Why? In the past, I’ve tried to tackle the really complex implementation issues and questions that you might not have seen anywhere else. Some of them have been beyond hairy, fraught with gotchas and caveats and warnings galore.

This one? Not so much. Like it or not, if you’ve had experience implementing SiteCatalyst on your own web site, implementing on a Facebook app using Omniture’s new app measurement solution is straightforward and familiar.

I will give you one notice before I go any further: The only Facebook app I’ve ever built is a simple proof-of-concept to help me understand the solution described below; your apps are likely far more complex, and you may have very specific needs or challenges that go beyond what is described below. Omniture Consulting is prepared to help you understand how best to generate uplift based on your specific Facebook strategies and app structures, but hopefully the information below is enough to get you started.

The way apps work is this: You build and host a small “site” which interfaces with Facebook via an API that has been established and a shared key that is tied to a Facebook account. Facebook serves up your app by using the API to send and receive data from the “site” (i.e, app) that you have built.

What this means is that all of the same rules apply to Facebook app implementation. When you set up your app, Facebook gives you a very simple, “Hello World”-esque PHP script that you can use as your first “page.” I’ve included it below and added how you might implement SiteCatalyst on this page using the new Facebook app measurement tool.

<?php
require_once 'facebook.php';
$appapikey = '93a9c39988cb7XXXXXXXXXXXXXXXX';
$appsecret = 'ec3954276b34c4b4XXXXXXXXXXXXXX';
$facebook = new Facebook($appapikey, $appsecret);
$user_id = $facebook->require_login();

?>

<html>
<head>
<title>Test App</title>
</head>
<body>
<?php
// Greet the currently logged-in user!
echo "<p>Hello, <fb:name uid=\"$user_id\" useyou=\"false\" />!</p>";


// Print out at most 25 of the logged-in user's friends,
// using the friends.get API method
echo "<p>Friends:";
$friends = $facebook->api_client->friends_get();
$friends = array_slice($friends, 0, 25);
foreach ($friends as $friend) {
echo "<br>$friend";
}
echo "</p>";
?>
<!-- SiteCatalyst code version: FBJS-1.0.
Copyright 1997-2009 Omniture, Inc. More info available at
http://www.omniture.com -->
<script src="s_code_fb.js"></script>
<script><!--
/* You may give each page an identifying name, server, and channel on
the next lines. */
s.pageName="Test App:Home"
s.channel="Home"
s.prop1="<?=$user_id?>"
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
s.t();//--></script><!--/DO NOT REMOVE/-->
<!-- End SiteCatalyst code version: FBJS-1.0. -->
</body>
</html>

I would also need to have the s_code_fb.js core JavaScript file hosted on a server in my control.

All we’re passing into SiteCatalyst in this example is the page name, the channel (site section), and the logged-in user’s ID (not name or username, but a numerical ID; this is very important for privacy purposes). However, you can populate any of the variables belonging to the Omniture Suite—eVars, props, products, events, etc. It really is a full-featured solution for measuring interaction with your Facebook apps just as you would measure interaction with your own web site! Also, note that Facebook’s API makes available quite a bit of useful information about those who interact with your app, making it easy to capture demographic and other data about your user base.

Of course, your app is likely comprised of multiple “pages.” You’ll be able to get pathing data as users navigate your app, and you can fire custom events as they perform whatever actions constitute a measurable aspect of conversion or interaction, according to your needs.

There are, actually, a few things to be aware of when implementing this solution:

  • Facebook app usage data probably should not be intermingled with usage data from your web site. After all, a “visit” to your app does not constitute a visit to your site. Therefore, I recommend using a separate report suite for Facebook app measurement.
  • Some Omniture JavaScript plug-ins will work with a Facebook app implementation, but not all. There are some key differences between FBJS (Facebook JavaScript) and conventional JavaScript that hamper some plug-in behavior. For example, FBJS does not support document.cookies, so plug-ins that rely on cookies (e.g., getValOnce, getDaysSinceLastVisit, etc.) will not work. For this reason, Omniture recommends using a home-grown solution, built in accordance with available FBJS documentation, to ensure correct functionality, rather than relying on plug-ins in your Facebook app implementation.
  • If you use first-party cookies in your SiteCatalyst implementation on your site, you can also use them in your implementation on Facebook apps by adding the s.trackingServer and s.trackingServerSecure variables, set to the appropriate data collection domains, to the s_code_fb.js file. However, note that this will function as third-party cookies to end users, because the app will be served up by Facebook and not directly by your site. Generally speaking, the Omniture cookie is not affected by Facebook’s limited cookie functionality. This means that (as mentioned above) pathing data, as well as visit/visitor data, can be recorded normally.
  • App Measurement for Facebook is only to be used for FBML applications. iFrame-based apps should use the standard Omniture JavaScript code, and Flash-based apps should use Omniture ActionSource.

Finally, please be aware that full documentation on the Facebook app measurement code is available within SiteCatalyst by going to Help > Help Home, then selecting Supporting Docs > Manuals from the left navigation menu. I’d also recommend checking out this blog post by my colleague, Vishal Chordia, from our Product Marketing team. Happy Facebooking!

0 comments