Key takeaway
Email marketing metrics are the counts and rates your platform reports back about a send: delivery, engagement, list health, revenue. Almost all of them are your own system describing your own sending to you, which makes them good at spotting a change and poor as a verdict. Take 10,000 delivered and 200 clicks: click-through reads 2%, click-to-open reads 10%, and nothing about the send differs. Only the complaint rate carries a published threshold, so I read it first.
What email marketing metrics are, and which of them decide anything.
An email marketing metric is a count or a rate describing one send, and it comes in only four kinds: did it arrive, what did the recipient do with it, did they stay on the list, and was it worth the money. That definition is the same on every platform, and it hides the thing that matters. Almost all of those numbers are your own system describing your own sending back to you, which makes them very good at spotting a change and useless as a verdict, because nobody outside your account ever agreed what a good one looks like. A small number are different, because somebody who can stop your mail is counting them too and has published the line they expect you to stay under. That split is the whole page.
I've spent a decade building email platforms, and the pattern I see most is a team presenting a fifteen-line scorecard every month, arguing about the click rate, and not noticing the one line that was about to cost them the inbox at a major provider.
You still have to report something upward, and "only one metric matters" isn't an answer anybody can take into a meeting.
Metrics do not stop at the inbox. The software follows subscribers onto the website. I laid out the mechanics on SaaS District: we capture "clicks, product clicks, add to carts" across the storefront. We tie those actions back to an email address. This data decides what a subscriber sees next.
The four groups every metric falls into.
Whatever your tool calls them, every email metric is measuring one of four things, and knowing which group a number sits in tells you who it's for.
- Delivery: whether the message reached the mailbox at all. Delivery rate, bounce rate, and inbox placement.
- Engagement: what happened after it arrived. Open rate, click-through rate, and click-to-open rate.
- List health: whether the audience is still an audience. Unsubscribe rate, complaint rate, and list growth rate.
- Revenue: what the send was worth. Conversion rate, revenue per email, and return on the program.
The four groups answer to different people, and that's the useful part of the grouping. Delivery and list health are read by mailbox providers, and they decide whether the next campaign arrives at all. Engagement is read by you and by whoever writes the subject lines. Revenue is read by whoever pays for the program. A scorecard that mixes all four together without saying which is which is how a team spends a quarter optimising a number nobody outside the company can see.
What the grouping can't tell you is what a metric is worth, because two tools can report different values for the same metric on the same send and both be right.
Why two tools report different numbers for the same send.
Every email metric is a fraction, and a fraction is only defined once both halves of it are. Click-through rate is clicks over a denominator of messages. Click-to-open rate is clicks over recorded opens instead, which is why it always reads higher and why the two can't be swapped for one another. As a worked example, take 10,000 delivered, 2,000 recorded opens, and 200 clicks: the click-through rate reads 2%, the click-to-open rate reads 10%, and nothing whatsoever about the send is different between those two numbers.
Three choices decide what a platform prints.
- The denominator: messages sent, or messages delivered. Bounces move the rate either way.
- The numerator: unique recipients who acted, or every action counted separately.
- The window: clicks counted for a day, for a week, or forever after the send.
Three binary choices are eight possible definitions of one metric. A rate copied out of one platform and set against a rate from another is comparing two different questions, and the gap between them says nothing about either send. Held constant inside one account, though, the same number is one of the most useful things you have: the definition cancels out and the movement is real. That's the case for caring about your own trend and ignoring everybody else's average, and it holds right up until the event underneath the metric changes, which is what happened to the open.
Open rate stopped measuring an open.
An open is recorded when a one-pixel image loads from your server. That's the entire mechanism, which means the metric was always measuring image loading rather than reading. It worked well enough for years, because loading the image and reading the message were roughly the same event.
They aren't now. Apple Mail downloads remote content in the background by default, whether or not the recipient engages with the message, and routes the request through two relays run by different entities, so the sender learns neither the recipient's IP address nor the moment of any real open. The pixel still fires. It fires for a machine.
Read the number for what it now measures. Open rate is largely a proxy for how much of your list sits on a mail client that pre-fetches images, so it moves when your list mix moves rather than when your writing improves. It stays genuinely useful for one job: detecting a delivery cliff. When opens fall to near zero across a whole send, mail isn't arriving, and that deserves an alert at three in the morning. Treat it as a smoke alarm, not a score. Apple wasn't the last mediated inbox either. Gmail's AI-generated summaries let a reader learn what a message says without opening it, and I now check that noise against authentication and reputation before trusting an open number at all.
You probably arrived wanting to know what a good open rate is. That question has its own page, and the only honest answer is a baseline built from your own history.
The one number a mailbox provider publishes a threshold for.
The complaint rate is the share of delivered messages that recipients mark as spam, and it's the only metric here whose acceptable value is published by somebody other than you. Gmail and Yahoo both wrote theirs down and both enforce them on the way in. The rules step up for bulk senders, which at Gmail means more than 5,000 messages a day to Gmail addresses.
- The complaint threshold: Google asks senders to keep spam rates below 0.3% in Postmaster Tools, with under 0.10% recommended, and Yahoo publishes the same 0.3% line.
- The authentication that comes with it: SPF and DKIM for bulk senders at both providers, plus a DMARC policy on the sending domain.
- The unsubscribe that comes with it: one-click unsubscribe on marketing mail, honoured within two days at Yahoo.
Everything else on a reporting screen is an internal opinion about how the send went. This one is a line drawn by an outside party, and crossing it has a consequence you can't argue your way out of: mail starts landing in the spam folder, or stops being accepted at all. That's why the complaint rate belongs at the top of a scorecard rather than at position twelve of seventeen, and why it's worth reading per send rather than per month. It's a small enough number that one bad import can move it inside a single campaign.
It's also a lagging measure of a list problem, and the same problem usually shows up in the bounce log first.
A bounce is two different events wearing one name.
Hard and soft isn't a vocabulary convention platforms agreed on. It's the class of the status code the receiving server returned, and both classes are defined in the mail standards. A 5.X.X code is a permanent failure, one that isn't likely to be resolved by resending the message in its current form, so something about the message or the destination has to change first. A 4.X.X is a persistent transient failure, where the message as sent is valid and some temporary condition delayed it, so a later attempt may well succeed.
That gives you a rule instead of a feeling. An address behind a 5.X.X is suppressed on the first occurrence and never mailed again, because retrying dead addresses is how a sender reputation and a complaint rate come apart together. A 4.X.X is retried on a schedule and suppressed only if it keeps failing. Both are decisions your sending path should be making without asking you.
A single blended bounce rate hides which of the two moved, which makes it close to useless as an alert. Split it before you chart it. Suppression itself, the rule that keeps a dead address out of every later send, has its own page.
The same metric means different things on a broadcast, a flow, and a transactional send.
A broadcast goes to a segment at a moment you chose. An automated flow goes to one person at a moment they chose, triggered by something they did. A transactional message answers something they did seconds ago and is often one they're actively waiting for. The audience, the intent, and the timing are different in all three cases, and every rate on the page moves with them.
Rates climb as the recipient's intent climbs, and they climb steeply, so a triggered message and a monthly newsletter can't be averaged into one program number without the send mix quietly deciding the answer. A campaign performance figure that improved because the flows sent more mail this month hasn't told you anything about your campaigns. It's told you the mix changed. The fix is dull and it works: split the reporting by send type first, then compare each type only against its own history.
Send type is the first cut. The second is the receiving domain, because a drop concentrated at one mailbox provider is a delivery problem while the same drop spread evenly across all of them is a content or list problem, and those two need opposite responses. Most reporting screens don't offer that cut at all.
Pick five metrics, then query them instead of watching them.
Five is enough, and the order matters as much as the set.
- Complaint rate, because it's the one with a threshold somebody else enforces.
- Bounce rate, split hard from soft, because it moves before the complaint rate does.
- Delivered volume by receiving domain, because it localises a problem the other four only hint at.
- Click-through rate against your own trailing history, because a recipient had to do something real to produce it.
- Revenue or conversions per send, because the program has to be worth running.
Then stop watching them. A dashboard shows you the last send, and every question actually worth asking is a comparison across sends: did the click rate drop across the whole list or only at one domain, did complaints move before or after the list import, is this flow ahead of where it was six weeks ago. Each of those is a query rather than a screen, and that difference decides whether you get an answer when you think of the question.
That's the reason we built Nitrosend the way we did. It's MCP-first: every capability is an API endpoint and an MCP tool before it is a screen, so the stack answers to the agent operating it instead of waiting for somebody to click through tabs. A platform built screen-first can't answer a question that spans forty sends, whatever gets bolted to the front of it, because the screen only ever holds the last one.
Measure the five, and put them where you can ask about them.
You now have five numbers to watch and a reason for each, and the awkward part is that watching isn't really what you want to do with them. Nitrosend specialises in email, and your agent can ask it for the complaint rate on a send, the hard-soft bounce split, or delivered volume by receiving domain. The free tier is 8,000 emails to start, then 500 a month, with unlimited contacts, full MCP, API, and CLI access, and no credit card.
Go deeper
Sources
- Google, Email sender guidelines: keep spam rates reported in Postmaster Tools below 0.3%, with under 0.10% recommended, and the bulk sender line of more than 5,000 messages a day to Gmail accounts.
- Yahoo, Sender best practices: keep the spam rate below 0.3%, implement SPF and DKIM with a DMARC policy, and honour unsubscribes within two days.
- Apple, Mail Privacy Protection and Privacy: Mail downloads remote content in the background by default regardless of engagement, and routes it through two relays operated by different entities.
- IETF, RFC 3463, Enhanced Mail System Status Codes: the 5.X.X permanent failure class and the 4.X.X persistent transient failure class the hard and soft bounce split is derived from.
Common questions
Five, in this order: complaint rate, bounce rate split hard from soft, delivered volume by receiving domain, click-through rate against your own trailing history, and revenue or conversions per send. The order is deliberate. The first three have consequences outside your account, and the last two are how you judge whether the program earns its place.
They share a numerator and differ in the denominator. Click-through rate divides clicks by messages, and click-to-open rate divides clicks by recorded opens, which is a much smaller number. Click-to-open therefore always reads higher, and the two aren't interchangeable. Quoting one against a figure calculated the other way compares two different questions.
Not on its own, and it's the cheaper of the two ways for somebody to leave. An unsubscribe takes an address off your list and stops there. A spam complaint about the same message tells the mailbox provider something about your sending, and that one has a threshold published outside your account. Read the two together: unsubscribes climbing while complaints stay flat usually points at cadence or targeting, and both climbing at once points at the list itself.
The only comparison worth anything is against your own trailing rate for the same send type. A broadcast, an automated flow, and a transactional message produce numbers that can't be averaged together, so split them first, then read the last several sends of that type. A rate moving against its own history tells you something. A rate held up against somebody else's list doesn't.
Yes, as a delivery alarm rather than an engagement score. An open is recorded when a tracking pixel loads, and Apple Mail loads remote content in the background by default, so a large share of recorded opens no longer correspond to anybody reading. What the metric still does well is show a delivery cliff: when opens fall to near zero across a send, mail isn't arriving.
It's the wrong question, because a blended bounce rate covers two different events. A 5.X.X status code is a permanent failure, and that address should be suppressed on the first occurrence and never mailed again. A 4.X.X is a transient failure, so it's retried on a schedule and suppressed only if it keeps failing. Split the two before you judge the number.
Revenue attributed to email over the cost of running the program, where the cost is platform fees plus the people and agency time behind the sends. The attribution rule decides the answer more than the arithmetic does: a seven-day window and a thirty-day window credit email with very different shares of the same revenue. Pick a window, write it down, and keep it.
On two cadences. Complaint rate and bounce rate are read per send, because both can move inside a single campaign and both have consequences at the mailbox provider. Engagement and revenue are read on a trailing window across several sends of the same type, because one send on its own is too noisy to draw a conclusion from.