In recent years, it’s become increasingly popular for people to use some sort of browser extension to blocks ads, trackers, and other unwanted scripts from loading on the websites they browse every day.
People are generally adopting these browser extensions to reduce bloat from advertising platforms that slows down their experience of the web, and to protect their privacy while online.
Part of our business has always been around collecting and analysing analytics data such as browsing behaviour, pageviews and custom-triggered events. We don’t collect this to be shady or creepy, to sell onto third parties, or to sell to advertisers – we do this to help our customers build better websites, products, and give their customers a better experience.
But we’re aware that some people don’t want to share this data with anyone, and that’s a reason for them to use some of these browser extensions. If you’re interested, we’ve shared our thoughts on content blockers before.
We firmly believe it’s important that we respect visitors’ intentions around blocking this tracking, while also not breaking the experience for other parts of the GoSquared platform – in particular, Live Chat and other features in GoSquared Assistant.
A brief history of time tracker.js
The GoSquared JavaScript Snippet is the piece of code that all customers of GoSquared embed in their HTML. It looks something like this:
<script>
!function(g,s,q,r,d){r=g[r]=g[r]||function(){(r.q=r.q||[]).push(
arguments)};d=s.createElement(q);q=s.getElementsByTagName(q)[0];
d.src='//d1l6p2sc9645hc.cloudfront.net/tracker.js';q.parentNode.
insertBefore(d,q)}(window,document,'script','_gs');
_gs('GSN-123456-A');
</script>
The purpose of this <script> tag is to load an external script file, tracker.js, which does all the hard work of gathering analytics data from the visitor’s browsing session and posting it back to our analytics backend, which lives on data.gosquared.com.
Historically, before the introduction of GoSquared Live Chat, that’s all this code would do: Gather analytics data for pageviews and custom event data, and send it to our analytics backend.
With the introduction of Live Chat, and more recently, Assistant, however, this code gained some extra functionality. As well collecting and posting the tracking data for Analytics, the tracker.js script now includes logic to load and bootstrap the code powering GoSquared Assistant.
How does Assistant get loaded?
Loading Assistant requires loading two things: the JavaScript module for Assistant, and some configuration for the GoSquared project in question – things like whether the project has Assistant enabled, what the project’s office hours are set to, what Prompts are set up, and which ones match the current visitor.
For reasons of efficiency, the request for this configuration data is combined with the first postback to our analytics endpoint. The backend bundles the configuration in with the response to the first tracking request, and then the frontend code uses that to bootstrap loading of the Assistant JavaScript. It looks something like this:
There’s a problem with this, though. As mentioned earlier, it’s become increasingly popular for visitors to use ad-blockers and tracker-blockers to improve their privacy on the web. The way these blockers work is to look for HTTP requests that match a set of rules and block them at the browser level.
The most popular of these tracker-blocker lists is EasyPrivacy, which includes a rule blocking data.gosquared.com on all sites where it appears as a third-party resource (i.e. any site which has GoSquared installed). This meant that step 1 in the diagram above would be blocked, and the tracker JS would never receive the data it needs to finish loading Assistant.
So how does it work now?
The way tracker.js loads the chat configuration data in the presence of tracker-blockers is now subtly different. If it detects that a request to data.gosquared.com has been blocked, it now attempts to load the data from a different endpoint, but without sending any of the analytics tracking data.
With these updates, visitors can benefit from a subset of Assistant’s features, without any analytics data being sent our way, so we’re addressing the privacy concerns some visitors have around user-level analytics.
The flow now looks something like this:
Are there any downsides to this?
The reason we originally (and still do for the majority of visitors) bundle the request for Assistant configuration in with the first analytics postback is for efficiency – on the front-end, fewer HTTP requests to different endpoints means using fewer browser and network resources, which means a quicker experience, which means Assistant is available and ready as fast as possible.
Splitting out a separate HTTP request means we have to forego some of those benefits in the presence of a tracker-blocker. It also means that some of the advanced rules in Prompts, which rely on analytics data collected by the tracker, can’t function properly without that data. But obviously this is a fair price to pay compared to not having Assistant at all.
What can we learn?
Splitting out the HTTP request for Assistant config onto a separate endpoint in the presence of tracker-blockers means we can now measure exactly how much traffic that endpoint gets. We can then use that to gain some insight into the adoption of content-blockers – at least those that specifically block GoSquared – on GoSquared-enabled sites.
What did we learn?
Our numbers are still preliminary at this stage, but our metrics indicate that roughly 0.8% of visits on GoSquared-enabled sites come from browsers with tracker-blockers.
This number is significantly lower than we might expect, especially based on other reports such as The IAB reporting 22.1% of UK adults and PageFair reporting 11% of the global internet population use ad blockers. There are a few possible explanations for this:
- We’re only measuring the proportion of visits that use a tracker-blocker which blocks GoSquared, rather than all ad-blockers (for example the popular ad-blockers AdBlock and Adblock Plus don’t enable the EasyPrivacy list by default)
- We can only measure those visits that block HTTP requests to our Analytics backend, but not our Assistant backend. To our knowledge this includes all the major blockers, but there may be some that we missed (have you come across a content blocker which breaks GoSquared Assistant which our current method doesn’t fix? Let us know!)
- The demographic cross-section of all visits on all GoSquared-enabled websites may not be distributed the same as in other wider studies.
We’re sure there’s plenty more we can learn as time goes on about the behaviour and usage of these content blockers, and we’ll be sure to write about them in the future. If there’s anything else you think we can learn or write about, be sure to let us know on Twitter!
