Sending Mapify’s newsletters and notification emails
Yingchen Liu
Newsletters and account notifications leave from two domains. Each language and audience has its own list, and a template engine replaced a day of hand-built email.
- Email systems
- Mailing lists
- Templates
01
Mapify writes to people in more than one kind of email
Mapify is an AI app that turns documents, videos, recordings and web pages into visual mind maps.
Some of those messages are newsletters: a language, an audience, and a send that many people receive together. Others are notifications about one account, including the code that binds an email address or deletes the account. A welcome, a payment, or a cancellation is a third kind: one person, one event.
Those messages used to be written by hand. A new email took about a day of a developer’s time, and marketing had to explain the change through that conversation. The sending platform and the template engine are what replaced that.
02
The problem
A newsletter and a notification email have to stay apart. People can ignore a newsletter, or mark it as something they did not ask for. The code that proves someone owns an email address, or that they mean to delete the account, still has to arrive. Putting both on one domain lets a newsletter complaint affect the mail that the account depends on. Mapify uses two domains for that reason: mail.mapify.so for newsletters, and hi.mapify.so for those account codes.
The second problem is who the newsletter is for. Mapify writes in more than one language, and it writes to people in different relationships with the product. One shared list would send a Japanese newsletter to an English reader, or a subscriber’s note to someone who has never paid. Each combination needs its own mailing list.
The third problem was producing the email. Before the template engine, a developer built each message by hand. That took about a day, and the brief had to pass back and forth between marketing and engineering. A small copy change waited on that conversation.
03
One message, two questions before it leaves
Architecture
The domain decides which reputation carries the message. The list and the template decide who receives which language.
The domain
Which sending domain should carry this?
A newsletter and an account code share a product. They do not share a domain.
- 01
Send the newsletter from mail.mapify.so
Bulk newsletters, and the product messages that people can unsubscribe from, leave from this domain.
- 02
Send the code from hi.mapify.so
The code that binds an email address, and the code that deletes an account, leave from the other domain and the other key.
- 03
Switch them separately
Newsletter sending and notification sending each have their own switch, so one can pause while the other continues.
The message
Who receives which version?
Language and audience pick the list. The template engine picks the words.
- 01
Put them on the right list
Each language has its own lists for people who never subscribed, people who used to, and people who subscribe now.
- 02
Render it from the template
One definition supplies the subject and the HTML. Marketing can change the message without waiting a day for a hand-built email.
- 03
Send it on the same platform
A test send, open and click tracking, and unsubscribe all use the Mailgun path that the real send uses.
How I implemented it
The sending platform is Mailgun, with one sender for each domain. The template engine takes a template name, a locale, and the variables for that message, and it returns the subject and the HTML. The same engine renders a test send. Opens and clicks are tracked on the send, and an unsubscribe link is added to the messages that allow it.
Lists live on mail.mapify.so. The newsletter lists are split by language and by whether the person has never subscribed, used to subscribe, or subscribes now. A dry run can walk the same path and record the send without delivering it. The saved conversation between marketing and engineering became a template change: the definition is the message, and a missing variable or language fails before anyone receives it.
04
The decision
I split the sending identity and the content. mail.mapify.so carries newsletters and the product messages a person can unsubscribe from, such as a welcome, a payment, or a cancellation. hi.mapify.so carries the verification codes, with a separate Mailgun key. Each side can be switched off on its own.
A person is placed on the list named for their language and their status. Changing language takes them off the old lists and onto the lists for the new language. Unsubscribing removes them from the lists they were on.
The decisions that shaped the system
- 01
Give newsletters and account codes different domains
Newsletters leave from mail.mapify.so. A verification code leaves from hi.mapify.so, with its own key, so a newsletter complaint stays off the domain that must deliver the code.
- 02
Give each audience its own list
A person belongs to the list for their language and their relationship to Mapify: never subscribed, formerly subscribed, or currently subscribed. A language change moves them.
- 03
Generate the email from one definition
The template engine produces the subject and the HTML for each language. A missing variable or translation fails before the send.
05
What improved
A newsletter complaint stays on mail.mapify.so. The account code still leaves from hi.mapify.so. A reader receives the list that matches their language and whether they subscribe. A new message is a template and a locale, so marketing can revise the words without booking a day of engineering time to assemble the email by hand.
06
What I learned
The hard part of email is the sending identity and the audience. The template is what makes a change cheap. Once those three are separate, a newsletter, a verification code, and a translated product message can share one platform.
Takeaways
- Send newsletters and account codes from different domains.
- Give each language and each audience its own mailing list.
- Generate the message from a template so a copy change does not take a day.