Campaign tracking pitfall
Do you use unique tracking ID’s for each of your campaigns? Then make sure that you interprete the data right, and keep in mind the following:
- direct entry or organic search will NOT appear in the campaign report
- direct entry or organic search are traffic sources for visits, but conversion generated during those visits will be attributed typically to the last clicked campaign, if any, or to an “Unspecified” category if no campaign-cookie was present.
- during a visit referred by a tagged campaign link, a visitor might still engage in an organic search, revisit your site during the same 30 minute period (and thus the same visit) and convert; is it then still correct to attribute the conversion to only the campaign (as it would show up in your campaign report)?
Several methods exist that offer a complete view:
- create a unified traffic rule (if your WA software supports this) that categorizes every entry as either a specific campaign (tracking code present), an organic search (no tracking code, referral from a search engine), a direct entry (no tracking code, no referrer). This approach attributes a conversion to the last “real” entry method, and allows some finetuning: you might still decide for instance to consider an organic search for your URL or brand name as a direct entry instead of an organic search entry.
- setting the expiration of the campaign cookie to “visit” gives more or less the same result as far as conversion allocation is concerned, but can still not differentiate between organic search and direct entry
- install a campaign pathing system, either through your WA software (Omniture has a plugin for this), or by using solutions like TagMan. This will allow you to distribute the conversion value over the different entry methods leading up to the converting visit.
- TagMan additionally allows you to deduplicate between affiliate sales and/or organic search sales.
Error page tagging
A very basic issue in all WA implementations is the completeness of the implementation. Sure: you browse your site, using checking tools like WASP, but what about all those pages that you DON’T browse? All the pages that people aren’t suppose to see?
Don’t be so naive as to think that your online audience won’t see them, ever. Oh no, if it’s on the net, people are bound to encounter it sometimes. Error pages might be hard to come by, but you don’t want them messing with your visitors, do you?
For error pages residing within your wCMS, it shouldn’t be too hard to convince your administrator to create (static) tags for each individual page. Try squeezing as much info as possible in those tags: any info about the origin of the error is best captured in an extra variable or property. Try categorizing this info to avoid an abundance of different error messages clouding your stats.
For “technical” error pages that are not managed in your wCMS, but just reside on your server, kindly talk to your IT colleagues to do the tagging for you. It are primarily these pages that never make it to your WA suite, so it might seem that all your online visitors are happily browsing, but you might be missing out on a huge chunk of frustrated surfers getting stuck on a 404 page as an untagged entry page…But you’ll never know without proper tagging.
It’s the basic rule of statistics: the data only tells you about the population you sampled.
