Archives

 

Getting Started With the Omniture PHP Measurement Library

The Omniture PHP Measurement Library lets you use PHP to record your visitor’s activity on your Web site. At first glance it can look a little intimidating, but it really is not that complicated. Once you have it implemented, all that you will see in the source code of your pages is the image request for the standard Omniture tracking pixel. This is what it looks like implemented.

Here is how to get started with it. From the Code Manager, download the OmnitureMeasurement.class.php file and add it to your server in a place so it can be referenced from every page of your site. Next you will need to include the Omniture PHP code on every page of your site.

Here is what a basic version of the PHP page code would look like:

<?php
require_once 'OmnitureMeasurement.class.php';
$s = new OmnitureMeasurement();
$s->account = 'ACCOUNT NAME HERE';
$s->botDetection = true;

$s->pageName = "Homepage";
$s->server = "Server";
$s->channel = "Channel";

$s->events = "events";
$s->prop1 = "prop1";
$s->prop2 = "prop2";
$s->eVar1 = "eVar1";
$s->eVar2 = "eVar2";

$s->currencyCode = 'USD';
$s->imageDimensions = '5x5';
$s->trackingServer = 'dominionenterprises.112.2o7.net';
$s->sendFromServer = false;
$s->debugTracking = false;
$s->track();
?>

Lets break it down by section so you will see what is going on here. Here is the first section of the code:

<?php
require_once 'OmnitureMeasurement.class.php';
$s = new OmnitureMeasurement();
$s->account = 'ACCOUNT NAME HERE';
$s->botDetection = true;

The first thing we have here is the call to the Omniture Measurement class require_once ‘OmnitureMeasurement.class.php’;. This is what makes the Omniture PHP tracking work. As I said you can download it from the Admin section of SiteCatalyst. That is followed by a line of code that will get the tracking started $s = new OmnitureMeasurement();. Next is the place where you enter the report suite id that is associated with the site you plan on tracking. Finally we have a line to detect bots. When this is set to true, the Measurement Library detects if the HTTP User-Agent field is a bot, and does not send bot-generated data to Omniture. If this is not included it is set to false by default. If you decide to not include that, then be prepared to see Googlebot show up in your reporting.
Googlebot User Agent

$s->pageName = "Homepage";
$s->server = "Server";
$s->channel = "Channel";

This next section should be pretty self explanatory. This is where I set the pageName, the server, and the channel variables. On my 404 error page this is where I also include the pageType variable, which would look like $s->pageType=”errorPage”;.

EXTRA: For a lot of my sites I like to use the folder name of the URL as the page name. Here is how you can do that using PHP. I insert this code before the Omniture tracking section:

<?php
$pNme = parse_url($url, PHP_URL_PATH);
if ($pNme=="/")$pNme = "Home Page";
?>

Then in the measurement library code I include:

$s->pageName = $pNme;

This pulls the file name from the URL and uses that as the page name. I also added a line that looks if all it finds is a slash / then I know they are on the Home Page and use that instead.

$s->events = "events";
$s->prop1 = "prop1";
$s->prop2 = "prop2";
$s->eVar1 = "eVar1";
$s->eVar2 = "eVar2";

This next section is where we are going to add the Custom Traffic variables, Custom Conversion variables, and Success Events. Again, this section should be pretty straight forward. If you know how to set props and eVars on the page and in the s_code file, you should know what to do here.

$s->currencyCode = 'USD';
$s->debugTracking = false;
$s->imageDimensions = '5x5';
$s->trackingServer = '112.2o7.net';
$s->sendFromServer = false;
$s->debugTracking = false;
$s->track();

This final section contains some pretty important elements. The first thing you will see is where you declare the Currency Code used for purchases or currency events. You can see I have mine set to US currency, USD. Next I have the call that specifies the width and height of the image request, in pixels. By default, this variable is 1×1. You can see I have mine changed to 5×5 to ensure support for all mobile devices. Next I enter my tracking server info. You should be able to find that in your s_code.js file.

The next two lines are pretty cool. Let’s say you do not to show any Omniture code on the page. You have the option to not have any thing appear in the source code. When $s->sendFromServer is set to true, the Measurement Library makes a direct HTTP request from the server instead of rendering an image tag to the Web browser. If you view the source of the page you will not see anything but the visitor will still be fully tracked. You can see a live example of it here.

Without any code on the page it can be difficult to debug the code to make sure everything is being passed in successfully. That’s where the next variable comes in, $s->debugTracking. With this set to false then we do not see anything. If it is set to true then you will see an output on the page of the metrics that are being passed into Omniture. You can see a live example of it here.

The problem with that is you either have it off all the time, or you have it on where all of your visitors can see a bunch of code on the page. What I like to do is to add in a little bit of extra code that will only allow the debug code to appear only for me. I do this based off of my ip address. I include this bit of code before the Omniture code:

$ip=$_SERVER['REMOTE_ADDR'];
if ($ip=="xxx.xxx.xx.xxx") {
	$atHome = true;
} else {
	$atHome = false;
}

And then In the Omniture code I have it set as:

$s->debugTracking = $atHome;

What this does is allows me to see the variables that are being set every time I visit the site, but none of my visitors have to see it.

The last thing you will see listed in this section is $s->track(); which is the call to fire off the code. Without this nothing works. This is the equivalent of having the line var s_code=s.t();if(s_code)document.write(s_code) in the standard JavaScript tracking. In other words, make sure you include this line.

OK, what else can we do with this? Well as many people know I am a big fan of using plug-ins. Here is one to get you started. One of the more useful ones is the Time Parting plug-in. As I have written about before, I like combining all of the time variables so I only use a single prop/eVar, so it looks something like s.prop1=”thursday|10:00pm” and then using a SAINT classification to break it out. How do we replicate this using the PHP Library? Here you go.

Above the Omniture Measurement code I include this:

$dayname = date('l');
$dayname = strtolower($dayname);
$hourname = date('g');
$minname = date('i');
$ampmname = date('a'); 

if ($minname <= "14") {
	$mintype = "00";
} else if ($minname >= "15" && $minname <= "29"){
	$mintype = "15";
} else if ($minname >= "30" && $minname <= "44"){
	$mintype = "30";
} else if ($minname >= "45" && $minname <= "59"){	
	$mintype = "45";
}
$fulldayparting = "$dayname|$hourname:$mintype$ampmname"; 

Then in one of the available props in the code I have:

$s->prop16 = $fulldayparting; 

This returns something like thursday|10:00pm, exactly like the Javascript plug-in does. I also like to copy this same value to an eVar, but I only want to do it once per visit. I like using the eVar for when the visit started, and the prop for every page view. Here is how I get that same value recorded only once per visit.

At the top of all my ‘extra’ code that I have included before the Omniture measurement code, I include this:

$sesionnumber = $_SESSION['count'];
if ($sesionnumber == '1') {
     $fulldaypartingsession = $fulldayparting;
} else {
     $fulldaypartingsession = '';
}

And then with the available eVars I include:

$s->eVar16 = $fulldaypartingsession;

What this does is on the first page of the session it will set the Time Parting value, but will just leave it blank for the rest of the session giving you a good session start time.

Hopefully this is enough to get you started. There are a lot of other cool PHP tricks that will allow you to replicate most of the functions of the Javascript tracking. Make sure you download and read the PHP Measurement Library Implementation Guide from the Omniture Help Section for additional details.

Enjoy!

Enhance Your SiteCatalyst S_Code Using Server-Side Scripting

I receive a lot of questions from people working on their own SiteCatalyst implementations and I’m always happy to help. One that I got recently is “why is your s_code file a php file”? I figured there were not too many people out there doing it like this or even know about this, so I thought I would help out those that were interested in what the advantages of using server side code to enhance your data collection.

The reason I use a php file to house all of my s_code script is simple. I want to be able to do what is not easily done with using standard JavaScript. Here are a couple of examples.

First things first. How do I get a php file to act like JavaScript? It’s actually pretty easy. First thing you do is in the top of your file add this small bit of code:

<?php header('Content-type: application/javascript'); ?>

The purpose of this line is just to say ‘hey, unless instructed otherwise, treat everything you are going to see here as JavaScript. Next change your file extension from .js to .php. That’s all you need to do to start adding in some php scripting into your file.

Here are some things I am using it for. I like capturing the IP address of my visitors. I like to track this because I have had problems with spammers, scraper bots and general bad visitors in the past, and I just like keeping my eye on things. Here is the code to capture IP address.

s.eVar17="<?php echo $_SERVER['REMOTE_ADDR']?>";

I also have this matched with the get Val Once plug-in.

Another thing I like to capture is User Agent. How many people come to my site from a specific build of IE6? Is Googlebot executing my JavaScript when crawling my site? Here is how I capture User Agent.

s.eVar23="<?php echo $_SERVER['HTTP_USER_AGENT']?>";

Again I match this up with the get Val Once plug-in.

Another thing I like to do is use php to populate the configuration variables of the Time Parting plug-in. The latest version of the plug-in, 2.0, uses specific daylight savings time variables (the 2.0 version is available from the Omniture Help section. The version I host here on the site is the older 1.4 version). The 3 variables that need to be configured for the plug-in are Daylight Savings Time start day for the current year, Daylight Savings Time end day for the current year, and the Current Year. Now all of these can be hard coded, but I’d rather do a little bit of one time coding and never have to worry about it again. Here is how I set those variables using php.

s.dstStart="<?php echo date('m/d/Y', strtotime("Second Sunday March 0"));?>";
s.dstEnd="<?php echo date('m/d/Y', strtotime("First Sunday November 0"));?>";
s.currentYear="<?php echo date('Y');?>";

All of these take advantage of the date() functionality of php. Combine that with a little bit of extra code, and with the fact that I know that daylight savings time always begins the second Sunday of March and ends on the first Sunday of November, I never need to touch those variables again.