Rate limiting vs frequency capping: throttle the pipe vs protect the person

What is the difference between rate limiting and frequency capping?

Frequency capping limits how many messages one person may receive in a rolling window. Rate limiting limits how fast a workflow or system may send per minute to protect deliverability and infrastructure.

One-line for eCRM teams: frequency cap = person budget; rate limit = pipe throttle. Both mean “send less,” but they protect different things.

After a Friday blast or a busy cart path in Iran, teams say “too many SMS — let’s cap.” Sometimes the person was hit four times in two hours (frequency). Sometimes twenty thousand SMS hit the operator in ten minutes and queued or filtered (rate). Do not swap one fix for the other.

For flow health beyond opens, see What is revenue per recipient (RPR)?.

How does each one work?

Frequency capping

Locks on the person: e.g. max 2 marketing SMS per 24 hours, or 3 promo emails per 7 days. Before each send the engine asks: does this person still have budget in the window? If not, suppress or defer. Goal: less fatigue and STOP.

Rate limiting

Locks on the pipe / workflow / integration: e.g. max N SMS per minute from this journey, or the operator API ceiling. It slows the send queue so deliverability, the SMS line, or email workers do not melt. Goal: system and inbox health — not necessarily how the individual feels.

Iran example: Friday sale + cart path

A digital-goods brand blasts sale SMS at Friday noon while a cart journey fires a touch every two hours. Operator rate limit is 1000 SMS/minute; the blast fills the pipe for twenty minutes. Some people get the blast plus two cart touches the same afternoon and hit STOP. The team only asks to raise the rate limit; in reality the pipe is busy and there is no per-person cap.

Diagnosis

Practical fix

1. Frequency cap: e.g. max 2 promo SMS / 24h / person (transactional separate).
2. Rate limit: send Friday blast through a throttle matching the operator contract.
3. Suppress people inside sensitive cart journeys from same-day blasts.
4. Keep transactional (OTP, receipt) out of the promo cap.
5. Weekly metrics: STOP, complaints, queue depth, and RPR — not send count alone.

Keep SMS flow vs campaign clear: SMS flow vs SMS campaign. For shot vs path: Marketing journey vs campaign.

When frequency cap, when rate limit?

1. One person getting touches from several journeys in 24h? → Frequency cap.
2. Large blast stressing operator or ESP? → Rate limit.
3. You need both: person budget first, then pipe throttle.
4. Are transactional messages exempt from the promo cap?
5. Is a rate-limited queue’s delay acceptable for the recipient?

Leadara mapping: events, segments, journeys, email/SMS

Leadara runs on events, segments, journeys, email, and SMS. Layer both controls on that model:

1. Events: record sends/engagement to count the frequency window (sms_sent, email_sent, or equivalents).
2. Suppress segments: people whose frequency budget is spent stay out of the week’s blast.
3. Journeys: gate SMS/email touches on person cap; throttle large campaign sends to the rate window.
4. Channels: separate caps for email vs SMS; never mash transactional into promo budget.
5. Goal + guard: on cart paths, purchase is the exit — a frequency cap does not replace a goal.

Common mistakes

• Raising rate limit when the pain is person-level STOP
• Caps so tight that welcome and cart paths die
• One budget for transactional and promo SMS
• Ignoring queue: rate limit with no delay monitor
• Calling success “all messages Delivered”

FAQ

What is the difference between rate limiting and frequency capping?

Frequency capping is a per-person message budget; rate limiting is how fast the system/pipe may send.

If we rate-limit, do we still need frequency caps?

Yes. A healthy pipe can still bombard one person from multiple journeys.

Should caps be the same across channels?

Usually separate: tighter on SMS, looser on email; transactional always separate.

Where do rate limit numbers come from?

Operator/ESP contracts and your own worker capacity — not standup gut feel.

Does Leadara have one magic switch for both?

You compose suppress segments, journey conditions, and campaign send policy; tune numbers with STOP and queue data.

What is the right metric on a busy week?

STOP and complaints (person), queue depth and API errors (pipe), plus RPR — not volume alone.

Do quiet hours replace these two?

No. Quiet hours are a clock window; frequency cap is person budget; rate limit is pipe throttle. Three separate layers.

Bottom line and next step

Frequency capping protects the person; rate limiting protects the pipe. This week, set a 2 promo SMS / 24h person cap, throttle the Friday blast to the operator window, and read STOP next to queue depth.

14-day test pattern

Days 1–2: baseline STOP and queue.
Days 3–5: turn on person frequency cap (10% holdout uncapped).
Days 6–10: set blast rate limit to operator contract.
Days 11–14: compare STOP, complaints, queue delay, RPR.

If B cuts STOP without a meaningful RPR drop, make it channel policy.

Team language: person or pipe?

In standup, if someone says “too many SMS,” ask: too many for one person, or too many per minute? First answer → frequency cap. Second → rate limit.

Go-live checklist

1. Separate promo frequency caps written for SMS and email?
2. Transactional exempt?
3. Rate limit aligned with operator/ESP contract?
4. Queue and delay monitored?
5. Suppress for spent budget?
6. Dashboard: STOP, complaints, queue depth, RPR?

Without item 6, “we added frequency control” is a slogan, not a system.

Boundary with quiet hours

Quiet hours are a clock window (e.g. 11pm–8am). Frequency capping says even in daytime a person gets at most N messages. Rate limiting says how many the pipe may pass per minute. Put all three on one board so Friday sales do not mash them together.

Healthy signals

Related reading

• What is revenue per recipient (RPR)?
• SMS flow vs SMS campaign
• Marketing journey vs campaign