I decided to write a series of blog posts about traffic sources performance evaluation in Adobe Analytics (formerly SiteCatalyst), because I haven’t met a single client that would fully understand about what is going on here.
To understand the current mess in traffic sources reports one must go through the history of these reports since the ancient ages.
The first level of the reports is in the default menu under the “Traffic Sources” Folder:
- Search Keywords – All
- Search Keywords – Paid
- Search Keywords – Natural
- Search Engines – All
- Search Engines – Paid
- Search Engines – Natural
- All Search Page Ranking
- Referring Domains
- Original Referring Domains
- Referrer Types
These reports serve the desire to be able to identify the basic traffic source types and provide reports for some of their specific characteristics (keywords for the search and referrer data for websites containing clicked links to a measured domain). The original ambition wasn’t very high, so it was enough to identify the traffic source for a single session (mostly called a Visit).
Internal Traffic Filters
The first thing you have to take care about is the fact, that every single Pageview may contain information about the referring URL (HTTP header “Referer”) – even those that follow Pageviews from your own website. So you need to tell SiteCatalyst which domains are part of your measured website, because otherwise SiteCatalyst would also consider your own pages as a Traffic Source. Basically you need to list all the domains that shouldn’t be considered a Traffic Source (there might be also i.e. Payment Gateways when applicable).
Search Engines in fact are also just another form of Referring Pages. SiteCatalyst contains a list of these by default. There is one more rule that needs to be fulfilled – the preceding page needs to contain the search phrase (most often in a query parameter “q” – i.e. http://www.bing.com/search?q=search%20phrase). The situation changed a bit with Google’s concerns about privacy, so now you don’t always have access to the Google’s search phrase, but at least you are able to recognize that it was a search due to the referring URL format.
Paid Search Detection Rules
Because the HTTP request does not contain the information about what particular link that was clicked on the Search Results Page (SERP), you need to do one more thing to recognize whether the Click-trough was from a Natural or a Paid Search Result. Mostly this is done through query parameters on the links from the Paid Search Results (mostly “cid” in SiteCatalyst or “utm_source/medium/campaign” in Google Analytics) called Campaign Tags.
What about the rest
Last but not least there is certain amount of traffic, that does not contain HTTP Referer information. Most often we call these “Direct Traffic” or sometimes you can find “Typed/Bookmarked” value in SiteCatalyst reports. This is not a very precise label, because under this value there is various traffic. Besides apparent scenarios in which the Visitor types our domain directly into the browser or clicks a previously bookmarked link, there might be also clicks from other applications (like Desktop Email or Social Media Clients) and also from browsers that simply do not disclose the referring URL information due to privacy reasons. There is also a scenario when the user clicks from a secured webpage (https://) to an unsecured one (http://), where the referring URL information is often also unavailable due to security reasons.
These reports are based just on the single session recorded within the tool and sadly these don’t take campaigns into account. The problem is, that “Campaign” is more of a made up concept that doesn’t align with the same borders as simple buckets separated by rules about the referring URL.
What comes next
Following article will outline campaign tracking, as it was a next stage in the SiteCatalyst development.