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

Facebook plans to add a conversion tracking tool to its suite of advertising products based on demand from the marketplace. The platform will allow marketers to track clicks through conversion, Brian Boland, manager of direct response solutions for Facebook, told OMMA Social attendees in San Francisco on Tuesday.

Reports will provide a list of tracked conversions and the impressions and the clicks that led to each. The feature will help marketers build out messages as the campaign expands into a variety of pieces.

Boland also served up advice on how to calculate a cost-per-fan metric to determine the campaigns return on investment (ROI). Not only the cost to acquire a fan, but the fan's worth. "Some businesses have looked at it as the depth in which they have the community engaged and look at the downstream effects," he says, pointing to Starbucks and Threadless as two examples.

Read the full article here.
http://www.mediapost.com/publications/?fa=Articles.showArticle&art_aid=121357#

Update: Datalicious now Atomic Lab Pion reseller and integration partner for Australia.

Is implementing and updating Omniture page tags an issue for you? Atomic Labs's Pion Reactors provides a solution to process your website and campaign data server side and then insert it via the Omniture API. They also currently support sending data to Google Analytics and Unica.

In contrast to using a central JavaScript file to dynamically populate the Omniture variables based on page URLs, the Atomic Labs software taps into the network traffic stream and can then use any text within the transmitted data to create/modify additional variables and events via processing rules. At the same time you can also enrich your visitors click stream data from the website with profiling information from your CRM database using simple SQL queries and all in real-time, a great first step towards single customer view.

Why would you want to implement this?

1. Bypass your developers, staging, testing, etc. Increase your speed to new insights
2. Deploy new analytics without risking errors on your web site
3. Hide your tracking data from prying eyes
4. Modify your CRM in real time. Create targeting algorithms to better serve your customer as well as lead queues for call center staff, all on the fly.
5. Enrich your analytics with data you would not allow in javascript, such as "profit on a sale transaction".
6. You won't lose data because of analytics request delays

Check out the Atomic Labs website below or email Hamish at hogilvy@datalicious.com for more information and implementation help.

http://www.atomiclabs.com/

Google has just added a function in Google Webmaster Tools that let’s you flag parameters you wish Google to ignore when crawling your site.

These can include things like session IDs, additional parameters and tracking ids. This is great way of handling the problem rather than forcing the webmaster to implement expensive work-around’s to be found in Google which has historically been the case.

Traditionally, sites that use session IDs as a way of tracking users or e-commerce, will have a disadvantage in search engine optimisation for a few reasons:

• Duplicate content
• Dispersion of page credit
• Potential for bot to get tied up on these additional pages and not crawl other important pages as often

On the tracking front, and speaking from personal experience, flagging removal of tracking IDs is a big boost to data integrity. A recent campaign I worked on saw several blog and news site pick up a unique tracking URL to refer back to the clients site, a tracking ID that was meant to be unique for an email campaign. Google then decided to pick this URL up as it crawled through the sites and it ranked it well in search. The result was most of the search visitors appeared to the analytics system that they came from the email campaign and the collected data were significantly impacted.

Great news and makes life a lot easier for web masters and marketers stuck with this problem.

http://googlewebmastercentral.blogspot.com/2009/10/new-parameter-handling-tool-helps-with.html