11 Tips for Preparing Enhanced Site Tracking During a Website Redesign
Mark Ryan | September 19, 2013
Top tips on what a web team should consider when redesigning a site, in order to prepare for enhanced tracking.
Often web teams realize that their current site has deteriorated with time and for certain reasons making small improvements on the site will simply not make enough of a lift to justify maintaining the site. They see a great opportunity for a large jump in conversion while achieving other more qualitative goals by scraping most of the existing site and performing a redesign. During the redesign the web team members will often dive in deep to the web analytics to learn everything they can about how prospects, customers, partners, etc. are interacting with the soon-to-be-replaced website.
In this deep dive, the web team consistently realizes one common lesson – they are not getting everything they want out of their current web analytics implementation. While web teams will always have an increasing appetite for data on how their users interact with their web site, at this point in the web redesign process there is a critical opportunity.
Often site tagging is an afterthought in website redesigns. Typically developers insert default tracking tags during the end of development and any real customization of the tracking happens post launch as questions arise about how the new site is performing. To ensure that the new website and new tracking provide heightened levels of insight on prospect and customer interactions, the team must think ahead to align the site tracking with the objectives of the site. Below is a list of items that the web team should consider early during the redesign project in order to prepare the new site for enhanced tracking.
- Establish an Owner: This is a simple step. The web team needs to establish the ultimate owner of site tracking, data for the digital channel, and proliferation and reporting of the data.
- Data Dictionary: Each variable that will be tracked and/or reported on should be defined in a Data Dictionary document. This documentation is sometimes embedded in the sites overall Business Requirements Document. It is often useful to meet with the various departments that depend on the site such as marketing, sales, and customer support to fully understand visitor flows and what data points can show. For each data point the Data Dictionary should define what is being tracked, what data sources are required to track it (i.e. Web analytics, CRM, etc.), and how it will be used to judge/improve the site. Having consensus on the Data Dictionary also helps give focus on specific goals for all other deliverables. This document should also outline the major segments used to interpret the data as well as the priority of different data points in reporting. The Data Dictionary should also set standards in tracking for items such as naming conventions for persistent variables and tracking events.
- Unique and Descriptive URLs: Much of the reporting in web analytics is based around pages and groups of pages on the site. But many sites don't put much thought into the naming of URLs. Folders, files, and subdomains should be named to give the page context. This will also help with SEO. Similar content should be grouped in directories with descriptive names. If one URL can generate multiple renderings of a page based on the state of a session, the engineers will need to create virtual pageviews in the tracking.
- URL Variables: Site owners should plan out how URL variables will affect web analytics reporting. Often times, application servers or content management systems will append a URL variable to help the page determine how to render. For example, some CMS platforms will have a page with a URL like this: www.yoursite.com/content.aspx?id=f9q34hfiha. The ID variable is used by the page to determine which content appears on the page. However, this ID is close to impossible to decipher in web analytics reporting. It's ideal to sit down with the technical gurus that will be building out the nuts and bolts of the site to understand how they will be using URL variables and what flexibility there is to help improve tracking. Often times the team will be able to help in ways such as dynamically inserting a directory into the URL (i.e. www.yoursite.com/product_B/content.aspx?id=f9q34hfiha).
- Clear Styles / Classes: As the site is being built, the engineering team should be thoughtful in how they name style classes and element IDs. This can save everyone a great deal of time as custom tracking is being implemented on the site. When the style/element names are unique and clear, the analyst can often create custom tracking by going into the web container and triggering events for custom tracking based of the styles/element IDs without having to bother the engineers. This type of custom tracking can also minimize the amount of time to adjust tracking tags during testing and post launch.
- Track Errors: Many sites forget to track errors in web analytics. It is important to define all possible errors with the web server and various site applications up front to ensure there are corresponding tracking events.
- Integration of Data Sources: Possibly the most difficult part of web analytics tracking is getting data from multiple platforms. Some examples of integrated data sources might be ecommerce engines, CRM platforms, email marketing, chat tools, survey tools, and call center platforms. It is important that all integrated data sources be identified before development and that all fields be defined so that any engineering efforts can be allocated to populate data into tracking elements such as data layer objects or directly into custom tracking tags.
- Content Management System Configurations: Another commonly forgotten component of preparing sites for tagging is the amount of configuration a CMS needs to enable site owners to properly implement custom tags, along with governance of proper tagging standards. At the very minimum, CMS templates need to be automatically fitted with default tags or a tag container to ensure that as site owners build new pages and templates, the tracking is not forgotten. But it doesn't stop there. Site owners that are creating functions within the site such as forms, calculators, tabs, mapping widgets, etc. need the ability to create custom tracking events within the CMS in a non-technical fashion. This requires some brilliant tagging from the engineers implementing the CMS.
- Hard to Track Files: As the site owners are planning all of the various new content for the site, the analytics owners need to be prepared for file formats that cannot have embedded analytics (i.e. PDFs, Docs, MP4) or links that are not necessarily inside of the site's digital experience (i.e. links to social sites). A global set of functions should be used to track files and links like these to ensure that this type of tracking is never forgotten. This can include a defined method for tracking complex pages on the site with other tags such as session tracking and heatmap tracking.
- Third Party Sites: If the new site is integrated with third party hosted sites such as financial applications, utility tools (i.e. chat, online banking), or third party content the method for tracking those visitors as they traverse through pop-ups, iframes, or off site links will need to be defined either with tags or virtual page views triggered by links.
Of course the tagging, data filtering, custom tagging, report generation, and optimization never stops at launch. This list simply outlines some of the initial steps in preparing a new site for new tracking. While preparation is important, the thirst for more data is never quenched. Web teams should always plan for and allot time for updates to tags and reports post launch.