For enterprises that send email at a large scale, Marketing Ops is faced with a difficult question: How do you ensure that the millions of emails that need to be sent every day get out quickly and reliably? This problem is compounded by the facts that large amounts of data are required to produce millions of emails, and the data is frequently divided among multiple databases across the enterprise (purchase history, customer profile, client support, etc.). For these organizations, it’s imperative to respond to real-time changes in data (such as recent purchases or interactions), and corporate firewalls often determine that marketing data needs to stay on premises.
If this describes your organization, your choice boils down to two options to fulfill your operational needs. You can either:
At first glance, the choice may seem like one of convenience — looking deeper, though, reveals there are drastically different outcomes depending on the route you take.
Let’s look at how each strategy might play out in a typical situation. For the sake of this example, let’s assume your audience size is 10,000,000 recipients, each recipient’s size in the database is 1 KB, and your email template is 100 KB.
Using Sendgrid or Sparkpost
Most API-based email delivery platforms expect users to send fully formed and rendered email templates in singular transaction-based API calls, or to use their proprietary email-rendering languages to personalize each email. This requires substantial integration between the Marketing and I.T. departments to ensure your rendering capabilities are functioning correctly, or learning the ins and outs of the email language your ESP is using to render each email.
After you’ve gone through the process of rendering all 10 million emails, you still have to send them to your ESP for delivery — and this is no easy matter. Using our assumptions above, we have a data transfer of:
(100 KB rendered email template) x (10,000,000 recipients) = 1,000 GB of data!
Transferring 1,000 gigs of data takes bandwidth, but that means it’s going to take a significant amount of time for your on-premises infrastructure to send the data to your ESP, and for your ESP to get your emails out quickly. The only way to speed this process up is to scale your infrastructure, which is going to eat your budget and force more integration with your I.T. department.
In the end, you’re left with three choices:
Using Bulk Sending Capabilities
Instead of sending email via many transactional API calls, another strategy is to send mail through a large bulk mailing. A cloud ESP designed to render and send large bulk mailings cuts down the cost and effort in this process by addressing the issue of scale up front. By allowing your ESP to take care of both rendering and deliverability, you are able to make a single transmission to the cloud with your recipient list and unrendered template. Using our example above, this leads to a data transfer of:
(One 100KB un-rendered email template) + (10,000,000 recipients x 1 kb per recipient) = 10 GB of data
The 99% efficiency improvement removes the need to scale up on-premises infrastructure, and lessens your dependence on additional IT resources.
But Which ESP?
Although many ESPs can claim to offer the benefit of build over buy, there are many things to watch out for to ensure you’re choosing the right one. For instance, many ESPs force you to use proprietary personalization tags to insert recipient data into an email and do other limited customization. These languages may be incomplete, or lack documentation. MessageGears uses the open source Freemarker templating language (with a robust development community ) for message personalization.
Additionally, MessageGears delivers on the promise of being the only true hybrid solution — allowing all data to remain on premises, with no contact lists or data stored in our cloud. Knowing how important data is to decision making, engagement analytics for each send are available in real time, providing you with access to the most valuable resource a marketer can have.