Website design & development is a complex process what involves many different aspects. While the focus usually is on visual design, content and functionality questions, some technical details that can impact your digital analytics tend to be left behind.
I would like to share my thought on 7 things worth considering while developing a website to save you from losing user behavior data and making it friendlier for Google Analytics implementation.
Hopefully, it could be a guide for web developers, website owners and marketers to avoid commonly made mistakes and follow best practices as early in the development as possible.
1) Plan a human and SEO friendly URL structure
URLs in digital analytics are the faces of your website pages, so to analyse website content and visitor behavior, page URLs should clearly identify the page.
URLs like these I believe are usually a bad choice: www.example.com/index.php?lang=1&page=43&category=5
By looking at such URL in the Content report, you will have a hard time identifying what this page is about. Such URLs are called dynamic, as they contain parameter names (lang, page,category in this example) and their values.
Far better would be to have a URL like this www.example.com/en/marketing/2015-trends
It is clear that the page is in English, marketing section, contains article on 2015 trend. In the Content or any other report you could easily identify, filter and analyze the data on this particular page or all articles in the marketing section. Such URLs are called static and they are a must-have for a majority of pages.
Popular CMS (Content Management Systems) like WordPress, Drupal and others offer a possibility to have readable static URLs or “clean URLs” – just need to enable it. For custom made CMS systems use URL rewriting options – ask your developers to do it, or google .htaccess URL rewriting.
Then again, you may also need to have dynamic pages – these are the pages that change their content based on previous user actions, like site search page or product filters. If all dynamic pages are generated with the same (static) URL for different user queries or actions, with default Google Analytics setup (without additional tweaks), it will be impossible to track them.
Let’s say you have a site search – user fills in the search form and gets redirected to results page www.example.com/search-results. As you can see, search term is not reflected in the URL, so it won’t be possible to see what exactly users were searching for (again, at least without additional coding). The solution in this case would be to use dynamic URLs and pass search query like this www.example.com/search-results?s=search+query
Now you could configure Site Search report and if this parameter is important for technical reasons and useless for analysis, like session id, you can easily exclude URL query parameters in Google Analytics. In such cases, using dynamic links would be more suitable.
To round up, some good URL practices:
- Use static readable URLs for static pages. Bonus: they also are better for SEO and users!
- Stick to a chosen URL structure. If similar pages have different URL path structure, like www.example.com/banana-article for one article and www.example.com/articles/cooking/grape-article it will make your reports hard to analyse. Choose one structure and stick to it. Hint: better to display category or section names in the URLs, to analyse both specific pages and all content within a specific category or section.
- For multilingual sites, have separate URLs for each language, with a 2-3 letter language code in the beginning or the URL path. If language change is not reflected in the URL (yes, is it rare, but can be seen from time to time) search engines will have trouble with indexing your webpage correctly, you will have difficulties with different language ads campaigns (no URLs for a specific language versions ). Also you won’t be able to know which language version visitors were reading.
- Use dynamic URLs for dynamic pages or to pass additional parameters, like search term for site search results, filters, transaction id or other dynamic parameters that are important for you to analyse or website to function.
2) Know some basics on how JavaScript and AJAX impacts Google Tag Manager and Google Analytics.
JavaScript is a programming language used for different interactions with the webpage, like validating a form without reloading a page, switching tabs, running image sliders, showing modal windows and etc. It is also used by Google Analytics to sent data to GA servers.
AJAX (Asynchronous JavaScript and XML) is a way to exchange data with a server and changing parts of a web page without reloading the whole page. While “simple JavaScript” can work only with the data loaded into the browser, AJAX allows to connect to other data sources and update some parts of the page, like when you scroll your Facebook Timeline and see more and more new content is being constantly added below.
Let’s start with impact on page tracking. By default, Google Analytics tracks page views that are loaded in the browser window and trigger Google Analytics page tracker. When user generates an actions what occurs in the background, without actual page reload, Google Analytics can not identify and track it. As a result, you won’t get data on JavaScript/AJAX forms, content sliders, filters, content tab clicks, paginators, modal popup interactions and other interactions.
If such dynamic content without URL change is needed, virtual pageviews or events can be used to send a “forced” hit and track actions undetected by a standard GA tracker. This will require developers to add some additional JavaScript code in the source code of the web page and/or (better) using Google Tag Manager (GTM).
While Google Tag Manager allows a Digital analytics specialist to configure Google Analytics with a much lesser client IT team involvement, that makes life easier for all, still there are some things to consider. Without going into technical details, just make sure you are using preventDefault() function instead of return false when overwriting default element action, for example on form submit button or modal window links. This will guarantee the correct tracking as return false will block the event from firing.
Most popular example for additional code necessity are AJAX forms, to know when the form was submitted. Some Worpdress contact form plugins can be easily configured to send a GA event or GTM Data Layer, which is really awesome. Sometimes you can also add a small JavaScript code snippet to a “Thank you” message, what will be invisible to visitors, but will track an action.
So if you are planning to have a lot of JavaScript/AJAX fueled interactions that you want to track to understand user behavior, better to consult with a Google Analytics specialist or an agency to come up with a tracking strategy & solutions.
3) Have a clear action confirmation page or message for each action
Both for the sake of analytics and better user experience, website should provide confirmation messages or pages after such actions as email subscription, contact form submission, purchase and others. And these can (must) be tracked as goals to evaluate conversions from different campaigns and traffic sources.
I would generally advise to have separate URLs for confirmation (aka “Thank you”) pages, reflecting the result of the action.
Example: there is a purchase form on www.example.com/checkout page. If the action presumes more than one scenario, like purchase was successful or failed, there should also be separate URLs for each scenario. Here you can use both dynamic and static URLs:
- Successful purchase URL – www.example.com/checkout?status=success or www.example.com/checkout/thank-you
- Failed purchase URL – www.example.com/checkout?status=failed or www.example.com/checkout/failed
This way you could easily configure Google Analytics goals for successful purchases and will be able to analyse the quantity and traffic sources separately for failed and successful actions.
With a separate page (URL) it will be easier, as this will require only goal configuration via the interface, as for the inline/modal messages you will need to add additional JavaScript code to sent a hit to Google Analytycs.
Having these actions tracked gives you more valuable data to analyse. And website visitors will have more trust and confidence while using your website, if they will see a clear confirmation after actions made.
4) Don’t truncate query parameters when redirecting a landing page
If the page has redirects, like from non www to www domain, or after moving a landing page to a new URL, make sure query parameters (it’s what goes after a ? symbol in a link) are not truncated. Losing Google Analytics utm or AdWords gclid parameters due to redirects will cause Google Analytics to identify traffic source and campaign not in the way you wanted and lose valuable data.
To avoid this, check landing page URLs for redirect and make sure Google Analytics/AdWords tags are not being cut off. And please save query parameter by default when developing URL redirects.
5) Use class and id attributes on clickable elements
To identify a specific element you want to track (with GTM Listeners or custom selectors) you can use clicked element id or class. If the clickable element, like a hyperlink, has no class or id attributes, you will need to look for workarounds – sometimes using element URL is an easy path, while in other situations you will need to identify by element parent class and do other JavaScript coding. So by adding classes or ids to clickable elements, Google Analytis setup will be much easier.
You should use the same classes to group similar objects (like all call-to-action buttons) and unique classes or ids to identify unique elements. For example, to separate footer and header call-to-action buttons.
Still, some situations will require adding JavaScript inline, as an onclick action or inside some JavaScript function.
6) Avoid using iframes for the main content
Sometimes iframe use is justified, like for embedding videos or 3rd party widgets. But you generally wouldn’t want to embed a whole page or an important part of the content. Using iframe for the main page content may generate multiple pageviews and if iframe content is on a different domain, screw referral data. Here is the topic on iframe in Google Analytics help center.
Fortunately, iframe websites are (almost) extinct, and this won´t be a popular issue.
7) Create new Account for a new client, not Property
Google Analytics has the following account hierarchy:
![Google Analytics Account Structure [via support.google.com]](https://www.apasters.com/wp-content/uploads/2014/11/ga-structure.png)
A proper way would be to always create a new Account for a new business. Only exception may be if creating a separate tracking code for the same client (for a new campaign promo website or app), then new Property use would be justified.
You can learn more about this in the Analytics Academy lesson with Justin Cutroni.
Conclusions
Often, especially if using different pre-configured content management systems, not everything from the mentioned list is possible to make (or not needed at all) . There are ways how to adjust Google Analytics & GTM and overcome technical obstacles – some problems can be solved easily, some may require a bit of “hacking” or IT team involvement.
Most important, in my opinion, is to understand the goals of the website and from the early stages (before presenting a finished iframe-ajax-onepage-flash website with poor usability) collaborate not only with web developers, but also Marketing, Digital Analytics, SEO, User Experience/Conversion and Design/UI specialists, to create a website what will be a marketing and sales tool, not a barrier.
Update in 2016: I’ve made a checklist for Google Analytics and GTM Friendly Website Development.