If you've ever been frustrated at the need for developers to add javascript tracking code, or you simply want to track pages like RSS and mobile pages where javascript is not allowed, then the following solution is for you.

We've done several server side solutions like this, such as the integration of phone calls into Google Analytics directly from the phone routing server (stay tuned for more!). I was reading through some articles researching and i came across an elegant post that i thought i should share:

http://www.vdgraaf.info/google-analytics-without-javascript.html

The PHP code to fake the image request for Google is as follows (also found at http://www.vdgraaf.info/wp-content/uploads/tracker.txt), although a similar technique can be used for Omniture or other platforms. This post is pretty old, but the code should still be fine, the principle is definitely still ok! 

Oh and this is also useful if you want to add other information to your Analytics, but you want to keep it from prying eyes! If you find this post useful, you may also want to check out one of our posts on network packet sniffing, which is becoming a serious alternative to javascript page tagging. See http://blog.datalicious.com/atomic-labs-pion-implementing-omniture-withou 

For more help with these types of integrations, contact us at insights@datalicious.com. 

<?php
$var_utmac='UA-000000-1'; //enter the new urchin code
$var_utmhn='yourdomain.com'; //enter your domain
$var_utmn=rand(1000000000,9999999999); //random request number
$var_cookie=rand(10000000,99999999); //random cookie number
$var_random=rand(1000000000,2147483647); //number under 2147483647
$var_today=time(); //today
$var_referer=$_SERVER['HTTP_REFERER']; //referer url

$var_uservar='-'; //enter your own user defined variable
$var_utmp='tracker/'.$_GET['url'].'.'.$_GET['filetype']; //this example adds a fake file request to the (fake) tracker directory (the image/pdf filename).

$urchinUrl='http://www.google-analytics.com/__utm.gif?utmwv=1&utmn='.$var_utmn.'&utmsr=-&utmsc=-&utmul=-&utmje=0&utmfl=-&utmdt=-&utmhn='.$var_utmhn.'&utmr='.$var_referer.'&utmp='.$var_utmp.'&utmac='.$var_utmac.'&utmcc=__utma%3D'.$var_cookie.'.'.$var_random.'.'.$var_today.'.'.$var_today.'.'.$var_today.'.2%3B%2B__utmb%3D'.$var_cookie.'%3B%2B__utmc%3D'.$var_cookie.'%3B%2B__utmz%3D'.$var_cookie.'.'.$var_today.'.2.2.utmccn%3D(direct)%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmv%3D'.$var_cookie.'.'.$var_uservar.'%3B';
 
$handle = fopen ($urchinUrl, "r");
$test = fgets($handle);
fclose($handle);

switch ($_GET['filetype']){
        case 'jpg':
        header('Content-Type: image/jpeg');
        break;
        case 'gif':
        header('Content-type: image/gif');
        break;
        case 'pdf':
        header('Content-type: application/pdf');
        break;
        // add your own content types where needed
}

$imageurl = fopen ('http://www.yourdomain.com/'.$_GET['url'].'.'.$_GET['filetype'], "r"); //this is where the real file should be located
while (!feof ($imageurl)) {
        $image = fgets($imageurl, 4096);
        echo $image;
}
fclose($imageurl);
?>

So what's the big deal?
I continually get to look inside the Site Catalyst implementations of various companies as they struggle to extract value from the product. Those implementations are usually done in such a way that future upgrades are extremely painful and time consuming, if not virtually impossible. Javascript page tagging is messy, but you can make it much cleaner by following the tips below.

Standard Practice and why you can do much better
Most web sites have a block of Omniture variables declared in the page code. For example, somewhere in the body, you may see something like:

s.pageName="site:some page";
s.prop12="calculator";
s.eVar14="widgets";
s.events="event2";

Lets say that prop12 is looking at tool usage and eVar14 is looking at product category affinity. The above will work fine, the variables will be populated in the scode and sent with the request as expected. But what happens when a developer comes back in 2 years time and wants to switch the usage of eVar14 or prop12? The variables are hard-coded everywhere, they appear in lots of templates, a few microsites, and are straight hard-coded on some custom pages, it's a complete nightmare.

The Solution
Call the variables something meaningful to you instead, don't use the Omniture naming convention in your HTML, this makes future changes very messy. Once you have your own variable names you can then transfer the information to the relevant site catalyst variables in the scode file.

Useful naming convention has several benefits:
1. It makes sense to the developer and hence they are less likely to screw it up
2. If you later want to make a change, that's fine, you simply make one change in the scode file and all the old usage will cease immediately as the new usage takes it's place. Switching a variable for your whole site/s can be done in minutes.

Example:
On page:
s.pageName="site:some page";
scToolUsage="calculator";
scCatAffinity="widgets";

In the scode, inside the s_doPlugins(s) function:
s.prop12=scToolUsage;
s.eVar14=scCatAffinity;

In the scode, outside the s_doPlugins(s) function (this makes sure the variables are declared in case they are not declared on the page):
scToolUsage="";
scCatAffinity="";

What about events?
Many events are page related (i.e. a registration event is triggered on the registration confirmation page). So why declare it on page in the variable section? You may want to change it later. Again this is something that can be easily dealt with in your scode file. If you use good s.pageName notation, you can trigger events specifically when certain pages are loaded. Below is an example using the s.apl plugin to append event2 to the s.events variable whenever the pageName contains "registration-thank-you". If you later decide to change the usage of event2 you can once again make a single change in the scode file and you're done, you don't have to worry about searching for code across your site/s.

Example code inside the s_doPlugins(s) function:
var scRegistration=new RegExp("registration-thank-you");
    if (scRegistration.test(s.pageName)) {
        s.events=s.apl(s.events,'event2',',',1);
    };

In short, centralise all the code maintenance you can in your scode file, this makes your developers jobs easier and also provides the freedom and flexibility to make changes quickly moving forward. Secondly, the pageName variable should be your one constant on-page declaration, use it wisely and it can be very powerful. For more tips on s.pageName convention best practice, see our earlier blog post on top 5 tips for deploying Omniture SiteCatalyst. For more information on Site Catalyst deployments, drop me a line at hogilvy@datalicious.com