Email marketing from tech perspective
My name is Andrei Rebrov, and I’m CTO at Scentbird. Earlier my co-founder Sergei wrote an article about our initial growth. Influencers market is one among others channels we use; another one is email marketing. It may seem strange why tech guy writes an article about such topic, but there is a very simple explanation of that. Email marketing is not about sending X amount of emails to bring Y clients and annoying Z of them, it’s all about data — when, whom, what, why, how and how many times. And as a software engineer, I can gather and analyze all data about our customers and build a good system that sends an email at the right moment with a right subject and clear call to action to the right person.
If you want to see current state of email marketing you can open your spam folder, and you will see something like this:
You will see spammy offers, fishy subjects, massive discounts, etc. Every day we receive tons of email that were sent without any sense. That’s why let’s start with the common understanding of email strategy. First of all, there are two types of emails: mass emails and transactional.
Mass emails
- Promo
- Discounts
- New features
- etc.
Trigger emails
- Abandoned cart
- Abandoned subscription page
- Update offers
- etc.
In other words, we use mass emails for delivering the same message for the big group of customers, and trigger emails usually have unique and personalized content. Let’s talk about each of this group in details.
Mass emails
I believe some of you are familiar with the legend of golden antelope. Many centuries ago in India that was a boy who found an antelope that was able to create a golden coin by knocking her leg on floor. One day they were captured by greedy Raja and he asked that antelope to start producing gold. Antelope agreed with one notice — if this Raja would say ‘Stop’ all coins became mud. He laughed and started yelling ‘More, more, more!’ Until he was buried with gold. As you can image right after that, he said ‘Stop’ and died. Happy end.
Why am I telling you this story? Because some companies use the same approach with their emails. They see that X emails bring Y customers and decide to send more emails. It works on the little perspective. But eventually, all these emails become mud because people unsubscribe, mark emails as spam, create filters or just ignore them.
Segmentation
So there are several rules or guidelines how to avoid it. First of all, you should use segmentation. Some simple segments that we use:
- Source of email
- Region / Time Zone
- Is this user our subscriber or not
- How long this user is our customer
- Open rate
- …
The source of email — we can obtain an email from different sources, for example, a customer can register on our website, from a giveaway, from partners. By the way, I don’t recommend buying email lists for several reasons:
- You never know quality of this list regarding conversion and terms of validity of emails
- Mail servers may detect higher volume of outbound emails and decrease you trust level
- Service that you use may question you about source of this emails (we got such question from Amazon SES)
Region/Time zone — it’s no a secret that people open email more often in certain time periods during the day. That’s why if you work in several time zones you might be interesting in delivering emails at the same time.
Is this user our subscriber or not — trust me, you don’t want to be in the situation when your existing customers get offers better that they had, especially if they paid the full price.
How long this user is our customer — this is about loyalty and higher LTV. There is a big chance that this category might be more open for different upsell offers.
Open rate — another type of segmentation that might affect you trust level. As far as I know, some email providers detect when you don’t open emails from the same contact for a long time, and then they start to mark it as a spam automatically.
You can, and I think you should add segments related to your business because it will give you more agility in what you are doing.
Email quality
Next thing I want to talk about is email quality. (Actually, this block is also applied to trigger emails as well.) And it’s not only about the copy, but it’s also about many different things:
- Spam content
- Image size
- Layout
- Broken links
- Fishy links
- Digital signature
- Domain trust
- …
Spam content — usually the core example of machine learning is spam detection. If your email contains typical phrases like: ‘Limited time offer’, ‘Unique opportunity’, ‘Enlarge your business’ and stuff like that it is more likely your email will go to spam.
Image size — I know, some of you want to send beautiful high-res images, but people today mostly check emails from their phones, and they don’t usually have LTE or wi-fi.
Layout — You should be careful with services that create an email from PSD template by slicing an image into many pieces. It’s a good way to start but when you a big find a person who can create nice HTML layout. Moreover, some mobile phones may not download images for ‘security reason’. When I was using Windows Phone it was super annoying.
Broken and fishy links — check links in your emails every time. If email provider detects broken link it might be a reason to block your email. Also, every domain you use in your email should be verified.
Digital signature — one of the most simple thing to do, but people usually forget about it. Find how to configure SPF and DKIM signatures for your email tool (Mandrill, Mailgun, Amazon SES). It will take about 5 minutes but will help you a lot.
Domain trust — you should periodically check you sending domain/IP for blacklisting. You can find most of the blacklists here. Usually, if you see your domain blacklisted, you can contact administration to exclude you.
There are couple of tools that you can use to check your emails: mail-tester.com and litmus.com
Tools
Now let’s talk about tools. Obviously, there are a lot of services that allow sending mass emails: SendWithUs, Mailchimp, etc. We started with Mailchimp, but it becomes quite expensive for a small startup as we were. So we found great self-hosted solution — Sendy.
Most interesting features (for us):
- It uses Amazon SES, so the pricing is excellent (https://aws.amazon.com/ses/pricing/)
- Simple and useful reports
- Automatic bounce, complaint & unsubscribe handling
- Autoresponders
As I said Sendy is a self-hosted solution and installation is quite easy:
- You will need apache2 (Nginx), PHP and MySQL
- Download and unpack archive
- Go to http://yourdomain/sendy and follow instructions, it will ask for AWS Access Key ID и AWS Secret Access Key, so you will have to go to Amazon IAM and create new user
- Verify your domain and emails in Amazon SES
- Configure Amazon SNS topics for email bounce/compliance
- Profit
Also you should configure couple of cron jobs for scheduled campaigns and importing subscribers:
/5 * * * * php /var/www/html/sendy/scheduled.php > /dev/null 2>&1*/1 * * * * php /var/www/html/sendy/import-csv.php > /dev/null 2>&1
As I said before you also should configure SPF and DKIM, so let’s do it.
Amazon SES used SPF by default, and DKIM should be enabled from console.
- Add next DNS record :
TXT | domain.com | v=spf1 include:amazonses.com ?all- Verify you domain as described here
Couple of words about how we work with Sendy. We are sending campaigns, but the most important part is about segmentation. There are some basic segments:
- All users
- Subscribers
- Subscribers who unsubscribed
- etc
To manage these lists dynamically, we are using Sendy API as well as Sendy API extension. Another important thing — if someone unsubscribes in trigger email system, we should also unsubscribe this person in Sendy. The biggest problem with Sendy is performance:
- You should set PHP memory limit to 1 Gb
- There is network limitation, so if your emails are big (convert them to base64 to see an actual size), i.e. 500 kb, you will be able to send around 70 emails per second. So you have to host cluster of Sendy’s
If you don’t want to spent time on configuration and managing you can use hosted solution.
Trigger emails
A person who invented term ‘trigger emails’ has picked the perfect name. As well as a gun trigger you can use it to kill your target or to shoot in your leg.
So as a said if you want to send trigger emails right, you should have data about your users, what they do on your website and what is their current state regarding flow.
Let’s say we are a typical e-commerce business. People enter the site, visit product pages, add something to the cart and finally make an order. So our goal is to guide people to the final step and return them to the flow if they exit at some point.
So how do we do this? We use Mandrill as a tool for trigger emails because it’s easy to use and the price is convenient. They recently changed their price and policy, so it’s better to read it first before you decide to use them.
We can split all trigger emails into two groups:
- emails you sent right after some event (like invoices, refunds, etc. )
- emails to bring customers back (abandonment cart, like us on Facebook, etc.)
Eventually, the second group of emails becomes something that is called drip email marketing (more buzzwords!).
How does it work? You want your customer to do something, in our case subscribe to our service. So you start to send them emails on some schedule. Usually, at some point, you start to give them some offer or discount because it’s better to lose some money than to lose a customer.
Technical implementation is simple:
- create a condition that will help you define customers you want to send email to and convert it to SQL query
- create a scheduled job, which will perform this SQL select and send email
- mark these people so we won’t send these emails twice if our job is interrupted
Couple of advice here:
- make sure you can stop and run these jobs separately if you want to stop any drip for a reason
- it should be easy to change job schedule for every email, so you don’t have to redeploy your app every time
- job service should be separate from the main application because it has different lifecycle
- it’s better to move you Mandrill (or any other service) to the another service as well and use queue mechanism (Amazon SQS for example) because every call to Mandrill is synchronous and it you application will work forever if you want so send 50k emails
- for the same reason it’s better to have to queues — one for regular trigger emails (signup, password retrieval) and another one for drip emails because you send them in a big batch and it will take a lot of time to process them.
It’s also become tricky when customer click on unsubscribe link in your trigger email because you still want them to receive important emails (like invoices) and don’t want to send them drip emails. In this case, you should use webhook mechanism which most of the services provide. And again, if someone unsubscribes from drip emails don’t forget to unsubscribe them from mass emails.
General advice
· Separate domains for trigger/mass emails — it will help to protect trust level for every email group
· A/B Tests — don’t forget to test subject, copy and sending time of emails
· Monitoring — you should see how regular are you sending each email, what is the conversion rate and how bad it is in terms of spam
· Invest time & money in quality — it is your channel for bringing new customers, treat it well
· Treat as a product
That being said I can spend a lot of time speaking about details, but I believe I’ve shared the most important part of our experience.
