Email event tracking means two different things, and the phrase is worth splitting before you build anything. The first meaning is tracking events about your emails: whether a message was delivered, opened, clicked, bounced, marked as spam, or unsubscribed. The second is tracking product events in order to trigger emails: someone signs up, hits a usage limit, or lets a trial lapse, and that event sends a message.
Both are real work, and most teams need both. This guide covers each in turn: first the events that come back from your email provider and what to do with them, then the product events that fire emails in the other direction, and finally why storing the two together on one user profile is where the value compounds.
Part 1: tracking events about your emails.
Once you send a message, a stream of events describes what happened to it. These are the events you track to know whether your email is working and to protect your sending reputation. The core set is small and worth knowing exactly.
| Event | What it signals | What to do |
|---|---|---|
| Delivered | The receiving mail server accepted the message. The most reliable positive signal. | No action needed; this is your deliverability baseline. |
| Open | A tracking pixel loaded. A soft signal, and often overcounted (see the caveat below). | Treat as a weak engagement hint, not proof someone read it. |
| Click | A tracked link was followed. The strongest engagement signal you get. | Use for follow-up triggers and to score real interest. |
| Bounce (hard) | Permanent failure: the address is invalid or does not exist. | Suppress the address immediately and stop sending to it. |
| Bounce (soft) | Temporary failure: full mailbox, server down, message too large. | Retry within a window; suppress after repeated soft bounces. |
| Complaint | The recipient marked the message as spam. | Suppress immediately; a rising rate is a deliverability emergency. |
| Unsubscribe | The recipient opted out of future mail. | Honor it at once; stop marketing sends to that address. |
How these events reach you.
Two mechanisms deliver email events. Delivery-related events, delivered, bounced, complained, and usually opens and clicks, arrive as provider webhooks: your email platform POSTs each event to an endpoint you run, as it happens. This is the reliable, server-side path, and it is how you should capture anything you act on. Opens and clicks specifically depend on the older client-side mechanism underneath, a tracking pixel for opens and wrapped redirect links for clicks, which the provider then reports to you as events.
The open-rate caveat.
Open tracking is not trustworthy the way it once was. Apple Mail Privacy Protection preloads remote images, including the tracking pixel, so a message can be marked opened whether or not the recipient actually looked at it. Across any modern audience, a large share of subscribers use Apple Mail, which means reported open rates are inflated by an amount you cannot cleanly measure. Keep opens as a rough directional trend if you like, but do not use them as a precise metric or as a trigger for anything that matters. A click is a much stronger signal because it takes a deliberate action, and a product event after the email is stronger still.
What to do with each event.
Tracking these events only pays off if they drive action. Hard bounces and complaints should suppress the address immediately: continuing to send to a dead address or someone who reported you as spam damages your sending reputation for everyone else on your list. Soft bounces are temporary, so retry within a sensible window and only suppress after the failures repeat. Above the level of any single message, watch your bounce and complaint rates over time as your deliverability early-warning system; a sudden rise is the signal to pause and investigate before an inbox provider starts filtering you.
Part 2: product events that trigger email.
The second meaning of email event tracking runs in the opposite direction. Instead of recording what happened to an email, you record what a user does in your product and use those events to decide what to send. A signup fires a welcome sequence, an activation event ends the onboarding nudges, hitting a usage limit triggers an upgrade prompt, and a lapsed trial starts a win-back message. This is event-triggered email, and the events that power it are product events, not email events.
Getting this right is mostly about tracking the right product events with clean, stable names. Two companion guides cover it in depth: how to think about product event tracking for email and a concrete list of which events to track for a SaaS . The short version is to track the handful of events that mark real progress through your product, name them consistently, and send them from your backend where they cannot be blocked.
Storing email events next to product events.
The payoff comes when both directions live on the same user profile. If your email outcomes, delivered, opened, clicked, sit in your email tool and your product events sit in your analytics tool, answering a simple question means joining two systems. Put them together and the questions that were a data project become a segment: everyone who clicked the onboarding email but never activated, everyone who opened the trial-expiry warning but did not upgrade, everyone who bounced and so never saw the sequence at all. Each of those is both an email fact and a product fact about the same person, and you can only ask it if the two facts share a profile.
This is what GetFluxly is built to do. It captures product events, builds a profile per user, and stores email outcomes next to them, so your behavioral segments can filter on email engagement and in-product behavior in the same view, without a SQL query or an export. It is a smaller, newer tool than the large suites, and the trade is depth for having both sides of email event tracking in one place.
Email event tracking, answered.
What events should I track for email?
Track the full delivery lifecycle: delivered, open, click, hard bounce, soft bounce, complaint, and unsubscribe. Delivered and bounce events tell you whether mail is reaching inboxes, complaints and unsubscribes protect your sending reputation, and opens and clicks measure engagement (with opens being the least reliable). If you also trigger email from product behavior, track the product events that start those sends, such as signup, activation, and trial expiry, separately. The two sets answer different questions: one is about your email, the other is about your product.
Are email open rates still reliable?
No, not on their own. Apple Mail Privacy Protection preloads remote images, including the tracking pixel, so a message can register as opened whether or not the recipient ever looked at it. That inflates open rates across any audience with a meaningful share of Apple Mail users, which is most of them. Opens are still useful as a rough, directional trend, but do not use them as a precise metric or a trigger for anything important. Clicks are a far stronger signal because they require a real action, and product events after the email are stronger still.
How do I track email events with Resend?
Resend delivers email events through webhooks. You register a webhook endpoint, subscribe to the events you care about (delivered, bounced, complained, opened, clicked, and so on), and Resend POSTs each event to your endpoint as it happens, signed so you can verify it is genuine. Your handler verifies the signature, deduplicates on the event id, and updates the recipient's state, for example suppressing an address on a hard bounce. The full walkthrough, including signature verification and retries, is in the guide to Resend webhooks.
What is the difference between email events and product events?
Email events are facts about a message you sent: delivered, opened, clicked, bounced, complained, unsubscribed. Product events are facts about what a user does inside your product: signed up, created a project, hit a usage limit, upgraded. Email events tell you how your sending is performing; product events tell you what to send and when. The most useful setups store both on the same user profile, so you can segment on the combination, for instance everyone who clicked the onboarding email but never activated.
Both meanings of email event tracking matter, and they reinforce each other: the events coming back from your email tell you what is working, and the product events going in decide what to send next. For the sending side of the picture, see the guide to transactional email best practices , and for the provider mechanics of capturing email events, the walkthrough on Resend webhooks.