How beehiiv Calculates Email Opens, Clicks, and Every KPI It Reports

Everyone knows the dashboard inflates. Apple opens your emails for people who never touched them, bots click your links, and your open rate looks like a victory lap it did not earn. That story has been told a hundred times.

The quieter problem is the opposite one, and almost nobody reports it: real activity that never gets counted at all. A subscriber who reads every word but never loads an image is invisible. A Gmail user who marks you as spam usually leaves no trace in your account. Your most loyal reader who clicks straight through, and your most annoyed reader heading for the unsubscribe button, can both register as nothing.

If you report beehiiv numbers to a client, an advertiser, or an investor, you need to know which direction each metric lies in. So this guide does three things, in order. First, where beehiiv quietly under-reports, because that is the part that will surprise you. Then exactly how every KPI is derived, formula by formula. Then where the numbers read high and swing for reasons you did not cause.

The mechanics you need to follow along are simple. beehiiv tracks two raw events, a pixel load (an open) and a link request (a click), and divides them by one denominator, delivered. That is the whole engine. Now here is where it leaks.

Where beehiiv quietly under-reports

These are the cases where genuine activity happens and the dashboard records less than the truth. Each one matters differently depending on your audience, but together they are the reason a "low" number is not always bad news.

Opens: read but never counted

An open is only recorded when the tracking pixel loads. Any time a real person reads the email without that image firing, you get a genuine read that shows up as nothing. That happens more than people think:

• Images are blocked or off by default. Some clients and corporate configurations do not load remote images automatically. The email gets read, the pixel never loads, no open is counted.
• Plain-text reading. If a subscriber views the plain-text version, there is no pixel to fire.
• Preview pane without remote content. Reading in a preview pane that does not pull remote images produces a read with no open.
• Security and automation layers. A message routed through a helpdesk, ticketing system, or scanner that displays it without loading external images is seen but not counted.
• Caching suppresses repeat opens. Gmail serves repeat opens from cache rather than re-firing the pixel, so your total opens undercount how often people actually reopened the email. Unique opens are less affected, which is one more reason unique is the steadier figure.

The takeaway: your true readership is always somewhat higher than your open count implies. This sits on top of the inflation from Apple, so opens are noisy in both directions at once. For a privacy-heavy or image-blocking segment, the undercount can be the dominant effect.

Clicks: the honest number errs low

beehiiv's Verified Clicks system, which we detail below, is conservative by design. It strips out anything that looks automated, which is exactly what you want, but it means a genuine human click can occasionally get classified as a bot and dropped. Verified clicks is the trustworthy number to report, but understand that it errs low, not high.

Tracking also misses clicks that skip the wrapped link entirely. A reader who copies the URL, types the destination, reads the web version of the post, or clicks inside a forwarded copy took real action that your click data never sees.

Unsubscribes: the metric that hides your churn

This is the conceptual one to internalize. Most disengaged readers never hit unsubscribe. They stop opening, filter you to a folder, or delete on sight. None of that registers as an unsubscribe. A flat, healthy-looking unsubscribe rate can sit directly on top of a list that is quietly going dead. That is why open-trend decay across many sends tells you more about attrition than the unsubscribe line ever will. The absence of unsubscribes is not proof of engagement.

Spam reports: the Gmail blind spot

Spam complaints are the most under-reported metric of all, and the reason is structural. Yahoo and Microsoft send senders individual complaint notifications, so those land as discrete events. Gmail does not. To protect user privacy, Gmail does not return complaints in the per-recipient format other providers use, and instead exposes only aggregated spam-rate data through Postmaster Tools, at the campaign or mail-stream level rather than the individual level. That data only appears once a sender crosses an undisclosed volume and complaint threshold, so lighter senders may see nothing at all.

Since Gmail is usually the majority of a beehiiv list, a large share of your real complaints never surfaces as a "Spam Reported" count in your account. It gets more misleading as things get worse: a complaint can only come from someone who received the email in their inbox, so once Gmail starts routing you to spam, those recipients can no longer complain, and your visible complaint rate falls precisely when your reputation is degrading.

With the leaks mapped, here is exactly how each number is built.

Every beehiiv metric is built from three things

Strip away the dashboard and beehiiv is tracking two raw events and dividing them by one denominator. The two events are a pixel load (an open) and a link request (a click). The denominator, for nearly every rate beehiiv reports, is delivered, not sent. Understand those three inputs and the rest is arithmetic. So we start with the denominator.

Delivered: the number everything hangs on

When you send a post, beehiiv records send attempts. It then subtracts the emails that never made it: hard bounces (invalid addresses), soft bounces (full mailbox, temporary server failure), and addresses pulled out by the suppression list. What survives is delivered.

• Delivery Rate = delivered / send attempts
• Bounce Rate = bounces / send attempts

This matters because open rate, click rate, unsubscribe rate, and spam rate are all calculated against delivered, not against the raw send. A bounced email cannot be opened or clicked, so excluding it gives a cleaner read on the people who actually received the thing. If you ever reconcile beehiiv against a platform that divides by sent, the gap is the bounces.

One caveat worth keeping in mind: "delivered" means accepted by the receiving server, not placed in the inbox. An email sitting in the spam folder still counts as delivered while having almost no chance of being opened, which is part of why open rate sags when placement slips.

How beehiiv calculates email opens

An open is measured with a small invisible tracking pixel, typically 1x1, that beehiiv embeds near the top of the email. When the recipient's mail client loads that image, beehiiv counts an open. beehiiv places the pixel at the top specifically to dodge the clipping that hides content lower in the message.

That single mechanic produces two numbers:

• Total Opens: every time the pixel loads, including the same person opening twice.
• Unique Opens: the first pixel load per subscriber. Open the newsletter ten times and you are still one unique open.

The headline rate uses unique opens:

• Open Rate = unique opens / delivered

beehiiv has confirmed it calculates open rate on unique opens, which is why that figure is the more stable one to trust. Total opens is useful for spotting your most obsessive readers, not for benchmarking. And as covered above, treat open rate as a directional signal only, because it is undercounted by image blocking and overcounted by pixel preloading at the same time.

How beehiiv calculates clicks

A click is tracked through link redirection. beehiiv rewrites the links in your post so the request routes through its tracking layer before forwarding the reader to the real destination. When that tracked link is requested, beehiiv logs a click.

Same as opens, this gives you two raw counts:

• Total Clicks: every click on every tracked link, repeats included.
• Unique Clicks: the number of individual subscribers who clicked at least one link, each counted once regardless of how many links they hit.

beehiiv also breaks clicks down per link in the Top Performing URLs table (total clicks and unique clicks per URL) and in the per-post click map, so you can see which specific links carried the engagement.

Verified Clicks: beehiiv's bot filter

Raw click data has a contamination problem. ISPs and anti-phishing software scan inbound email and pre-test the links to check for threats. Those automated requests register as clicks even though no human did anything. Authentication scrutiny from Gmail and Yahoo adds more machine noise. The result is inflated click counts that make a post look more engaging than it was.

beehiiv built Verified Clicks to strip that out. It runs click data through a filter that weighs dozens of signals, including IP address, user agent, and click timing patterns, to separate human clicks from bot clicks. The classic tell: a recipient registering several clicks within seconds of the email landing is almost certainly a scanner, not a reader. beehiiv cross-checks against additional signals before excluding it.

That produces a parallel, cleaner set of metrics:

• Verified Total Clicks: total clicks confirmed as genuine.
• Verified Unique Clicks: individual verified humans who clicked.
• Verified Click-To-Open Rate: verified unique clicks divided by delivered.

beehiiv keeps both the raw and verified numbers visible so you can choose which to report. For client and advertiser reporting, verified is the honest figure. Raw clicks will often be meaningfully higher, and the gap is mostly machines. Just remember the tradeoff from the underreporting section: the filter is conservative, so verified clicks can drop a small number of real ones.

The click-through rate trap: same label, two formulas

This is the section to read twice.

The standard industry definition of click-to-open rate (CTOR) is unique clicks divided by unique opens. It answers "of the people who opened, what share clicked." The standard definition of click rate (CTR) used in newsletter advertising, the one Dan Oshinsky and Inbox Collective hold up as the reference, is unique clickers divided by emails delivered (or sent). Two different questions, two different denominators.

beehiiv uses the words "Click-To-Open Rate" for both, on different screens:

• On an individual post's Performance tab, "Click-to-open rate" is calculated as clicks divided by opens. That matches the real CTOR definition.
• On the aggregate Posts Report KPI charts, "Click-To-Open Rate" is defined as the number of subscribers who clicked at least one link, divided by emails delivered. That is a unique click rate, not a click-to-open rate. The denominator is delivered, not opens.

Same three words. Different math. The aggregate figure and the per-post figure are answering different questions, and if you average one and quote it as the other, your report is wrong.

The practical rule for anyone reporting beehiiv numbers:

1. Decide which question you are answering. "What share of recipients clicked" is a click rate over delivered. "What share of openers clicked" is a true CTOR over opens.
2. Pull the number from the surface that uses the matching formula, or compute it yourself from the raw counts.
3. Confirm the label before you trust it. When an advertiser asks for "CTR," they almost always mean unique clickers over delivered, which lines up with beehiiv's aggregate "Click-To-Open Rate" and with the API click_rate field. When they ask for "CTOR," they mean clicks over opens. Confirm which one before you send the screenshot.

If you compute it yourself, the two clean formulas are:

• Click rate = unique clicks / delivered
• Click-to-open rate (true) = unique clicks / unique opens

Every other KPI beehiiv reports, with its formula

beehiiv's Posts Report and per-post analytics surface a long list of metrics. Here is the exact derivation of each one.

Metric	How beehiiv derives it
Sent	Total send attempts for the post
Delivered	Sent minus bounces and suppressed addresses
Delivery Rate	Delivered / sent
Bounce Rate	Bounces / sent
Total Opens	Every pixel load, repeats included
Unique Opens	First pixel load per subscriber
Open Rate	Unique opens / delivered
Total Clicks	Every click on every tracked link
Unique Clicks	Distinct subscribers who clicked at least one link
Verified Total Clicks	Total clicks after bot filtering
Verified Unique Clicks	Distinct verified human clickers
Click-To-Open Rate (Posts Report)	Unique clickers / delivered
Click-To-Open Rate (single post)	Clicks / opens
Verified Click-To-Open Rate	Verified unique clicks / delivered
Unsubscribe Rate	Unsubscribes / delivered
Spam Report Rate	Spam complaints / delivered
Web Views	Unique page views of the web version of the post
Web Clicks (Unique)	Distinct clicks on links in the web post
Web Click Rate	Unique web clicks / web views
Total Impressions	Combined email and web reach for the post

A few of these deserve a sentence more.

Unsubscribe Rate and Spam Report Rate are both divided by delivered, same as the engagement rates. A spike in either is your earliest warning that a send hurt you, and they move faster than open rate when something is wrong. But hold the underreporting caveats in mind: unsubscribe rate misses silent churn, and spam rate is largely blind to Gmail. Low numbers here are not the same as a healthy list.

Web metrics are tracked separately from email. A post published to both web and email has an email audience measured by the pixel and link redirects, and a web audience measured by page views and on-page link clicks. beehiiv reports these on separate axes and only combines them into Total Impressions and Total Clicks when you switch the view to Email and Web together. Do not add an email open rate to a web view count and expect it to mean anything.

The Post Engagement Funnel visualizes the drop from Delivered to Opened to Verified Clicked for a time period, alongside Unique Subscribers and Unique Posts. It is the same data as the KPIs, arranged so you can see where attention falls off.

Content Tags roll all of the above up by content pillar, so you can compare how your "interview" posts perform against your "deep dive" posts rather than just post by post.

Publication-level and historical stats

Beyond individual posts, beehiiv reports rolling stats for the whole publication. The ones that show up in the API and in account-level views include historical average open rate, historical average click rate, total emails sent, total unique opens (first open per subscriber only), and total clicks. These are lifetime or trailing figures, useful for a high-level health read but blunt for diagnosing a specific send.

beehiiv also frames audience health around active subscribers, the readers who have opened or clicked within a window. A reader who has gone silent across many sends is effectively dead weight on your list, and carrying too many of them drags open rate and deliverability down at the same time. Pruning them is one of the few moves that improves several metrics at once.

Pulling these numbers through the beehiiv API

If you are automating client reporting rather than screenshotting dashboards, the beehiiv API exposes these metrics as structured fields. Add the stats expansion to a post or aggregate-stats request and you get back the numbers directly.

At the post and aggregate level the fields map to the dashboard like this:

• recipients, delivered
• opens, unique_opens, open_rate
• clicks, unique_clicks, click_rate
• unsubscribes, spam_reports

Note that click_rate here is the unique-clicks-over-delivered figure, the same quantity beehiiv labels "Click-To-Open Rate" in the aggregate Posts Report. So if you are building a report and pulling click_rate from the API, you are reporting a click rate over delivered, not a true click-to-open rate. If a client wants clicks over opens, compute unique_clicks / unique_opens yourself.

At the publication level, the expandable stats include stat_average_open_rate, stat_average_click_rate, stat_total_sent, stat_total_unique_opened (first open per subscriber only), and stat_total_clicked.

Building the report off the API rather than the dashboard also lets you apply your own definitions consistently across every client, which is the only way to keep a multi-client reporting pipeline honest.

Why your numbers also read high, and swing on their own

We have covered where the dashboard reads low. It also reads high, and moves for reasons that have nothing to do with you, driven by decisions at Apple, Google, Yahoo, and Microsoft. If you report these metrics, you need to be able to explain the moves you did not cause.

• Apple Mail Privacy Protection. Since September 2021, Apple Mail pre-loads the tracking pixel for its users whether or not a human opened the email. That inflated open rates across the entire industry and made Apple-heavy lists look artificially strong. Then starting in April 2024 Apple began changing when that prefetch happens, which reduced pixel loads and pushed reported opens back down, with no change in actual reading behavior. So both the 2021 spike and the 2024 sag were Apple, not you.
• Gmail's image proxy. Gmail routes email images through its own servers, so the opens you see are requests from Google, not directly from a device. Combined with the caching behavior covered earlier, this is another reason the open signal is approximate and unique opens is the number to lean on.
• Bot and scanner clicks. As covered in the Verified Clicks section, security tooling clicks your links automatically and inflates raw clicks. This is why raw click numbers should never be the figure you hand a client.
• Recent provider shifts. The last year added several. Gmail changed its Promotions tab default from chronological to relevance-based sorting in September 2025, which buries senders a reader engages with less. Gmail open rates have also been declining since early 2026 in ways that do not map to any sender-side change. Yahoo cut free storage from one terabyte to twenty gigabytes by August 2025, increasing over-quota soft bounces for some senders. And in late February 2026 Outlook and Hotmail rate-limited deliveries widely enough that Microsoft acknowledged it, delaying delivery and suppressing opens for senders who did nothing wrong.

The lesson is not that metrics are useless. It is that any single send's open rate is noise in both directions, and the signal lives in the trend across many sends and in the metrics that require real human intent.

How to actually read a beehiiv report

Rank the metrics by how much human intention they require.

Opens require none. After MPP, an open can mean a machine loaded a pixel while your subscriber was asleep, and a real read can go uncounted when images are off. Treat open rate as a rough directional read, useful for trend lines and subject-line tests, never as proof anyone read anything.

Clicks require intent. A person chose to act. Verified clicks require intent and survive a bot filter, which makes them the most trustworthy engagement number beehiiv gives you, as long as you remember the count runs slightly conservative.

Conversions, replies, and unsubscribes sit even closer to truth, because they are deliberate human decisions with consequences. And treat silence carefully: a flat unsubscribe rate and a clean spam count are not proof of health, because both metrics systematically miss the readers drifting away and the Gmail users quietly reporting you. A clean way to read any send is to ask whether real people clicked and converted, and whether the trend across recent sends is holding. If yes, the send worked, whatever the open rate did.

Frequently asked questions

Does beehiiv undercount opens if images are blocked? Yes. An open is only recorded when the tracking pixel loads. If a subscriber has images blocked or off by default, reads the plain-text version, or views the email in a preview pane that does not pull remote content, the read happens but no open is counted. Your true readership is always somewhat higher than the open count implies.

Why don't my Gmail spam complaints show up in beehiiv? Because Gmail does not report complaints the way other providers do. Yahoo and Microsoft send individual complaint notifications, but Gmail only exposes aggregate spam-rate data through Postmaster Tools, at the campaign level and only above an undisclosed volume threshold. Since Gmail is usually the bulk of a list, much of your real complaint volume never appears as a "Spam Reported" event in your account.

How does beehiiv track email opens? With an invisible 1x1 tracking pixel embedded near the top of each email. When the recipient's mail client loads that image, beehiiv records an open. Open rate is then unique opens divided by emails delivered.

What is the difference between total opens and unique opens in beehiiv? Total opens counts every pixel load, including the same person opening repeatedly. Unique opens counts only the first open per subscriber. beehiiv calculates open rate on unique opens, so that is the more reliable figure.

How does beehiiv calculate click-through rate? It depends on the screen. On an individual post's Performance tab, the "click-to-open rate" is clicks divided by opens. On the aggregate Posts Report and in the API, the headline click metric is unique clickers divided by emails delivered, which is technically a click rate rather than a click-to-open rate. Always confirm the denominator before reporting it.

What are Verified Clicks in beehiiv? Verified Clicks is beehiiv's bot-filtering system. It analyzes signals like IP address, user agent, and click timing to remove automated clicks from ISP scanners and anti-phishing tools, leaving a cleaner count of genuine human clicks. The filter is conservative, so it can occasionally drop a real click.

Why is my beehiiv open rate dropping when nothing changed? Usually because of inbox-provider behavior rather than your content. Apple's adjustments to Mail Privacy Protection prefetching, Gmail's image caching and 2026 open-rate decline, Yahoo storage-driven soft bounces, and Microsoft rate limiting have all suppressed reported opens industry-wide without any change in real engagement.

Should I divide email rates by sent or delivered? beehiiv divides by delivered. Bounced and suppressed emails never reached anyone and cannot be opened or clicked, so excluding them gives a more accurate read on the people who actually received the email.

Inbox Alchemy builds and runs founder-led newsletters, including the reporting that proves they work. If your beehiiv numbers need to mean something to a client or an advertiser, the definitions are the whole game.