With every new website launch, we track how users browse and interact with the site. We do this to gain insight into customer behavior. These days, optimizing websites based on real audience data is essential. When done well, it leads companies to the promised land – more customers, better engagement, and increased conversions.
To be useful, the information we measure and report includes a small handful of key performance indicators. Yes, I am talking about – Clicks, Bounce Rates, HVTs (High Value Tasks) and KPIs. This implies a degree of flexibility to respond to client demands on the part of the analyst and the developer. They are responsible for providing the client ways to improve these metrics and make the marketing campaign successful.
If You’re Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late
Reid Hoffman, Founder of LinkedIn
In general, any kind of data collected about visitors requires designing and implementing thoughtful triggers for custom events that will serve as markers for the user journey on the site. For example, once a browser event takes place we like to record the activity. Then, a piece of code is run and the information is saved and processed. That functionality already exists in commercially available libraries like Google Analytics and its competitors. Analytics frameworks are widely used today; figures about the usage of Google Analytics, for example, show that the number of sites that rely on its features has increased sevenfold in the last eight years.
Exactly what is Google Analytics tracking?
Although analytics libraries have become quite popular, they come at a price in terms of what users can accomplish with the resources they provide. If you have Google Analytics, for example, you know the core events it provides information can be fairly limiting.
According to Google they track the following in GA:
- Time spent on site
- Time spent on each page
- Order of internal links visited
Other information includes referrer sites, geolocation, operating system etc. Google is coy about these and places them in a separate paragraph and somewhat understated fashion.
Some of Google’s competitors – like Hotjar – offer visually appealing features like heat maps that capture clicks, taps and other behavior.
Challenges
Now imagine your latest project is to develop or implement a marketing campaign for a client. Suddenly you realize the data provided by Google’s Analytics is not sufficient or detailed enough. To make important decisions, whether it is for providing an optimal user experience or a successful digital marketing campaign, we need to better data.
One way to approach this challenge is to fall back on open source plugins and custom extensions for Google Analytics. Depending on requirements, this is an option for some developers. Customizations in existing plugins can be great (up to a point) to give more traction with custom events. Indeed, with open source libraries developed to extend Google Analytics features hooking up your updated plugin to a Firebase or MongoDB instance is a cinch and all the data at your fingertips.
Autotrack is a JavaScript library built on top of the analytics.js. It makes it easier for web developers to track the user interactions that are common to most websites. This is one extension for Google Analytics the Google Analytics development team maintains. It is available on github. It features, for example, a plugin called impressionTracker that determines which elements are visible in the viewport. If an element on the website is not visible and the user scrolls to the element, an event is triggered and information sent to Google.
Analytics and Custom Solutions
So far so good, but even this may not be enough to address all the questions and concerns a client might have, as we at Gulo found out.
Imagine that you need to track how much time the user spends on a given page, say, reading the text. That is, measure user engagement based on a combination of factors like scroll events, time it takes to read the text on the page, time it takes to fill out a form or complete a survey, and then decide which of a number promotional modals to trigger on which pages.
Imagine further you would like to track a type of user engagement. This particular KPI for engagement might live in a modal on a specific product page. If we deems the user as “engaged” because they visit a sequence of pages, spent a period of time on the page, or even repeatedly visit the page, we need to track whether the user subscribed to newsletter or viewed the same page a certain a number of times. To exclude any of these conditions without causing major revision in said plugin is a major headache.
As a developer, you have two options: either build a solution from scratch or integrate with existing libraries and preface your grand integration with caveats about its limitations.
Our Approach
Here at Gulo we chose the former approach that allowed us to extend and fine-tune quantitative research into behavior well beyond any previous work in this area – well, that clearly isn’t not true. We did nothing particularly revolutionary and yet we achieved much.
We did not have many limitors, our only one being our own knowledge and skill of JavaScript and JavaScript frameworks. Out of a range of options when it comes to JavaScript frameworks, we went a traditional route ensuing the results would integrate well with WordPress development and the other client’s websites we’ve built over the years. We carefully examined the client needs and built all the necessary triggers around them. Then we hooked up the key engagement points we aimed to track.
The plugin is complete open-source and supports passing a litany of configuration settings. Frontend developers can pass configuration options without having to worry about the implementation details. Setup is fully-automated and very flexible.
What went wrong?
We discovered our processes were not as automated as we originally conceived it to be; configuration settings had to be added, adjusted, and removed; conflicts with other JS libraries had to be fixed, conditions pertaining to specific data we were targeting – how to measure an abstract concept like engagement – but overall we are quite happy with the initial version of our plugin.
What we got right?
We simplified the workflow at Gulo. Made significant progress in terms of deployment time and ease of deployment. For example, instead of moving files from one project to project (I know, embarrassing), we made the available on npm (access it on npm or contribute on Github), installable with all the dependencies with a single command.
Most importantly, we obviated the need for subscription services that provide similar functionality.
