As we start projects and need to gather data to help inform strategy and design, we often need to add new custom tags to web applications that are already built. Because we don’t necessarily have direct access to the engineers that originally developed the applications we commonly run into hurdles caused by the fact that the original developers never thought about tagging the web applications. Below is a list of 11 simple steps/processes that application engineers can take to make tagging easy.
- Unique URLs: Much of web analytics tracking is based on page URLs. Make sure that dynamic pages, forms, and filters have unique URLs. When URLs follow standard SEO best practices, it is very helpful to analysts. For example, www.yoursite.com/productcategory/product is much better for tracking than www.yoursite.com/page?id=704077.
- URL Variables: When web applications use URL variables to communicate the state of the session (i.e. search queries, filters, customizations) this is great for analysts. Consider the following URL, www.hotelsite.com/denver/findaroom.aspx?startdate=7/14/12&enddate=7/17/12&pref=nonsmoking. From this one URL, the analyst can see the intent of the visitor (finding a room), the location, the duration of the trip, how far out the trip is being planned, and the smoking preferences of the visitor.
- Tag Container: Once applications are implemented, it can be tricky giving analysts access to the necessary files for updating page tags. Setting up a tag container will decrease the amount of time and resource needs to add/optimize site tracking.
- Styles / Classes: Much of the custom tracking in analytics today can utilize classes and style elements to manage tags from the tag container. Ensuring that all of the major elements (links, headers, form elements, menus, etc) have unique classes will help the analysts track visitor behaviors without requiring application engineers to update the code on the site.
Define Custom Tracking Early: Before implementation begins, the analysts should document all default and custom tracking. This documentation should be reviewed with the engineering team. This important step accomplishes some basic successes:
- Source to Sale to Support tracking can be accomplished as the engineers understand what back-end data needs to be tracked in the web analytics (i.e. SKUs, customer IDs)
- Tagging Tactics are learned by the engineers. Sometimes it is hard to understand that web applications developed with server-side scripting are very different than web analytics functions created with client-side technologies. It’s great for the application engineers to get an early understanding of how tagging is implemented.
- Integration of Data Sources: Before site development begins, the analysts and the engineers should identify all disparate systems that need to contribute data for effective tracking. For e-commerce sites this would include inventory systems, financial systems, CRM, and possible customer satisfaction surveys. Support sites, promotional sites, investor sites, career sites, etc all require data from external sources.
- Video: More and more video content is appearing on all types of sites and site developers often forget to tag/track this highly interactive content type.
Content Management System: When possible the engineers should implement auto-tagging through the content management system so that content developers do not have to be mindful of tracking. Good CMS development can auto tag event tracking such as button clicks, video plays, scrolling, and drop down menu usage.
- Errors: A commonly overlooked aspect of analytics is tracking any errors that visitors encounter. Engineers should be sure to use analytics tags to track all errors including zero search results, application errors, authentication time outs, form errors (i.e. required fields) and broken URLs.
- Assume Post-Production Updates: Testing helps minimize production errors in tagging. But production data and usage always uncovers bugs in custom tracking code. The majority of the time, these bugs are unnoticeable (even undetectable) by visitors/users and quality assurance team members. The team should assume that the analysts will need access to the tags post launch to make fixes once live data is brought into the system.
This is definitely not a complete list. But following these simple steps will significantly improve the teams ability to understand how visitors interact with a site/application and will decrease the amount of time needed to gather the right data post launch.