After my first post on the Kaizen principle, I would like to move on with a more “practical” post. It is the first one of a coming series of posts on “good” practices” (I think it would be pretentious to call these “best” practices as these are mainly based on my personal experience). I will open with a technical-oriented post on content tagging and how you can make your life easier when using a content management system.
You probably know the “famous” Web Analytics cycle (or one of its variations) as depicted in the below diagram. Web Analytics is a continuous improvement cycle of 4 main phases: measurements, reporting, analysis and optimization. Anyone will understand that the first phase is crucial. To take the right decision, you need to get your data right. It is the foundation of any good Web Analytics.
Nowadays, most companies that operate large or multiple websites use content management systems (CMS). This is especially true when you work with several languages or in an international context. I will not go into the details of the main features of CMS’s but in short these facilitate content creation & management by business users, brand image consistency, content replication and localisation (i.e. translation). In short, these are powerful tools for managing websites.
There are several challenges when working in complex web environment when it comes to tagging. These includes among others:
- Completeness & accuracy: you must ensure that all the content produced is tagged (no “hole”) and in a correct way. Otherwise your data may be incomplete and your analysis will be biased.
- Consistency: having standardized rules for tagging is important in order to ensure that your content and sites are measured the same way so you can compare “apples” to “apples”.
- Transparency: the tagging process must be transparent for content managers who are “business” people i.e. non technical. Their involvement must be limited as much as possible to reduce errors (missing tags, wrong values…)
So why not leveraging your CMS capabilities to seamlessly integrate your Web Analytics tags and deliver high quality tagging?
Automatic & dynamic include of page script
- Make the include dynamic: Some parts of the script are specific to each site you are managing. It can be the domain name, the Website ID (e.g. WebTrends DCS ID or Google Analytics account number), the data collector server hostname (if you host your own solution or use aliases)… You should add these elements in the Website properties / metadata in your CMS so the script is set dynamically based on these settings. These are configured by the technical team when a new site or publication is created in the CMS. It will make maintenance easier as you will need just one version of the script for all sites. When you do an update, you have only one file to update on root level. No more copy/paste errors such as one site using the same script of another one or sites that do not have their script updated (“ooops we forgot that one”).
- Add the script on page rendering not on publishing: the tag is usually place in the part of the HTML code. It is often added in the page when it is published from the CMS. Instead you should isolate the script so it is added in the page when the page is “rendered” (i.e. requested). This may require tweaking all your templates but the added-value worth it. Here again, script maintenance and update will be facilitated. When you will update the script, one file will need to be republished instead of every single page of your websites. Trust me, this is quite frustrating to have to republish hundreds of pages just because you change a website ID or domain name. This type of task is time & resource consuming: it has to be scheduled, pages will fail, you will need to test the entire site…Well, you don’t want to do that. Note that while impact on performances should be insignificant, it should be measured and tested first.
Generating custom tags: keep it simple!
In most CMS, when you create a page, you have the content elements (text, links, images…) and also metadata such as product name, template name, template variant and any other custom properties linked to your content.
Now you should try to automate the meta tag / variable definition process as much as possible. Remember, you want to limit CMS user interactions in the tagging process. However you have to do this carefully and in a clever way.
Automate simple & generic rules
You will have to get your hands dirty and do some analysis (or better, have someone doing it for you). Try to identify mapping rules between CMS content / metadata and your WA variables / meta tags.
For example, one variable can be the template name that is used to create the page (product info page, specifications page, gallery page, help page…). If template names are technical ID’s then use a mapping file to translate these into something meaningful in your reports. Content group values can be linked to meta properties defined at directory level (if all pages of a logical group are located under same directory). Product name / category can be linked to the corresponding metadata field if defined in a specific metadata field. Etc. Well, you get the idea….
Start first with the simplest and most generic rules. Also be careful with automation, put some controls to prevent the insertion of invalid characters or value that may generate execution errors or incomplete parameter strings (like the ampersand “&”).
Make sure that you can get a unique & meaningful titles passed to the corresponding WA parameter. Or if difficult, try to have at least that each combination of a set of parameters is unique (e.g. title & content group).
Simplified user input
Large websites are often complex and it will not be possible to automate everything. For some parts, you will have to rely on user input. For example, it can be the scenario name (if page is part of a workflow), a campaign ID, a flag indicating the page is a conversion point… If you do so, here are some tips:
- Easy access to tagging settings: Don’t hide the tag setting fields in areas where Content Managers do not go when creating content. Add the tag setting fields next to other fields / metadata they have to fill so they do not forget to set these.
- Use non-technical language: Keep in mind that content managers are non-techie users, they are business users. So do NOT use fields with labels such as “WT.cg_n”, “utm_campaign”, “Scenario name” but “Content category”, “Campaign Name / ID”, “Workflow name” (or something they can understand).
- Provide pre-defined lists of values: Use dropdown lists of values, checkboxes or radio buttons but avoid free text fields at all costs. Free text fields are wide open doors for errors. For example, you will get spelling errors or different spellings for the same values. Believe me, once the mess is there, it is hard to clean (and it will keep coming back).
- Document procedure & train content managers: Make sure that content manager training cover the tag setting phase and that fields and procedures are well documented (keep it clear & simple). Do not forget to mention points of contact for any support or question.
- Use inheritance mechanism: The use of inheritance mechanisms can help you to limit manual setting at page-level. For example, if the all pages related to a product are under same directory, put the definition of the product on directory level and implement an inheritance mechanism. Upon publishing the system will check if a value is defined at page level, if not it will look at folder level. If no value found then either it stops (so no product parameter is added i.e. a non product page) or it can go up recursively (up to you to see if it can apply to your context). The advantage is that instead of setting this parameter for each page, you do it once at directory level (or any other central place).
The general idea is that you should limit manual input and make it as simple as possible (while keeping control on the output).
To end this post, here are some additional tips:
- Keep doors open for special cases: All rules have exceptions. 100% automation is not possible so you will need to foresee mechanisms or ways to allow special cases. Try to automate 80% of the cases (most common ones) and implement “advanced” functionalities (such as override mechanisms) for the other 20% (or leave this special ones to your technical team)
- Tagging on / off switch: It should be possible to de-activate the tagging (i.e. removing the script from the page) either at page level or global level (all site). Why the hell would you do that? It can be for testing purpose when you don’t want tracking code to interfere in new development testing. Or imagine that for some reasons, the tracking code put down or slow dramatically down your site (it can happen). By just checking a checkbox and republishing one setting file, you can be back online while the issue get fixed. It is better to loose data than customers.
Of course you can do many other things with your CMS like adding tracking code on special items (e.g. to track downloads, offsite links) or tracking navigation usage but it would be too long to detail all possibilities in just one post.
What about testing?
You will need to test your tagging integration. Manual testing on each template during development is ok but it is not manageable when deployed to the complete site. Testing just one or two pages of each template is not enough. You need to make sure everything went well and that all your pages are correctly tagged. There are several solutions: the expensive ones like developing your own tool or using services like Maxamine (now owned by Accenture) and a very good free one (the poor guy’s solution): WASP (Web Analytics Solutions Profiler) from Stephane Hamel. It is quite powerful and very flexible. Try it out before considering any expensive solution. Read Stephane’s post for more details on WASP and tagging quality testing.
All in all a good tagging integration in your CMS can be very powerful. It will make IT life easier whenever it comes to maintenance (like script upgrade) and it can deliver high quality data (completeness, accuracy, less errors…). You will be able to focus your efforts on valuable tasks (KPI’s definition, analysis, optimization…) and not on trying desperately to get your data right.
Here again I advise you to use a Kaizen approach: start with the basic & easy part and implement simpler rules first. When you get it right, move on to the next level as you acquire experience.
So these are some of my “good” practices regarding tagging & CMS integration. Your turn now. What do you think of all these? What are your “good” (or best) practices? Please share your ideas, critics or any feedback.
Related reading & resources:
- “When Content Management Systems Meet Data Analytics” by Dr. Chris Grant (it is from 2006 but it is still a very interesting article on the subject)
- “WASP: a good tool to audit site tags” by Stephane Hamel
- New WebTrends Tag Builder tool, a great tool to set-up your WebTrends tags with advanced features.
Thanks to Chris Grant for letting me borrow her article illustration (opening illustration)