Email Newsletter Advertising has a Scale and Format Problem

Email newsletter advertising has a scaling problem. Sponsorships delivered as native HTML earn everyone more money but are difficult to implement en masse. Display ads are easy but less effective.

In fact, with the current state of email newsletter advertising in 2024, it is unlikely that very large advertising agencies and the top-tier brands they represent will make significant investments in creator newsletters as a channel unless email service providers (ESPs) become more involved.

Big Advertisers Need Scale

Amazon spends more than $6 billion a year on advertising. Walmart invests something like $2 billion. Apple spends, perhaps, $1.3 billion. Oh, and Capital One also sends around $1.3 billion annually on advertising, according to a 2023 AdAge report.

These are some of the most desirable brands, and nearly every email newsletter creator would love to have direct placements from them. But the scale doesn't work.

Certainly, there are a few celebrity creators who would be of interest to, say, Capital One as a sponsorship partner, but the 90th personal finance newsletter on Kit or Beehiiv is not.

The brand's agency of record cannot keep up with dozens or hundreds of creator newsletter contacts, relationships, and ad deadlines. They need a way to place email newsletter ads in bulk.

Please do not misunderstand. Many great brands are now and will continue to be very willing to work with lots of newsletter creators. These brands fall into the small-and-mid-sized business (SMB) range or are in a niche that makes it challenging to advertise otherwise.

Rather, I am arguing here that before top-tier brands and the advertising agencies that represent them can invest in email newsletter advertising in a significant way —think hundreds of millions of dollars— it must be relatively easier for them to place ads at scale.

One barrier to scale is ad format.

Newsletter Ad Format

As of July 2024, two ad formats dominate email newsletter advertising —native HTML and display.

Native HTML

In the email newsletter context, a native HTML advertisement is built just like the newsletter itself. The headline, copy, call-to-action, and image are all discrete HTML elements.

I found an example in Eric Partaker's Peak Performance Insights newsletter. Each and every part of the ad was a separate HTML element.

At some point, when Partaker or someone on his team was preparing this newsletter, that individual manually added the sponsorship, typing out—or at least pasting—the headline, copy, and CTA. That same person also had to manually upload the image.

In the case of Partaker's newsletter, this native HTML ad is a sponsorship. It earns the special sponsorship designation because it represents a personal connection between Partaker and the brand —a personal endorsement. Partaker has taken a picture with the product—yes, that is him in the photograph—and included a personal message.

"I struggled to sleep well during a big chunk of my life, so I'm always on the lookout for ways to further improve the quality of my sleep. Oxa, the sponsor of this week's newsletter, approaches the problem in a unique way."

Sponsorships are the gold standard for email newsletter advertising. Compared to other kinds of ads, they earn the most revenue for newsletter creators and are likely to generate the best results for sponsorship brands.

Native HTML newsletter ads are not always sponsorships. This format is also very popular for relatively small newsletters running revenue-per-click ads.

Here is an example from the RadReads newsletter, which is the work of content creator Khe Hy. This advertisement from Rosetta Stone is not personalized, rather, it is "advertiser written."

This advertiser-written version is the type that we would love to have scale for huge brands.

Display Ads

Display ads in email newsletters are single HTML image tags with tracking and targeting parameters.

Here is an example of what that image tag might look like in skeleton form.

<div class="advertisement">
    <a href="...">
        <img src="...&clkk=UNIQUE_ID">
    </a>
</div>

The crucial part to notice is the image tag's src parameter, which points to the ad server.

When a subscriber opens the email newsletter, a "call" is made to retrieve the ad image. Because the image has a unique ID —which is very often the subscriber's email address in a privacy-safe format (hash)— the ad can be aimed at the individual subscriber.

The display ad's image tag can be added to an email newsletter template once and deliver advertisements without any continued or manual intervention.

In June 2024, Google Ad Manager added beta support for email newsletter display ads just like this. Companies like LiveIntent and Paved have similar implementations.

Native HTML vs. Display

Native HTML and display ads each have specific advantages and disadvantages that have a powerful impact on how email newsletter advertising will work at scale.

Performance. I was involved in a short series of tests that compared identical brand-written copy from several different brands, delivering half of the subscribers a native HTML ad unit and the other half a display ad unit. Over the course of about 15 million ad impressions, the native HTML ad generated between 50% and 300% more ad clicks.

Ad impressions. Display ads are images, so any subscriber who has images turned off will never see the ad. In contrast, the native HTML ad unit has real text associated with it, so it does show up.

Even when a subscriber has images turned on —which is the typical case— ad blockers may remove email display ads, but I have never seen an ad blocker remove the text of a native HTML ad.

Deliverability. While over the course of a few billion ad impressions, I have not seen a significant impact on email deliverability in general, I have seen ad format impact some specific newsletter creators. For example, a newsletter author with about 750,000 subscribers and a stellar sending reputation saw a 5% reduction in open rates when using the display ad format. This single data point is anecdotal but concerning.

Scaleability. As of July 2024, native HTML ads must be placed manually and individually. This is a limitation of the email standard itself and is unavoidable. Display ads can be placed automatically, even when the copy is unique.

Ad targeting. Because native HTML ad units are not scaleable, they are also not targeted. Almost exclusively, a native HTML ad unit is shown to the entire subscriber base for a given edition of an email newsletter. Display ads in email can be aimed at individual subscribers.

The native HTML unit is better because it is performant and visible more often. Display works at scale and can target individual subscribers in the same way advertisers can with most performance ad campaigns.

ESPs

Email newsletter advertising has a scale problem because its best ad unit —native HTML— does not work at scale and cannot be aimed at specific subscribers or even groups of subscribers.

The trouble is that the native HTML ad unit can only be placed before an email newsletter is sent. The newsletter creator has to add it manually.

This manual step means that if email newsletter advertising —as an industry— wants to be able to send HTML at scale, ESPs will need to integrate ad placement directly into their sending process.

Let's compare the current process of placing a native HTML ad in a newsletter to what I am proposing. Assume we are using brand-written copy consisting of a headline, body or message, and CTA. There is also an image. Both the image and the CTA will point to a tracking-enabled link.

Here is the current creator-centric process.

• The brand sends creative assets to the creator.
• The creator writes the newsletter and individually places each component of the ad one at a time.
• When the newsletter draft is ready, the creator sends a "proof" of the ad to the brand.
• The brand confirms that the assets are correct and approves the proof.
• The creator schedules the newsletter.
• The ESP builds the newsletter.
• The ESP sends the newsletter.

In this current process, notice that a human must manually place the native HTML ad. This typically requires sending a proof so that a brand representative can click the links and double-check the copy.

Next, you may not realized this, but the ESP has to "build" the newsletter one subscriber at a time —this is important, so I will repeat it. The newsletter is built individually in HTML for every subscriber.

ESPs build outbound email messages this way for several reasons, two of which are tracking and personalization. For example, ESPs all report when a specific subscriber opens an email message or clicks a link. In order to have subscriber-level reporting, there must be subscriber-level tracking. Similarly, if the message says "Hello Bob," "Hello Fred," or "Hello Juan" at the top, the ESP's server will need to iterate over each message, personalizing it before sending it.

Given this fact, there is an opportunity to send native HTML email newsletter ads at scale. Here is what the basic process could look like.

• The creator makes his newsletter available for native HTML ads, building a one-time ad template complete with fonts, colors, and styles.
• The brand submits creative assets to an ad server, like Google, LiveIntent, or any demand-side platform.
• When the ESP builds the newsletter, it sends a request to the ad server via an application programming interface (API). The request is unique to each subscriber so that the ad can be targeted.
• The ESP places the native HTML ad in the newsletter, employing the ad template.
• The ESP sends the newsletter.

In this scenario, huge brands like Amazon, Apple, and Capital One have access to the performant native HTML ads at scale.

Potential Problems

In my opinion, this approach to sending targeted, native HTML email newsletter ads at scale could unlock millions of dollars in revenue and make email newsletter advertising relatively more interesting to top-tier brands and agencies.

There are, however, at least a couple of serious problems with having ESPs place HTML ads at the time of sending.

Ad Timing

The first problem concerns when the ad assets are delivered.

Imagine the performance ad buyer at some big agency placing a campaign on the Meta Ads platform. The campaign —let's call it Awesome Campaign— has a $50,000 per day budget and will run for five days.

When someone opens the Instagram app, an algorithm matches Awesome Campaign with that user, and the ad impression follows within nanoseconds.

The Meta Ads server can easily manage the daily budget because it knows precisely when the ad impression will occur.

Now, let's consider the same campaign but in an email newsletter.

The ESP starts building the newsletter at 5:00 am on the fifth day of the Awesome Campaign. The ESP's server makes an API call to the ad server and is matched to the Awesome Campaign assets.

All is well, except one subscriber is on vacation. He loves the newsletter, but it will be three more days before he opens the email.

Another subscriber has never opened this particular newsletter message and, therefore, never saw the ad.

How does the ad server count these impressions? If Awesome Campaign is charged every time an API call is made, it is overpaying. But, if it is only charged when an actual impression happens, it could go over its daily targets or have ads "appear" outside a campaign window.

Sending Emails

A second problem has to do with the time it takes to send an email message.

For my proposal to work, the ESP must make an API call to the ad server for every subscriber on an email newsletter's list. Or, at the very least, it would need to send the ad server a list of all of the subscribers and get an ad assignment for each as a massive batch.

Let's imagine for a moment that the average response time from the ad server was 50 milliseconds. This delay before the ad server responds following the API request is latency. Put another way, each request adds 50 milliseconds of latency to the email message-sending process.

To be clear, the API request process is not linear, meaning that one request immediately follows another in time. Rather, the requests can be made in parallel —at the same time. But let's make the point.

If an ESP sends one billion individual email messages per month, which is not a lot, it would add a year and a half of latency to its email-sending process each month.

Conclusion

Email newsletter advertising has a scaling problem, in part, because the most effective ad unit at its disposal —the native HTML ad— does not scale. Thus, as an advertising channel, email newsletters may not be able to break into the "big time" and attract huge, well-known brands and the massive amount of advertising dollars they bring.

ESPs can solve the scaling problem if they partner with ad networks, but this task is not easy.

In the meantime, many newsletter creators will still be able to earn a nice living working with brands in the SMB range.