The cadence question: how often should you email?

Built into "how often should we email?" is an assumption: cadence is one program-wide dial you turn until the magic number appears. It isn't. Cadence is an emergent property, something that falls out of other decisions rather than being set directly, and the decisions it falls out of are each a more productive conversation than the top-level one.

Walk through the actual users on your list and the contradictions stack up fast. Someone three days into onboarding (the first week or two after signup, when usage habits are forming) should get more mail than your average. Someone dormant for six months should get less. Buyers from this week sit in a different post-purchase sequence than users who've never converted. And the click-everything power user can absorb what a cold-list recipient cannot. Same program, wildly different right answers.

Better question: what are the inputs that determine the right cadence per cohort (a group of users who share a defining trait: stage, engagement, acquisition window)? Answer those, and the program-level frequency falls out as a consequence, not as an argument.

Lifecycle stage. Different stages tolerate different frequencies. Onboarding is intense by design: more email in week one than in any other week of the relationship. Engaged users tolerate regular cadence because they're finding value. At-risk users (those whose engagement has dropped but who haven't fully lapsed) tolerate some cadence but need higher-signal messages, not more of them. Lapsed users need specific low-density sequences, not the standard program. The Lifecycle Program Design skill covers stage-specific cadence for each canonical stage.

Engagement tier within the stage. Inside any stage, users vary. A subscriber who opened four of your last five emails can handle more than one who opened one. Tier explicitly: segment users by engagement signal and ship a different cadence for each band. Most programs that pick a single rate end up under-mailing the engaged base, over-mailing the light base, and producing worse aggregate numbers than they could.

Natural product cycle. A daily-engagement product (a news app, a habit tracker) tolerates a different frequency than a monthly-engagement one (a tax tool, an annual-renewal SaaS). The lifecycle cadence should match or just slightly lead the product's usage rhythm, not impose a separate one that ignores when the user is ready for the product.

Deliverability headroom. Deliverability is your ability to land in the inbox rather than spam. Strong sender reputation (mailbox providers' trust score for your sending domain) and clean list hygiene give you more room to send. Weak reputation, more volume compounds the damage. Most programs that "can't send more email" actually can. They just need to fix hygiene first so the additional volume doesn't poison reputation. The deliverability guide covers the full connection between frequency and sender reputation.

Content inventory. You can only send as many messages as you have worth sending. Shipping a second email in a week just because the schedule said so, when the content is thin, is worse than shipping one good email. Quality bar sets the cadence ceiling; cycle sets the floor.

Even with well-designed per-cohort cadences, things go sideways when systems collide. Onboarding email fires on a Tuesday morning. Lifecycle newsletter goes out the same hour. Product-update broadcast hits the whole list. Abandoned-cart push catches one user who tabbed away on the checkout page. That user gets four messages in an afternoon. Not because anyone designed it, but because four independent systems fired independently. A user-level frequency cap is the wrapper that prevents this compound damage.

Practical cap: no more than N marketing messages per user per week, with transactional (order confirmations, password resets) and critical-service messages exempt. N depends on program and tier; three to five marketing messages per week is the range that balances engagement and fatigue for most B2C audiences. Under-mailing a cohort 20% below the cap rarely hurts; over-mailing 20% above it reliably does.

Priority is the harder question. Which message gets cut when a user is about to cross the cap? Decide in advance and encode it in the system. Onboarding beats newsletter. Abandoned-cart beats promotional. Transactional beats everything. Without explicit priority, the cap produces random cuts and the program becomes less coherent, not more.

A subscriber who hasn't opened a single email in 30 days is telling you something the cadence rules can't hear. Your tiering says they're engaged and should get three a week. The behaviour says otherwise. Drop them dramatically below the rule. Not because the rule is wrong, but because the engagement signal is telling you the user is heading toward lapsed. Continuing to mail at the normal rate accelerates that journey.

A spam complaint, a move-to-junk, or an abandoned unsubscribe flow is a louder signal again. Suppress outright or drop to minimum-touch immediately. The cost of one extra send to a user who's already said "stop" through behaviour is a complaint. Complaint rate is the metric mailbox providers (Gmail, Outlook, Yahoo) actually weigh against your reputation. Complaints poison deliverability; unsubscribes just trim the list.

The principle: cadence rules define the ceiling, not the floor. The ceiling is the maximum you can mail without damage. Whatever engagement signals say the user is willing to receive sets the floor, and it can be much lower than the ceiling. A cadence system that ignores the floor over-mails disengaging users and ships them straight to spam complaints: the one thing the cap was supposed to prevent.

Lifecycle teams rarely get to answer cadence questions in isolation. A senior stakeholder observes they're getting "too many emails from your own company" and asks the team to cut back. The ask is real, but it's a sample size of one. A cadence cut based on a single user's experience is usually wrong for the base.

The productive response isn't "actually our engagement rates are fine". That reads as defensive. It's to surface the tiering. Show which users are receiving how many messages. Show engagement-by-cadence data for each tier. Invite the stakeholder to look at whether their own cadence is actually aligned with their own engagement tier, which, usually, it isn't. They opened two emails all year and are receiving three a week. The right answer is almost never "cut everyone's cadence". It's "this user's cadence doesn't match their engagement: fix the mismatch, not the program".

The other version of this question: what's the actual risk of over-mailing? Higher complaint rates, higher unsubscribe rates, and sender reputation damage that compounds over months. The cost usually surfaces 30–90 days after the frequency increase, which is why programs rarely link them. Watch complaint rate, not unsubscribe rate. One predicts deliverability damage; the other predicts list-size damage.

Significance testing, checking whether a difference in numbers is real or just noise, has a role here too. Any cadence change deserves a proper test before it rolls program-wide. A 20% cut that produces a 30% revenue drop is worse than the problem it was trying to fix.

Stop arguing about a single program-wide number. Pull a list of your active subscribers, segment them by engagement tier (opens in the last 30 days is fine for a first pass), and look at how many messages each tier received last week. If your engaged top decile and your disengaged bottom decile got the same volume, you have a tiering problem, not a cadence problem. Fix that first. The program-level number sorts itself out.