Blogpost information
- Category: AWS
- Date: 05 March, 2023
- GitHub URL: /
TL;DR
This blogpost will explain the posibility to setup HTTPS link tracking for Amazon SES using your own, already existing, web application. This would save you the hassle from setting up an additional CDN.
To quote amazon; "Amazon SES is a cloud email service provider that can integrate into any application for bulk email sending". This means it is a simple way to start sending out emails to your users.
At some point in your development process, the need might occur to start tracking the amount of clicks and opens that happen on certain emails. The ability to track opens and clicks reduces the stress that comes with uncertainty and helps you to work more effectively and efficiently. It might, for example, give you a better insight into your (weekly) newsletter, or other transactional emails.
Enabling Default Open/Click Tracking
Open/Click tracking is something that can be enabled through configuration (Configuration Set).
You can go to the Amazon SES Console, but before anything, be sure to select the correct region. Afterwards, you can click on Configuration Sets, choose the set to edit, and add/edit your settings on the Event destinations tab. Open/Click tracking can be enabled by ticking the checkbox and will instantly start working for every new email that's being sent out by Amazon SES.
Easy enough, right? All of the links in your email will now be prefixed with http://r.REGION.awstrack.me. The reason being is that every click will first be proxied through AWS to increment the open/click counters, before forwarding to your original destination.
You can go to the Amazon SES Console, but before anything, be sure to select the correct region. Afterwards, you can click on Configuration Sets, choose the set to edit, and add/edit your settings on the Event destinations tab. Open/Click tracking can be enabled by ticking the checkbox and will instantly start working for every new email that's being sent out by Amazon SES.
Easy enough, right? All of the links in your email will now be prefixed with http://r.REGION.awstrack.me. The reason being is that every click will first be proxied through AWS to increment the open/click counters, before forwarding to your original destination.
HTTP Custom Domain Tracking
It is critical to change the standard AWS tracking URL as many of your users will be using adblockers and anti-tracking services. The standard URL used by AWS is blocked by any decent adblocker, meaning your users will either not be able to click the links in your email, or will be required to go through an extra step confirming that they want to visit the URL.
This is why you also have the option to use your own domains, rather than a domain owned and operated by Amazon SES.
This is why you also have the option to use your own domains, rather than a domain owned and operated by Amazon SES.
The setup for this exists out of verifying your click domain on AWS, and linking a CNAME DNS record to http://r.REGION.awstrack.me. More information about this setup can be found in the Amazon SES Setup Documentation.
HTTPS Custom Domain Tracking
While setting up open/click tracking is relatively simple for HTTP, setting it up to support HTTPS can be a bit more cumbersome. The Amazon SES Setup Documentation includes pretty extensive information on the setup to support this, however, this also includes setting up a CloudFront distribution with Amazon Certificate Manager, and using the http://r.REGION.awstrack.me as an origin.
This looks roughly as schematically represented on the right.
While this solution contains a perfectly working setup, it also contains an extra AWS component which could be avoided. What if we already have a website running on EC2/ECS/Fargate/EKS/...?
Let’s throw this into a schematic overview. As you can see on the left, we already have an existing application already supported by HTTPS. In our example use case, we use an Application Load Balancer in combination with Amazon Certificate Manager to support this. Keep in mind that you can also use a single EC2 machine with LetsEncrypt or HAProxy. The idea remains the same, we will use our existing HTTPS supported web application as a HTTPS Proxy for our open/click tracking.
To achieve this, create the open/click tracking DNS record with a CNAME for your existing application. If you are already forwarding everything (example *.domain.com) to your application, no further action is required here.
To achieve this, create the open/click tracking DNS record with a CNAME for your existing application. If you are already forwarding everything (example *.domain.com) to your application, no further action is required here.
Next up is making sure your application can redirect the requests that happen from click.example.com to http://r.REGION.awstrack.me. This completely depends on your application. In my example code I will use a PHP framework, which can redirect everything from click.example.com, to a separate controller. In this controller, we are then able to forward the requests.
The example cost exists out of creating a Guzzle object, and passing along all the parameters using a request made to the AWS SES Tracking domain.
And that’s basically it! HTTPS Open/Click tracking will now work through your existing application, avoiding the need to include a CloudFront distribution in between.
And that’s basically it! HTTPS Open/Click tracking will now work through your existing application, avoiding the need to include a CloudFront distribution in between.
