Introduction

Currently, there is no ideal mechanism to track user engagement across emails. This is a quick primer on the current three main alternatives, with their own pros and cons:

 - Message Disposition Notifications (aka read receipts): read receipts are implemented by adding a Header to your emails that lets email clients know where to send a read receipt. Their implementation varies from email client to email client, and while it is the "technically correct" solution, they can be ignored by users and disrespected by some email clients.

 - Link Tokens: link tokens are uniquely identifying variables that are inserted into links present throughout the email to let an application know once a user clicks on them. They are the most respectful implementation out of the three, but they have severe disadvantages. They can only be used in emails with links for a user to click on, and they only work if a user actually interacts with the email.

 - Tracking pixels: tracking pixels are discreet or outright invisible links to images that are added to an email. Taking advantage of the underlying concept of the Internet as a connected mass of dependencies, an email does not require that all of its content reside locally. By having an image reside in a server and requiring clients to fetch it, it's possible to know when a client has opened an email in order to load its dependencies. The most efficient technique out of the three, in that clients must disable all email images in order to avoid tracking. It has been somewhat neutralized by image caching servers as shown by Gmail, but still a good solution if all you need to know is if an email has been opened. This is what the component implements in an OutSystems context.

Component usage

Emails sent by the platform have a unique ID that is available once the email has finished being generated. This is convenient for email tracking and identification, but a little awkward codewise, since we need a unique token to be sent into the context of an email, and the email ID once it has finished generating. This is a quick example of what an email implementation will look like with this component:

We need a unique Token to act as our identifier inside the email (outputted by the GenerateNewTrackingToken Action), and once the email has finished processing, the Email action will output a Sent_Email Id, which is used by the platform to track emails. Our unique Token and this Sent_Email Id must be used as inputs for the BindTrackingToken Action in order to successfully register a tracking pixel that will await user interaction. Inside the Email, all that is required is to include the TrackingToken webblock, and use the generated tracking token as an input:

For a working example, you can consult the TrackingTest page inside the Demo module. It also includes a simple backoffice, should you wish for a quick way to consult this information. Otherwise, you can construct one to suit your needs by using the EmailTrackerToken Entity residing in the EmailTracker_CS module.

FAQ

1. I sent an email and opened it with my favorite email client, but my tracking token did not update. Is this a bug? What's happening?

There's really only one reason for this to happen - the image within the email did not load. This can happen because email clients are smart enough not to load images without user permission. Check to see if your email client is blocking images by default. If it never attempts a download, the tracking token will never update.

For reference, I've tested this in the Gmail web client and the latest version of Thunderbird. Both worked, but Thunderbird blocks images by default and offers users the decision to unblock them. If they decide not to, email engagement cannot be tracked with the pixel tracker technique.

2. Why didn't you include the other two techniques in this component?

I think the best way to measure user engagement is indeed using a mix of the techniques in the Introduction section. However, the first technique is usually frowned upon: in my experience, users view Read Receipts as either too formal or outright rude. They should not be used in a marketing campaign or in most communications. Link tokens would require applications to send their HTML into this component so it could send emails on their behalf (very impractical), or for applications to inject their own tokens - in which case, they are better off managing their own engagement instead of relying on a component. This component implements the more practical of the three techniques in a manner that has the least impact for your existing applications.

3. Why don't you provide a Try Now link for this?

This application relies on sent emails in order to generate and display data. As a user, for a practical demo you'd want to send an email to an arbitrary email box and then check the Read status in the backoffice. In order for this flow to work, I'd have to provide my OutSystems environment as a public email service, and this won't happen for security reasons. Please install it in your infrastructure and perform a quick test with the available Test page.