Key takeaway
An ecommerce email programme is a store's event stream with a sending policy attached. Five events decide which flows you can build, and four of them earn most of what the channel earns. Receipts and campaigns are separate streams, and the mailbox providers and the reader both treat them that way. Carts are abandoned at 70.22%, but 40% of that is checkout costs arriving on the last screen, and I've never fixed a pricing problem with a reminder.
What ecommerce email marketing actually is.
Ecommerce email marketing is the mail a store sends against what a shopper has done. In practice that's three kinds of mail: receipts and shipping notices tied to one order, promotional sends to a chosen audience, and flows that fire off a store event. The definition is flat, correct, and available on every page ranking for this phrase. The take underneath it is the useful part: an ecommerce email program is a store's event stream with a sending policy attached. The emails are the output. The inputs are a handful of events and a consent state, and a store that gets those right can build any flow it likes on any platform it buys.
Page one of this search offers eight, fourteen, or twenty "types" of ecommerce email, and the count is close to the only thing separating one guide from the next. The types are a menu. Nothing on the menu tells you what has to be true in the storefront before you can serve any of it, which is why two stores follow the same guide and get results a factor apart. The stores I've watched do well here were never the ones running the longest list of email types. They were the ones whose checkout emitted three events you could rely on.
The channel is worth the trouble because the storefront is. Online sales were 17.1% of US retail sales in the second quarter of 2026, $340.2bn seasonally adjusted. What the definition above doesn't tell you is which of the two streams a given message belongs to, and that turns out to decide what the message is allowed to do.
General email platforms try to serve every industry. We chose a strict constraint on Developer Podcast because "we built SmartrMail to be purely for ecommerce" and nothing else. We ignore blogs. We ignore content sites. This narrow scope gives us the time to build a proper recommendation engine.
The two streams, and the line between them.
A store sends two kinds of email, and the difference isn't tone. One confirms something the customer already did: the order, the shipment, the return, the refund. The other asks them to do something new. A receipt is the first kind. A Tuesday promotion is the second. Mailbox providers score the two differently, suppression applies to one and not the other, and the reader knows which is which before opening either.
This is the line nearly every guide on this search walks quietly over. An order confirmation is the most-opened mail a store sends, so the advice is always to fill the space under it with recommendations, an upsell, or a code. Do enough of that and the confirmation stops being a confirmation. What arrives is a promotion with a receipt on top, and it now needs everything a promotion needs: a one-click unsubscribe, a subject line about the order rather than the offer, and suppression that holds. Somebody who unsubscribed from your marketing did not unsubscribe from their shipping notification, and a store that can't tell the two apart will eventually send the wrong one.
My rule ends the argument before anyone starts it: a receipt confirms an order, everything else is a campaign, and a store that keeps the two apart never has to work out which one a given email was. The upsell you wanted in the confirmation works about as well in a campaign two days later.
Permission travels badly across borders too. An address collected at a checkout in one market carries a narrower licence than the same address collected in another, and the difference turns on what the customer was actually told at the counter or on the form, not on anything a platform can infer afterwards. The mailbox providers read none of that. They judge the sending domain, which is a stricter test than any of it.
The five events every flow is built on.
Before a flow is a flow, it's an event with an identified contact attached. Every automation on page one of this search is a rule that waits for one of five things and then sends something. A store that emits all five can build any of them, on any platform, in an afternoon. A store missing one can't build the flows that depend on it, and no amount of platform fixes that, because the gap is upstream in the storefront rather than in the sender.
- Subscribe: the contact and the consent state, with when and where it was collected. The consent record is the part that gets lost, and it's the part that matters later.
- Cart created: a cart with an identity attached to it. An anonymous cart is a number in an analytics chart, not something you can mail.
- Order placed: the line items, the value, and the customer. It's what makes a receipt possible and what every segment above one order is built from.
- Fulfillment: shipped, delivered, or delayed. It carries the only two emails a customer actively wants to receive.
- Lapse: not an event a store emits but a threshold it defines. Ninety days of nothing on a monthly-purchase product isn't ninety days on an annual one.
Events are the input, not the program. The hard part no flow builder solves for you is identity resolution: getting the logged-out browser, the subscriber, and the customer to be one person by the time a flow reads the record. Nitrosend takes those events over its API and turns them into flows with triggers, steps, and branches.
Complex designs rarely outperform basic utility in retail. Our own platform data on QA Selling Online proves this point. The messages that generate the most revenue per send are "simple as hell" and rely entirely on product recommendations. They just show items based on what the customer has bought or liked. You only need a subject line and relevant products to drive sales.
The four flows worth building, in the order worth building them.
The count is the point. Page one offers up to twenty flows, and a store working through its first ten thousand orders should build four. The order below is the order they earn their keep in, and each one buys the time to build the next. Everything else is either a variation on these four or needs infrastructure they don't. I'd rather see four flows a store can explain than twenty it inherited from a template pack. Build them one at a time, and give each one enough sends to be judged before you start the next.
| Flow | Fires on | Judged on |
|---|---|---|
| Welcome | Subscribe, sends inside the hour. | First orders from new subscribers, not open rate (highest number in the account, tells you nothing). |
| Cart recovery | An identified cart with no matching order, two or three sends across 48 hours. | Recovered revenue net of discount. Keep the discount off send one. |
| Post-purchase | Fulfillment, not the order, so a review request never lands before the parcel does. | Repeat purchase rate. |
| Win-back | The lapse threshold you defined above. | Reactivation. Read the failures too: contacts it can't wake are the ones to suppress. |
Everything past those four wants a live product catalogue sitting behind the trigger. Back-in-stock, price drop, replenishment, and browse abandonment all need the sender to know what a product is, what it costs today, and whether it's in stock, which is a feed problem in the storefront rather than a flow problem in the email tool. It's worth solving once the first four are earning, and it's a poor place to start. Recommendation emails out-earn every other automation type, which is exactly why it's tempting to build the feed problem first. Resist it: the four above don't need a catalogue, and they're what proves the programme is worth running before you build one that does.
Most cart abandonment isn't an email problem.
Every guide on this topic opens on the same number. Roughly 70.22% of online carts are abandoned, averaged across 50 studies, and the figure is quoted as the size of the email opportunity. It gets quoted without the rest of the page it sits on, which is the half worth reading: the same research asked shoppers who abandoned at checkout why they did it, and almost none of the answers are things an email can address.
- Extra costs at checkout, 40%: shipping, tax, and fees appearing on the last screen.
- Delivery too slow, 20%: the real date was worse than the one the shopper assumed.
- Distrust of entering card details, 19%: a checkout that doesn't look safe to hand a card to.
- Forced account creation, 18%: no guest checkout, or none a shopper can find.
The conclusion nobody draws from that list is the one worth drawing. An email can't fix a shipping cost that appeared on the last screen. A code sent an hour later is a store paying, one order at a time, to repair its own checkout, and it's paying at exactly the moment the shopper has already decided the price was wrong. Cart recovery is still worth building. It's worth being honest about what it is: a collection mechanism for the abandonment you haven't fixed yet, not a growth channel. Move the shipping cost onto the product page and the flow gets cheaper on its own.
Those figures cover shoppers who reached checkout with intent. A large share of carts were never purchases in the first place, and no sequence converts somebody who had four tabs open and was using the cart as a shortlist.
A cart abandonment message needs to do more than just remind the shopper about their forgotten item. I used a basic coffee mug scenario on QA Selling Online to illustrate this tactic. A customer abandons their cart. You send an automated message "30 minutes later" with the forgotten product. You also include smart blocks with related items. This turns a basic reminder into a personalized catalogue.
What an ecommerce sender is actually held to.
Past 5,000 messages a day to Gmail addresses, the receiving side sets the rules. Gmail's sender requirements ask for SPF, DKIM, and DMARC on the sending domain, the From header aligned to one of them, and a spam complaint rate kept below 0.30%. Yahoo asks for the same shape of thing and adds a hard operational number: unsubscribes honored within 2 days. One-click unsubscribe is a mechanism rather than a link, a POST to a URL listed in the headers with no confirmation screen in between, defined in RFC 8058.
The 0.30% isn't a best practice. It's a ceiling with enforcement behind it, and it's the number that makes an ecommerce program different from a newsletter. Complaints come from promotional volume, and the domain carrying those complaints is the same domain the receipts leave from. So a weekend of hard promotion can cost a store the delivery of the mail its customers were waiting for, and the customer never finds out why the shipping notice didn't arrive. They just email support, which is the one cost of a bad send nobody puts in the report. That's the argument for separating the two streams at the sending level rather than only in the copy, and it's why the answer to a soft month is never a bigger send.
Authentication is table stakes, and a competent store passes it in an afternoon. What it doesn't fix is who is on the list, which is where a complaint rate actually comes from. Nitrosend gives you sending domains with DKIM and DNS verification, suppression that holds across campaigns and flows, and BYO sending keys on Pro and above covering Amazon SES, Resend, Postmark, Mailgun, and SendGrid, so a store that already has a sending reputation it trusts keeps sending on it.
The only metric that matters at the end of the month is the total sales figure. We put this calculation front and center on In the Ring with SUMO Heavy to keep retailers focused. The dashboard shows exactly "how much revenue is coming from email versus the rest of your store." A retailer might see they make 18% of their revenue from campaigns. Tracking this baseline is the first step to testing new flows and improving overall retention.
Running the program from an agent instead of a builder.
Everything above is data, a trigger, and a template. The flow is a record. The audience is a query. The send is a policy with a schedule on it. None of that is inherently a screen. It only became one because the tools were built for a person clicking through a builder, one wizard step at a time.
Every existing email platform was designed for humans clicking buttons, so an agent bolted onto one is driving a dashboard by remote control: it reaches whatever the API happened to expose and stops at whatever the product only ever shipped as a page. Nitrosend is MCP-first. Every capability is an API endpoint and an MCP tool before it's a screen, so the four flows above, the segments behind them, and the suppression list underneath them can be created, changed, and audited from one agent command. We've run ecommerce sending stacks from the inside, which is why the Nitrosend MCP server was built before the screens were.
An agent doesn't decide what your lapse threshold should be, and it'll happily build a fifth flow nobody asked for. The judgement in those four flows stays yours. What changes is the cost of acting on it. The distance between deciding to hold the discount back on send one and having that live stops being an afternoon in a builder and starts being a sentence.
A store with four flows, a clean split between receipts and campaigns, and a complaint rate somebody watches needs a sending platform that answers to the thing already running the store. That's the case Nitrosend is built for. Start on the free tier: 8,000 emails to begin with, then 500 a month, unlimited contacts, and full MCP, API, and CLI access with no card. Point one flow at it, watch it for a week, and read the pricing ladder once you know your real volume.
Sources
- US Census Bureau, Quarterly retail e-commerce sales: online sales at 17.1% of total US retail sales in Q2 2026, $340.2bn seasonally adjusted.
- Baymard Institute, Cart abandonment rate statistics: 70.22% averaged across 50 studies, and the checkout abandonment reasons at 40%, 20%, 19%, and 18%.
- Google, Email sender guidelines: the 5,000-a-day bulk threshold, SPF, DKIM, DMARC, From-header alignment, and the 0.30% spam complaint rate.
- Yahoo Sender Hub, Best practices: Yahoo's equivalent authentication requirements, and unsubscribes honored within 2 days.
- RFC 8058: Signaling One-Click Functionality for List Email Headers, the POST mechanism behind one-click unsubscribe.
Common questions
Yes, and the reason is structural rather than a benchmark number. Email is the only channel where a store owns both the audience and the trigger: nobody rate-limits your list, and a receipt or a shipping notice reaches an inbox whatever an ad platform is charging that week. What varies is how much of that a given store captures, and most of the gap comes down to whether the storefront emits the events a flow needs. A store with clean subscribe, cart, order, and fulfillment events gets far more from the same platform than one without them.
Check the trigger before you touch the copy. A flow that falls off a cliff is almost always an event problem: a storefront change stopped emitting the event, an integration key expired, or identity resolution broke and the flow is firing on contacts it can't match to an order. A flow that fades slowly is usually audience exhaustion, because everyone who was going to respond already has and new contacts are arriving more slowly than the flow burns through them. Rewriting the subject line fixes neither. Read entries into the flow first, then completions, then revenue, and only rewrite once you know the right people are still entering it.
That question is really a choice between three classes of product, and they aren't competing for the same job. A commerce-native suite bundles a product catalogue, on-site behavior, and often SMS, and bills against the size of your contact list. A general ESP gives you campaigns, templates, and a flow builder without the commerce layer. An API-first sender treats sending as infrastructure your own systems drive. Work out which class you're buying before you compare prices, because comparing across the three tells you almost nothing. None of those three is what Nitrosend is. Nitrosend is an AI-native email platform: every capability is an API endpoint and an MCP tool before it is a screen, so campaigns, flows, contacts, and segments answer to an agent instead of to somebody clicking through a builder.
You can, and doing it changes what the email is. A confirmation is something the customer's own action asked for. Once enough promotion is stacked under it that the offer is the reason it went out, what arrives is a promotion with a receipt on top, and it needs everything a promotion needs: a subject line about the order rather than the offer, a one-click unsubscribe, and suppression that holds. The simpler rule is to keep the confirmation a confirmation and send the recommendations as a campaign two days later.
It depends where they are, and it turns on what they were told at checkout rather than on the purchase itself. The narrow version that travels almost everywhere is an address taken in the course of a sale, used for your own similar products, with an easy free way to object offered when you took it and in every message since. A different product line, or a different seller, falls outside that. An address collected for a shipping notification was collected for a shipping notification.
Two or three, spread across roughly 48 hours, with the first going out within a few hours of the cart going quiet. Keep the discount off the first send: a code on send one teaches regular shoppers to abandon on purpose, and you end up paying for carts that were always going to convert. Judge the flow on recovered revenue net of whatever discount it gave away, not on its open rate. If recovery volume keeps climbing, that's usually a checkout problem rather than an email opportunity, and the checkout is the cheaper thing to fix.
Set the cadence against your spam complaint rate rather than against a number somebody published. Gmail and Yahoo both expect bulk senders to stay under a 0.30% complaint rate, and that ceiling is what a frequency decision is really trading against. Send, watch the complaint rate and the unsubscribe rate for a couple of weeks, and increase only while both stay flat. A store that sends twice a week to people who want the mail is safer than one sending monthly to a list it bought, so segment before you throttle.
Separating them is worth it once promotional volume is meaningful, and the reason is reputation rather than deliverability folklore. Complaints come almost entirely from promotional sends, and if receipts and campaigns leave from the same domain, a bad promotional weekend can delay or suppress the shipping notice a customer is actively waiting for. Splitting the streams, usually a subdomain per stream with its own authentication and its own reputation, keeps the mail people asked for insulated from the mail they merely tolerate. It also makes the numbers legible, because a complaint rate mixing both tells you nothing about either.