A necessary but sometimes complicated union
| By Dr. Chris Grant A 2006 study by Forrester Research titled "The Top Marketing Technologies in 2005" revealed that website analytics and digital asset or content management systems (CMS) were in the upper ranks of marketing to-do lists. This has led to a re-allocation of many marketing budgets, and for good reason. A Content Management System (CMS) makes life easier for everyone responsible for maintaining a website. Changes to the site are faster, easier and less risky to implement. The CMS ensures that content is formatted correctly and the overall page layout and navigation stay intact. |
A Web analytics program also makes life easier for marketing executives by producing detailed information about website visitor behavior - data that enables marketers to make more informed decisions regarding their online content, applications, and marketing programs.
The not-so-great reality is that CMS and analytics are often implemented by different groups. Usually, IT controls content management while marketing departments tend to oversee Web analytics software.
Whichever camp you're in, analytics or CMS, the other camp will affect what you're trying to do. Sometimes, the effect is widespread and unfavorable. The CMS initiative, for example, often causes all URLs on your site to change to something completely different and is sometimes distinctly uninformative to the casual observer. This shift in URL structure is based largely on the way content management software dynamically constructs pages by calling in the appropriate template and content associated with that page. The analytics initiative will add many requirements to the building of the CMS that may not be welcome. It's not a good mix to have unless it's done right.
For example, suppose you are at the analytics end of the spectrum and have a well-performing analytics program in place, producing detailed information that supports your most important marketing decisions. Then, your Web developer decides to make the site more standardized while letting more people create pages using a CMS solution. CMS is implemented, launched, and you start seeing some effects in your analytics output:
- Your easy-to-read site activity reports turn into lists of URLs that you need a decoder ring to understand. Your top-viewed page, formerly displayed as /home.html, is now /site/us/page.asp?id=24758216781 and you have no idea if that's the home page or not. Or, perhaps worse, your top-viewed page is now /content/page.asp and, in fact, that page is showing up in reports as the only viewed page.
- Entire sections of the site seem to disappear from the reports. You once could glance at a list of site directories and learn about product-related traffic by looking at statistics for the directory called /products/. Now you're seeing only one directory, a gigantic one called /site/us/ that seems to contain all site activity with no differentiation.
- Since all the URLs have changed from what they were previously, links from other sites leading anywhere but the home page now result in "Page Not Found" screens. Your Page Errors report is now bloated with thousands of hits to the errors page.
- The programmers formerly added markers to your "featured products" links that allowed you to see how much of the traffic to each product came from the features. Now, they're telling you the CMS will not support that feature.
- One of the departments is adding several pages to the site. The CMS made it easy, but you discover too late that the reporting tracking code (that makes the pages reportable) doesn't appear in the new pages. None of the traffic to those pages is being recorded.
On the other side, suppose you are a site management maven and you have a clean, smoothly-running CMS implementation in place when a marketing executive decides to obtain some good visitor behavior information. Soon, you're getting on-technical sounding requests for changes from the people setting up the analytics software.
- Can you change my product page URL from www.yoursite.com/index.cfm?id=18742582 to something simple like www.yoursite.com/product?
- Please give us a list of all ID codes with their page titles.
- We need a list of all ID codes sorted by sections of the site. Here's a list of the directories previously on the site to help you sort.
- Here's some code. Every page needs to have this code inserted in the source.
- Links to pdfs and other downloads now need to go through redirects that are unique for each downloaded file.
Do any of these ring a bell?
Now, planning ahead and getting input from other parts of the system from the outset is always a good idea, so consider it said. But let's jump ahead to a couple of solutions that can sometimes bail everybody out after the situation has become unmanageable.
The Web analytics department often holds part of the solution in the form of three options that many good analytics programs have.
Turn on "display page titles
Amazing as it seems, reporting software does not always bother with page titles. Turning on "titles" will quickly and easily make your decoder-ring page URLs intelligible because the analytics reports will display both the page title and the garbled URL. You can then train your brain to scan the page titles and ignore the rest.
Of course, this option assumes that your pages have unique and descriptive page titles. If not, jump to options 2 and 3 - but also have a talk with the CMS people about the importance of unique and descriptive page titles for search engine ranks as well as reporting.
Turn on "display query parameters as part of the URL.
There's something shocking about a site report that shows massive traffic to just a few page file names such as page.asp, index.cfm or content.do. If this is what you're getting, then you are dealing with a CMS that works in terms of templates or page types. The actual page content is being specified in the file's arguments or query parameters - i.e. the stuff that appears after a "?" in the URL. For example: /www.yoursite.com/index.cfm?id=18742582 is telling the server to display the page template called Index and fill it with the content tagged as "18742582" in the content database.
Your analytics program was probably set to display only the filename in reports which, in this case, is index.cfm. Find the setting that forces a display of both the filename and the subsequent query string, and your analytics reports will fill up with unique URLs. True, they will be decoder-ring URLs, unless you use one of the other options as well. But the reports will no longer at first glance be incomprehensible.
Turn on "tabulate query parameters and translate them using a lookup table.
There's an alternative to option 2 that can be even better in some ways because it produces more legible results.
Most analytics programs will tabulate the query parameters in URLs, (e.g., display a list of all values of "id" that are used with the file index.cfm.) But the better programs will also let you supply a lookup table that the program will use before displaying reports - changing decoder-ring parameters into plain English of your choice. The table is usually a simple text file that you can easily create using information pulled from the site's content database, provided by your friends who run the CMS.
In other words, the "18742582" mentioned above can be displayed as "Customer Service Contact Page."
Lookup tables are wonderful things and Web analytics programs have incorporated them because of CMS and the like. If you have them, use them.
Although the Web analytics group can often produce passable reporting without any changes to the CMS, it's the CMS that really has the power. CMS software, by its very nature, is usually versatile and adaptable. In the end, it controls everything that the Web analytics software works with - the raw data.
With this power comes responsibility. So this is for you, CMS people:
If the Content Management tool generates a bread crumb trail, also "give" it to the analytics program.
This is possibly the single most helpful thing you can do for your analytics colleagues. In one fell swoop, it provides them the raw material for solving the issues of directories and decoder-ring URLs. Different analytics programs have different ways of collecting and using this extra information so CMS and analytics people will have to do a little homework. But the end result is an extra piece of information that not only describes what is on the page but gives it context and helps segment the site.
For a deluxe version, collect the bread crumb trail as one variable, and also break it up into first-level categories, second-level sub-categories, etc. This allows more ways to choose site "sections" for reports.
If your CMS doesn't put a bread crumb trail on pages, consider doing it now. As a general usability feature, everybody wins.
Add an "include" to the templates
An include is a command that tells a page to go to another location and collect a piece of code. This is a good thing to have in your templates on principle to make sure that little details like tracking codes are never left out.
A good place to put the include is in the footer because the footer tends to appear on every template, including those newly created.
Make the CMS generate meaningful and unique titles
With one-size-fits-all page titles, your site is missing big opportunities to be indexed by search engines and having understandable traffic reports. Make sure the CMS either requires unique titles from the CMS user or generates one from relevant database fields.
Make important within-site links trackable
Your site probably has oft-changing feature areas, teasers or cross sells to tempt visitors to jump to a special product or featured content. Analytics programs do a good job of evaluating how well these featured links work, as long as clicks on these links can be separated from the ordinary navigation paths to the featured destinations.
Here's a core concept that will help you help the analytics people: Query parameters in URLs are easy ways to make information available to Web analytics. Anything in a query parameter gets into the raw data for the analysis software.
So, to enable separation of teaser traffic, add a marker parameter to the destination page's URL. A simple example is source=homepagefeature. The CMS should be set up so that cross-sells, teasers and featured-item real estate get this information added to the links automatically. In programming terms, these special bits of screen real estate need to be a separate component type or content type.
A really cool and hip way to do it is to have the marker parameter added only when a mouse button is actually pressed. Detecting a mouse click is an extra bit of work in the CMS setup but it prevents spiders, which do not click, from picking up and listing the amended URLs in search engine results.
Identify traffic to obsolete URLs
You've probably set up a graceful default "File Not Found" (404 error code) page that politely tells visitors that a particular URL no longer exists. Or, you may have implemented a lookup function that will send the visitor to the new version of the page. But have you overlooked the value of recording what destination URLs were being sought and where those seekers were actually sent? If the CMS manages this functionality, it should be created to insert that information as a couple of query parameters in the URL of the 404 page or the redirect page. Remember that anything in a query parameter gets into the hands of the analysts. A parameter called "originalURL=" and another called "redirectedto=" will do the trick nicely.
We've outlined quite a to-do list for marketers savvy enough to have both a Content Management System and a Web analytics initiative. While CMS and analytics software can initially create logistical challenges for your Web operations, once identified and remedied, the combined power and efficiency of a content-managed website along with the deep customer insight provided by an analytics program are well worth the effort. In fact, as competition escalates online and expectations continue to rise, your business and your consumers require every advantage that a cohesive CMS and analytics package provide.
About the Author
Dr. Chris Grant is a Senior Data Strategist at Enlighten, a full service interactive agency structured to design, deliver and measure integrated online brand experiences. At Enlighten, Dr. Grant develops comprehensive analytics programs designed to produce deep customer insight for clients such as Hunter Douglas, Audi of America, Citizen's Bank, and Comerica.