Archives

 

Update SiteCatalyst Marketing Channels To Include Pinterest

This week Adobe released an infographic regarding their advances in measuring social media. As I was reading it, one part really caught my attention: “For many, shopping is inherently social. Online shoppers miss going to the mall with friends, sharing their opinions, and getting a little feedback before making a purchase. By filling this digital gap, Pinterest has become the #2 driver of traffic to retailers in less than a years’ time.

Wow, Pinterest is really taking off as a valuable social traffic source for eCommerce sites. But for some reason I don’t remember seeing Pinterest listed among my top social media sites. This makes me wonder, are all of my marketing channel reports accurately showing their value?

If you are a big user of the Marketing Channel reports, at some point they will need to be updated. Specifically the social networks channel. Adobe does a good job keeping the list of known search engines pretty accurate across SiteCatalyst, but the same can’t be said about the list of social networks.

If your marketing channel reports were initially activated using the auto-setup option, they included a list of domains that are considered to be social networks by SiteCatalyst. Unfortunately that list does not get automatically updated over time like the list of search engines does, or like the list of domains used to identify the social networks in the traffic sources referrer type report does, and that’s fine. If I have edited the list of social network domains in the marketing channel rule, I don’t want it to be changed by some automatic update. But when using the auto-setup option to enable the marketing channels, for some reason the list of domains used to create the social network channel is considerably different than the list of domains used to identify a social network in the referrer type report.

The SiteCatalyst knowledge base answer #10576 contains a list of 128 different domains that are used in the Referrer Type report to identify social networks. In contrast if you take a look at the marketing channels processing rules to see which domains get pre-defined as social networks, that list is much smaller. Only 51 domains. I even went and enabled the marketing channels reports on a report suite that has never had them before today to check, and I still only saw the 51 domains included in the social network rule.

Marketing Channels Social Networks Processing Rule

We can see that the rule to define social networks can accept up to 500 different domains, so why the default list is less than half of what is used for the referrer types report is a great question.

But wait a minute, I don’t remember seeing Pinterest in either of the lists of social networks that was used by the marketing channels reports or the referrer types reports. I decided to double check the reports themselves, so I opened up the referrer type report, broke it down by the referrer report, and in fact Pinterest was there. It is accurately considered to be a social network in the traffic sources reports. That tells me that even though the list of domains used to define a social network in KB answer #10576 was current as of November 2011 as it states, it in fact has been updated since then. Now checking the marketing channels reports manager, I see the rule which defines a social network still contains the original list of 51 domains. The social network marketing channel for my eCommerce sites has been missing out on the credit for all the conversions generated from that valuable Pinterest traffic, as well as any conversion credit from those other 77 domains considered to be social networks that were not included in that channels rule. My marketing channel reports were not providing an accurate representation of my social networks true value.

Whether you’re using the Unified Sources VISTA rule, the Channel Manager s_code.js plugin, the Marketing Channel Manager that’s built into SiteCatalyst, or some other channel identification method, make sure you are keeping it updated regularly to ensure all of your marketing channels are getting all the credit they deserve.

enjoy!

Improve Accuracy & Identify Traffic That SiteCatalyst Can’t

I’ve been doing a lot of work recently with my Traffic Sources reports. My goals have been to clean up messy data that could come in, and to make it easier to look at traffic from different sections of the same referrer. Now I would like to see what I can do to make the standard Referrer and Referring Domains reports a little more accurate, and try to fill in some of the holes they create which prevent me from getting a really good summary view of my traffic.

Overall the standard Referrer and Referring Domains reports do a pretty good job at telling me where my visitors came from, but there is one item that is a major problem for me. That one item is called “Typed/Bookmarked”.

According to the SiteCatalyst Knowledge Base, “Typed/Bookmarked line items occur in reporting where a referrer for an image request is not present.” So in other words, if SiteCatalyst does not see a referrer value, then it simply can not tell you where that visitor came from, so they get dropped into the Typed/Bookmarked bucket. Typically that’s fine. There is no way to know completely where every single one of your visitors came from. Thats just the nature of the beast. But one problem I have is that even though SiteCatalyst may not know where that visitor came from, I possibly do. So how do I know but SiteCatalyst doesn’t you ask? Tracking codes.

Yesterday Omniture shared a study that was done by BtoB Magazine which said “email is used by 88% of marketers surveyed and ranked as their No. 1 form of digital outreach”. Its been no secret that running email campaigns is a great way to get more visits for your site, and ultimately more conversions. Judging by my inbox there are a lot of marketers out there that agree. Email marketing best practices recommend that tracking codes are included on all of the URL’s in the email. This is typically the best way to determine the effectiveness of those email campaigns, and hopefully it’s something you’ve been doing with your own email campaigns. The problem with this is that most email applications are not going to pass a referrer value to the site. So even though we are able to track the performance of these emails in our campaign reporting, when looking at our Referrer reports we are not able to see that traffic credited to the correct source. No referring value means the Traffic Sources reports consider it to be Typed/Bookmarked traffic, when we know it isn’t. Our Typed/Bookmarked values get over inflated, and the email campaign traffic doesn’t get properly credited. So what can be done about it?

Here’s what I like to do. I add in a tiny bit of code to the doPlugins section of my s_code.js file that checks to see if the image request has no referring URL, and if the current URL has a tracking code associated with one of my email campaigns. If that criteria is met then inject a specific referring domain value to my traffic sources report, correctly attributing that visit as being from one of my email campaigns. The code to do this is quite simple:

if(!document.referrer){
	var s_eml = s.getQueryParam('eml');
	if(s_eml){s.referrer="mail://email.campaign/"+s_eml;}
}

Now lets say I’m running an email campaign which contains links to my home page. I made sure that the URL’s for those links have the query string parameter eml=56789. The parameter eml is the tracking code I use specifically for my email campaigns, and 56789 is the identifier for that specific campaign. When a visitor tries to access a page of my site using one of those URL’s containing my email tracking code and they do not have a referring URL value, my normal campaign tracking does it’s job, and this new snippet of code inject’s the value of mail://email.campaign/56789 as the referring domain. If the visitor was using using an email application that did pass a referrer value, then that passed value will always take precedence. Injecting that new value as the referring URL will accomplish a couple of things. First that whole value will now appear in my Referrers report. With that I’m able to compare the traffic generated from specific email campaigns to other traffic sources. Comparing traffic generated from an email campaign to traffic generated from an organic source wasn’t always the easiest thing to do in a single SiteCatalyst report.
Email Referrer

Next in my Referring Domains report I will get the value of email.campaign, and more importantly I won’t register another instance of Typed/Bookmarked. With this I can get a look at the traffic generated from the email campaign compared to all my other known referrers as a whole to see how it stacks up.
Email Referring Domains

Here’s an additional bonus I get from doing this. If you take a look at that URL value I used as the referrer value, it does not begin with http://, but it begins with mail://. In the Traffic Sources reports you will find a report called Referrer Type. This report is basically a glorified SAINT classification that looks at each referring URL and assigns it to a different bucket. When a SiteCatalyst see’s a referring URL beginning with the value of mail:// or the value of imap:// it then gets classified to the Mail bucket in the Referrer Type report. I’m now starting to get a better view of all my traffic sources in one pretty graph.

Email Referrer Types

Another source of traffic for some sites that is also not being accurately represented in the Traffic Sources reports is when a visitor comes to the site by clicking a link in a pdf. Last week after the latest iPad was announced, a friend sent me a pdf that came from Apple about using the iPad at Work. It contained good information, so I passed it along to a couple of other friends. Looking at the pdf a little closer, there was one thing that caught my eye. It contained 25 individual links back to apple.com. I wasn’t viewing this email in a web browser but in the simple Preview app on my Mac, yet every single one of those links was clickable. I thought that was great, another opportunities to drive traffic to the site. But this was also not so great because it was another opportunities to take a visitor and classify them as being Typed/Bookmarked, even though Apple could know easily and specifically where they were coming from.

Much like with emails, all it takes is a tiny couple of lines of code to identify that traffic. I like to use the value of pdf= as the query string parameter for links embedded in pdf’s, but you can obviously change it to whatever you like.

if(!document.referrer){
	var s_pdf = s.getQueryParam('pdf');
	if(s_pdf){s.referrer="file://pdf.document/"+s_pdf;}
}

Just like before with the emails, the current URL needs to contain that tracking code and there must be no referrer value present for this to work.

Taking a look at that snippet of code, I used the referring URL domain value of file://pdf.document combined with a unique identifier for that pdf. Unlike with the email’s, this time I started the value with file://. This will now get assigned a new value in the Referrer Type report, the value of Hard Drive. Not the best description of what’s going on, but that’s the only value left. The Referrer Type report is set to classify all referrers into 6 different buckets, and there is no way to add any additional categories to it.

All Referrer Types

Another popular source of traffic I’ve seen that does not get proper credit in Traffic Sources reports are visits that come from a mobile application. There are tons of mobile apps which have some component to them that can take the visitor from the app to their website. Like all the other links, you hopefully have the ones in your mobile app tagged with a tracking code. If so then just one more snippet of code and that traffic can be accounted for:

if(!document.referrer){
	var s_app = s.getQueryParam('app');
	if(s_app){s.referrer="file://mobile.application/"+s_app;}
}

I used the tracking code of app, but you can use what ever you would like. This app referred traffic will also be listed in the referrer type report as Hard Drive. Since I used up all the options in that report, all the extras such as mobile app traffic and pdf traffic will need to share the Hard Drive bucket.

I like to keep all three snippets of code wrapped up in one clean package:

if(!document.referrer){
	var s_eml = s.getQueryParam('eml');
	var s_pdf = s.getQueryParam('pdf');
	var s_app = s.getQueryParam('app');

	if(s_eml){
		s.referrer = "mail://email.campaign/"+s_eml;
	}else if(s_pdf){
		s.referrer = "file:///pdf.document/"+s_pdf;
	}else if(s_app){
		s.referrer = "file:///mobile.application/"+s_app;
	}
}

Now in my Referrer and Referring Domains reporting, I get a better look at how my visitors are arriving to my site.
All New Referrers

All New Referring Domains

Maybe you have some other kind of web app, or some kind of shared widget, or some other totally different way for visitors to follow a link to get to your site. So long as you can add a tracking code to that link you can get that traffic correctly represented in your Traffic Sources reports, and stop over inflating the Typed/Bookmarked metric. This is not meant to replace the Marketing Channels reports, the Channel Manager plugin, or the Unified Sources VISTA rule, but to improve the functionality and accuracy of some of the core SiteCatalyst reports.

I hope this helps.
enjoy!

How To Improve Referring Domain Reporting In SiteCatalyst

While going over my Traffic Sources reports recently, I realized that I had a problem with how my referrers were reported. Not a problem with bad data coming into SiteCatalyst, like the recent issue I fixed regarding the Google Plus referrers, but this was a problem with the Referrers and Referring Domains reports themselves.

Both reports are working as they were designed, but the problem is that both reports are on opposite ends of the spectrum from one another. I feel that at times the Referrers report gives me too much information, while the Referring Domains report doesn’t give me enough. I need a something a bit more in the middle.

Here’s an example of the problem. Checking the Referring Domain report in SiteCatalyst, this is a snippet of what I see:
Referring Domains Report in SiteCatalyst

I can see that some of my visitors came from Google, and some from Yahoo, and that’s all this report tells me. When I see something like that, I start to wonder which sections of the referring site lead to the visitors deciding to come to my site. Well, the first thing I could do in an attempt to answer my question would be to click the magnifying glass icon next to each line item in the Referring Domains report to get a quick view of what referrers specifically mades up that value. Unfortunately the little popup window doesn’t break out the referrers in any kind of a useful way, and I can’t do anything with that popup report myself because there is no export option in that window, so that option’s out. I could do a standard sub-relation breakdown of the two reports, then export the results into Excel, then do some sorting and filtering and could probably get the answer I need for a single Referring Domain value in roughly 5 to 10 minutes. But then I’m stuck having to go back and do that whole process again for the other Referring Domains. This method could end up taking a while, so this option is also out. I’m sure I could whip something up in Data Warehouse, but I won’t see that report anytime soon either. I could go set up a ton of Processing Rules, but that won’t work because I would end up using all the rules just to help me populate one variable. So how do I get the report I need? Looks like it time for some more s_code magic.

And voilà. I give to you the s.getFullReferringDomains plugin. What this will do is look at that referrer value and grab not only the domain name, but any subdomains it may have as well. This uses the same s.linkInternalFilters values that you’ve already set up to ensure that this will only set its value when there is an external referrer. So now I will get a better, quicker, easier look at my referring domains:
Full Referring Domains Report in SiteCatalyst

All that needs to be done is to choose an unused variable, and call the plugin from it. This should be placed inside of the doPlugins section of the s_code.js file.

s.eVar1 = s.getFullReferringDomains();

Then just add the plugin itself to the plugins section of your s_code file.

/*
 * Get Full Referring Domains
 */  
s.getFullReferringDomains=new Function(""
+"var s=this,dr=window.document.referrer,n=s.linkInternalFilters.spli"
+"t(',');if(dr){var r=dr.split('/')[2],l=n.length;for(i=0;i<=l;i++){i"
+"f(r.indexOf(n[i])!=-1){r='';i=l+1;}}return r}");

One last thing I like to do with this new report is to go into the Report Suite manager in the Admin Console, and move it to the Traffic sources menu. This way all of your referrer related reports will all live in one spot. It looks like it should have lived there all along.

Full Referring Domains Traffic Sources Report in SiteCatalyst

enjoy!

How To Fix Google Plus Referrer Values In SiteCatalyst

Recently I was looking through some traffic sources reports in SiteCatalyst, and I noticed something odd. In my Referrers report I had a bunch of different referring URL’s that were all coming from Google Plus, all going to the exact same page on my site, but each referring URL was listed separately. Taking a closer look, I noticed that each referring URL contained some unique query string values, and my Referrers report was quickly getting filled up with a lot of redundant links.

Multiple Google Plus Referrers

I was curious to learn about what was going on, so using Chrome I logged into my Google Plus account looking for a link to click. I found a link one of my friends shared, clicked it, and then checked what the referring link to that site was.
Google Plus Referrer using Chrome
Next I did the same thing in Firefox. I clicked the exact same link as before shared by the same person, and then checked that referrer.
Google Plus Referrer using Firefox
Finally I tried clicking the exact same link for a third time, this time trying it in Safari.
Google Plus Referrer using Safari
The exact same link, shared by the exact same person, going to the exact same page, from the exact same Google Plus account, but three different referring URL values. It looked like Google Plus was using a unique URL value for each browser. But wait, I had a ton of different values in my Referrers report so that couldn’t be it. Still using Chrome I went back and clicked on the same link I’ve been using.
Google Plus Referrer using Chrome again
Another unique referring URL. As Google Plus usage beings to increase, I can see this becoming a big problem. I needed to find an easy way to clean up my Google Plus referrers.

Looking at each referring link I see that there are two parameters that are unique each time, n= and usg=. I could probably keep testing and find out what these two parameters meant, but I doubt I’ll need them. I just need to know that the visitor came from Google Plus. But looking closer at the referrer value I can see something else that could be useful. The url= parameter contains the page that the link was headed to, and that could be helpful to have. So if I had a way to just drop off everything from that Google Plus referring URL query string except for the url= value, that would give me what I’m looking for. I would now be able to clean up my Referrers report by removing all the redundant links, and as a bonus I would be able to tell which page of my site attracted the most attention on Google Plus just by looking at those referrers. So how do I do it?

All it takes is a little bit of code dropped into the s_code.js file and my problem is solved.
Google Plus Referrer's Cleaned Up In SiteCatalyst

The best part is that there is no set up required. I wanted to keep it really simple so I made sure that there’s nothing that needs to be configured. Just paste this plugin code right next to all of your other plugins, and all of your messy Google Plus referring URLs will get cleaned up automagically!

/*
 * Clean up Google Plus referrer values
 */
s.cleanGP=new Function("var s=this,a=document.referrer,b='plus.url.go"
+"ogle.com',c,d,e,g,i=0,p,referrer;if(a&&a.split('/')[2]==b){c=a.spli"
+"t(/[\?|&]/);d=c[0].length;e=c[0].lastIndexOf('/');g=d>e?c[0].substr"
+"ing(0,e+1):c[0];for(i=0;i<=c.length;i++)'url'==c[i].substring(0,3)&"
+"&(p='?'+unescape(c[i]),i=c.length+1);g&&(this.s.referrer=p?g+p:g);}"
+"return this.s.referrer")();

enjoy!

Capture Mobile Device Screen Orientation In SiteCatalyst

Recently I was speaking to someone who was in the process of creating an tablet experience for their visitors. At one point they asked the question “of my iPad visitors, how do I find out in what format do they view my site the most in, landscape or portrait?”. I started going through all of the reports in SiteCatalyst and tried to find the answer, but that information just was not available. So I decided to whip a little bit of code that would figure this out for us. I call this the screenOrientation plug-in.

Basically what this will do is it will check to see in what position the mobile visitor is viewing the site in, whether they are viewing the site in a portrait or a landscape view when the page loads, and capture that value into a SiteCatalyst variable.

To implement this plug-in you first need to take this code, and add it to your s_code file near the rest of your plug-ins.

function screenOrientation(){switch(window.orientation){case 0:case 180:return("Portrait");break;case 90:case -90:return("Landscape");}window.scroll(0,0)}

Next in the do_plugins section of the s_code file, add the call to the plug-in to what ever SiteCatalyst variable you want this data captured in. In the example here you can see I am capturing it in s.prop1

s.prop1=screenOrientation();

Thats all it takes. Once the code is implemented, if the device does not have an orientation value the variable will not capture anything, but if the visitor is on a mobile device with an orientation value, the value of Landscape or Portrait will be captured on each page load. You will end up with a report that looks something like this:

Mobile Screen Orientation Report

To make it easier to access the report I also moved it into the Mobile report menu by using the customize menus option in the admin console of SiteCatalyst.

SiteCatalyst Mobile Reports

enjoy!

Custom Link Tracking in Omniture using jQuery

One of the most common things I get asked to track are specific links on the website. Typically to do that I would use a custom link tracking function. This typically involves adding a large chunk of JavaScript code to each link, or adding a function to your s_code file and then calling that function using an onClick function added directly to the link. That methodology works fine, and I’ve been doing it forever. But that means working with IT to add more code to your pages, something I want to try to avoid as much as possible. So how can we make the implementation of our link tracking quicker and use less code? If you haven’t figured it out by now, we’re going to use some jQuery.

For more information how to do this, please read the full article Custom Link Tracking in Omniture using jQuery.

For more information on website optimization solutions, please visit Keystone Solutions.

How to Setup contextData Variables in SiteCatalyst 15



Today I show you how to setup and use contextData variables with processing rules in SiteCatalyst 15.

Enjoy.

Processing Rules in SiteCatalyst 15



Here is a quick look at what can be done with and how to set up processing rules in SiteCatalyst 15.

Enjoy.

How To Capture A Query String Parameter From A Referring URL In SiteCatalyst

Recently someone had asked the question, how do I capture a query string parameter that’s on referring URL? We all know how to grab a query string parameter from the current page URL by using the getQueryParam SiteCatalyst plug-in, but most people don’t know that plug-in can be used to get a query string parameter from the referring URL as well. I once had a real unique implementation that was not using that plug-in and needed to capture that value. I wanted to keep the implementation really light so I decided to give it a try using a smaller bit of code. I broke out a little JavaScript magic to see if I could make it happen simpler than using that plug-in. Turns out it’s not too difficult to accomplish, in fact I got it down to just a single line of code.

function getRefQueryParam(a){a=a.replace(/[\[]/,"\\[").replace(/[\]]/,"\\]");a=RegExp("[\\?&]"+a+"=([^&#]*)").exec(document.referrer);return a==null?"":a[1]};

Its a little function called getRefQueryParam. To use it just place that code in your s_code file, and then call it with the name of the query string parameter you want to capture. In this example I want to capture the value of the parameter forumID= from the referring URL and record it in s.prop1.

s.prop1=getRefQueryParam('forumID');

With a little JavaScript goodness it is an easy value to capture.

Enjoy.