Today we’re launching a new Chrome extension, called Tracker Blocker, that is a companion extension for GMass. If you’re using GMass to send campaigns, you should also install Tracker Blocker so that your open-tracking reports are as accurate as possible.

Get it now!

Install Tracker Blocker from the Chrome Web Store.

What is it?

The Tracker Blocker extension was created to solve a longstanding problem that GMass users have — triggering “false” opens when they open an email from their Sent folder. GMass, or any other Gmail-based campaign sending tool, sends emails directly from your Gmail account, and as a result, they are logged to your Sent folder. It’s impossible, however, to distinguish your contact opening the email in their Inbox versus you opening the email from your Sent folder. Other scenarios may also lead you to opening the email and triggering an “open”, such as:

• Opening an email from your Sent folder
• The email bouncing, and then you opening the bounce notification
• Someone replying to your email, and then opening the reply
• You set your campaign to create DRAFTS, and then open a DRAFT for editing

The Tracker Blocker extension prevents these “false” opens by preventing the browser from registering an open on your own emails.

Give me the basics!

This extension is a simple extension that blocks network requests to our open tracking server. This prevents false opens from registering if you open an email you’ve sent with GMass.

Click the black GMass icon in the upper-right of your browser to open the settings panel. If you don’t see the black GMass icon, then click the “puzzle piece” icon, find the Tracker Blocker extension in the list and “pin” it.

There are two checkboxes to toggle, one to block pixels and one to notify you when a pixel is blocked. Obviously if you have the “Notify” box checked but the “Block” checkbox unchecked, you won’t be notified of anything.

If the “Block” box is unchecked, then opens will register. Perhaps you’re a new GMass user, and you want to test the open tracking functionality to see how the reports look. In that case, you may want to leave the box unchecked. The “Block open-tracking pixels” box must be checked though to enable the pixel blocking functionality.

You can test the blocking functionality and prove its working with a bit of technical wizardry. First open up Chrome’s Developer Tools by right-clicking anywhere in Gmail and choosing “Inspect”. Then navigate to the Console tab. NOw open up an email sent by GMass that you know has an open tracking pixel. Once you do, you’ll see a line appear in the console that looks like:

GET https://ci4.googleusercontent.com/proxy/mbvlSfX7TS0l48CkU54uxsc97v37z7XfcbDWLwQkg9OCbq4wuXGEIv5mxst6... net::ERR_BLOCKED_BY_CLIENT

You may find that when you open an email that has the pixel, that three network requests are actually blocked, and as a result, three browser notifications popup on your computer. We’re not sure why this is, but we suspect that Gmail is specifically trying three times to load an image when it detects a problem. Unfortunately that’s not something we can control.

Additionally, if you’re having opens logged to the Label GMass Reports–>Opens, you will notice that a notification won’t appear here with Tracker Blocker running.

Are you notified when a pixel is blocked?

Sometimes.

Notifying you, the user, when a tracking pixel is blocked, is difficult, due to recent updates to Chrome. Our Tracker Blocker extension is built on the latest Chrome extension specification, called Manifest V3, and this latest specification does not, by default, allow our code to fire an “event” whenever a pixel is blocked. Therefore, it’s not possible to reliably alert you when a pixel is blocked, unless you have Chrome Dev Tools open and you’re monitoring the Console, as shown above.

We have implemented a workaround to the limitations in Manifest V3, however, that will allow pop-up browser notifications to alert you when a pixel is blocked, some of the time. Why doesn’t it work all of the time? It has to do with something called “service workers”, and the fact that in Manifest V3, it’s not possible to keep “service workers” alive persistently. Whether we can notify you when a tracking pixel is blocked is dependent on whether at the time of the pixel block, the service worker for our extension is active or not. Unfortunately that’s not something Chrome gives us full control over yet.

If you want to make sure you’re alerted when a pixel is blocked, then:

1. Make sure the “Notify” box is checked in the settings panel for the extension.
2. Uncheck and re-check the “Block open-tracking pixels” box, because each time you do that, the service worker is activated for a few minutes, which will allow you to receive notifications

The notifications also aren’t fool proof because there are several operating system and browser-level controls that can prevent notifications from appearing, so if you want to know for sure that the extension is working and blocking pixels, you can do so by opening up Chrome’s Developer Tools and following the instructions above.

I thought GMass’s open tracking pixel was unblockable…

If you’ve kept up with GMass’s developments over the years, you might recall that in 2021, we re-programmed our open tracking pixel to make it unblockable by pixel blockers. This generated quite some controversy, as you can tell if you read the comments in that blog post. In order to allow Tracker Blocker to block the GMass open tracking pixel, we did have to modify the URL pattern of the pixel. It is now slightly blockable, but only if you know the pattern we’re using, and to our knowledge, we’re the only ones that know the pattern.

Will pixels be blocked on mobile devices?

Because Chrome extensions, by their very own nature, only work on desktop operating systems and not on mobile, it is simply not possible to block open tracking pixels from firing on mobile devices. This includes native email client apps like the Gmail app and logging into webmail clients using a web browser on mobile devices.

How do other email outreach platforms solve this problem?

All email outreach platforms that connect to Gmail face this same issue of allowing “opens” to be triggered by the user opening up their own Sent email. If the platform is a Chrome extension like GMass, then it likely includes pixel blocking functionality that is based on Manifest V2, and that functionality will stop working in 2023 when Chrome disables V2 functionality. Examples of these types of Chrome extensions include SalesHandy and Mixmax.

If the email platform is entirely web-based, then there’s simply no way for the platform to prevent false “opens”, unless the platform also offers a Chrome extension that can block pixels, and none of them do. Examples of these platforms include the cold email tools Mailshake and Lemlist.

Interestingly, a popular Chrome extension called MailTrack, which adds tracking to individual emails, solves this problem in a unique way. MailTrack adds a tracking pixel to all individually sent email, but instead of blocking the pixel from firing if the user opens a sent email, MailTrack quickly deletes the entire message from the Sent mail folder and replaces it with a new message that doesn’t have the tracking pixel. This achieves the objective of preventing the user from firing their own tracking pixel. This is a creative approach that isn’t feasible for an email outreach platform because using this same technique would triple the time and processing power needed to send each individual email, due to  the additional steps of deleting the Sent email and re-inserting it. See our article about MailTrack’s approach to creatively solving other challenges.

Frequently Asked Questions:

Q: If GMass users can use this for more accurate open tracking, can’t email privacy advocates also use it to stop us from tracking their opens?

A: Yes, but we suspect that the use case for privacy will be limited. We’ve concluded that by analyzing other Chrome extensions that also block tracking pixels and seeing that their install count isn’t particularly impactful.

Q: Why didn’t you just bake the pixel blocking functionality into the GMass extension instead of creating a whole other extension we have to install?

A: Because Tracker Blocker is based on new Chrome extension technology, called Manifest V3, that Chrome is now requiring, and baking it into GMass isn’t possible anymore. Furthermore, we plan to support competitors’ platforms and block their pixels as well, so it made sense to make this a different extension entirely.

Q: Aren’t there other pixel blocking extensions already in the Chrome Web Store? Why did you create your own?

A: There are other pixel blocking extensions, such as Trocker (10,000 users) and Ugly Email (90,000 users) and PixelBlock (90,000 users) but in analyzing them, we found that they’re a) not supported well, b) they haven’t been updated in a long time, and c) they’re based off of the older Chrome extension technology (Manifest V2) that will be phased out in the coming year. That means, eventually, all of these extensions will just stop working, unless their developers decide to rewrite them.

Q: What’s the difference between the old extension technology (Manifest V2) and the new extension technology (Manifest V3)?

A: There are a lot of differences, and you can read about them directly from Google here, but the main difference that applies to software that blocks network requests, as Tracker Blocker does, is that in Manifest V2 this was done via a Chrome API called webRequest, and in Manifest V3, webRequest is no longer available, and now a new API called declarativeNetRequest must be used. You may have heard about the controversy surrounding this change when Chrome first announced Manifest v3 because at the time, it affected the ability for ad blockers to work. The differences between the two APIs are explained on the Chromium blog and in the official developer docs.

Ajay Goel

Ajay is the founder of GMass and has been developing email sending software for 20 years.