Reading Time: 4 minutes
Google Analytics has recently launched their Autotrack options – a series of plugins designed to enhance the standard tracking implementation. Sites currently using just the standard Google Analytics base snippet are likely going to see the most benefit of these plugins, but there are a couple of other issues Google Analytics is using these plugins to try and solve for (such as single-page applications and device orientation). The plugins are a way for additional data collection without extensive custom development or making the jump (yet) to Google Tag Manager.
The trackers and what they collect
eventTracker
- Similar to in-line event tracking, but removes the need to manually write an event listener. The event components are added to the site markup, so when the desired action occurs, the event components are sent directly to GA.
- Data details – will populate in the event tracking report with the details you have defined.
mediaQueryTracker
- Allows for collecting greater granularity of media devices types and configurations, such as orientation (landscape, portrait), breakpoints, and resolution. Evaluate the experiences your audience is getting in different views and how response your responsive design truly is for your visitors.
- Data details – populates within the custom dimensions report (e.g. landscape/portrait).
outboundFormTracker
- Sends an event when it detects that a form has been submitted on a different domain (yes, that includes subdomains as well). Think about a site registration. A user is on your site, perusing the content, and decides to register. The user has entered their contact details and hits Submit, blissfully unaware that the registration form is actually on your subdomain.
- Data details – Category: Outbound Link, Action: submit, and Label being the value of the action attribute.
outboundLinkTracker
- Identifies when a link has been clicked that would take a user away from the current domain. The bounce rate does not tell us if someone left our website because they hated it or actually moved to a tangential part of our experience. With this plugin, we will be able to see that the user actually clicked off our site to go to a partner site who has a link present. Therefore, the user is still engaging as we’d want them to, just in a different way than the bounce rate would historically lead us to believe.
- Data details – Category: Outbound Link, Action: click, and Label being the value of the href (the url where the link is pointed to go).
socialTracker
- Appends tracking for social interactions to Twitter and Facebook actions, specifically tweet, follow and like/unlike. Really, this gives a shortcut to having to create a distinct tag for each network or action by dynamically populating the event components.
- Data details – Category: network, Action: like/unlike/tweet/follow, and Label URL of the current page.
urlChangeTracker
- Detects changes in the URL via the History API and updates the tracker to send a pageview. The primary use will likely be for single-page applications and those with a dynamic content population. Please note, however, this plugin does not capture hash changes.
Sounds great, are they worth it?
Well, yes and no. These plugins can be a great option for sites that are only using the basic Google Analytics implementation that wants to dip their toes into gathering more data (or simply do not have the time, resources, budget, etc. for a more robust solution right now). This could also be a great solution for single-page applications.
But there are some (big) considerations. Not all plugins are supported by all browsers (IE and Firefox being the most finicky with the plugins). If traffic from those browsers is important to your business, evaluate the plugin to ensure it will not skew the data being collected.
If you are moving to Google Tag Manager or already have a custom implementation in place (whether small or extensive), use caution. Many of the plugins are duplicative of tags that are standard modifications or part of a regular GTM implementation, and proper testing should be done in the case of custom implementation to ensure conflicts are not being introduced.
Additionally, these plugins are meant to work with the Universal Analytics (analytics.js) snippet. If your site is still using gs.js, highly recommend you plan to upgrade to the newer tracking version sooner rather than later. There are many benefits to updating your tracking code beyond being able to use these plugins (such as how the data is collected and processed, additional reporting features, etc.).
And as always, this does not remove the need for a solid analytics and tracking plan. If anything, it makes having a tracking plan even more necessary to account for the additional data that has been set to automatically collect. A knowledge repository or even a data collection grid for what tracking (code, tags, plugins) is in place can go a long way later when someone asks what is being collected, or where certain data came from.
Why this is such a big deal
The concept of a ‘standard’ tracking implementation has just been very twisted. For many companies, a basic tracking implementation was placing the Google Analytics tracking snippet (also called the pageview snippet) on each page and calling it a day. With auto track and a few more moments of your developers’ time, a multitude of data points quickly become available. At that point, it seems that the question becomes which plugin(s) to use. No longer is it enough to just know how many users came to a site and what pages they viewed. While GA’s standard tracking is robust, it is no longer enough. Autotrack helps to bridge that gap for many companies, and in time, redefine what is ‘standard tracking’.
For more details:
https://ga-dev-tools.web.app/
https://googledevelopers.blogspot.com/2016/02/introducing-autotrack-for-analyticsjs.html
https://github.com/googleanalytics/autotrack/#usage
